Modular Scripting Integration Thread

#61 Man, this is going to be some significant amount of effort. The console is tied into the SimObject ID system and ghosting and everything, I think. I would be up for this, definitely, though not starting immediately. We have a lot of TS-related changes lined up for 3.7. I think during or after that, I'd be more willing to start writing some code - or, probably, ripping it out, since I still think a good way to start would be to make a C++-only version of the engine. At least, I will do that to gain an understanding of how far the console reaches into the engine, which bits do what, etc. Sort of the way I ripped the stock templates apart to make t3d-bones.

EDIT after seeing James' post: I wonder if C++11 variadic templates will help make EngineAPI into what it was supposed to be. What information did you find was lacking? I assume that in the process of modularising scripting we would have to fix that.

#62

Quote:
From what I gathered engineAPI was at some point supposed to be a replacement for the console stuff, but in the end it seems to have mostly been turned into a way of adding even more docs

That is really funny. :)

@dB,
I think I would be up for that brain damage. I need to get familiar with T3D again and get the newest version. Should I grab the master or development version? I also need to practice using Github more.

#63 Development all the way. We keep it reasonably stable. We've also not been able to release as quickly as we'd like, so master is a bit behind.

#64

Quote:
I wonder if C++11 variadic templates will help make EngineAPI into what it was supposed to be.

That's what I thought when I first saw that feature in the new standard.

#65 @daniel

The only good thing variadic templates would do is make those long function wrapper templates slightly easier to read. This could also be achieved by using a preprocessor.

The engine api lacks a lot of crucial bindings for core utility types. From what I recall there was also a big problem passing In strings since it explicitly required everything to be encoded as UTF16 (though even then I still had problems and had to force if to use UTF8).

The console related classes reach quite far into the engine though it's not too surprising and in a lot of cases its quite useful. Though I would advise against thinking everything in console == torque script. In a lot if cases I imagine stuff can be repurposed and generalized.

#66

Quote:I would advise against thinking everything in console == torque script.

Yep, good point.

#67

Quote:
I would advise against thinking everything in console == torque script.

This brings back really confusing memories.

@JamesU,
Thanks for giving us some pointers on this.

@dB,
I think your approach of ripping it out and see where the leaks are is a really good idea. Then using JB Weld we can get it running again. Then put the scripting language back in with some crowbars, duct tape, and a welding torch.

#68 It might also be useful to be able to draw a console/TS line in the source code. But yeah, your description sounds basically accurate :P.

EDIT: will need at least 3 crowbars.

#69

Quote:
The only good thing variadic templates would do is make those long function wrapper templates slightly easier to read. This could also be achieved by using a preprocessor.

I thought that's how it was being done before engineAPI....

And let's not forget that we can weld crowbars in place where duct tape is insufficient....