Modular Scripting Integration Thread

#1 Just so everyone knows, integration will be slow for a little while as I am busy at the moment, but progress will be coming soon.

#2 Squirrel is a pretty good language, all the power of Lua, but none of the silliness(unless you count source files ending in .nut), and it'd be a lot easier for beginners than TS!

Keep up the good work.

#3 Did you get anywhere with this?

#4 Nope, but i still occasionally do modify the TorqueScript Virtual Machine.

#5 I've made a small amount of progress on this. (working on getting the VM set up with Sqrat)

In your opinion, is it worthwhile to implement this? Or has Torquescript improved very much since TGE 1.3? From what I can tell, it hasn't changed significantly. There's also the barrier that it's not a common language.

#6 TorqueScript has changed very little since then, though Jeff's doing some interesting work on it. My problem with the language is that it just isn't built on solid foundations. I'd sign up for getting some other VM (Lua or Squirrel) integrated, but my plate's a bit full right now.

#7

Quote:
I'd sign up for getting some other VM (Lua or Squirrel) integrated, but my plate's a bit full right now.

Damn :-( . This is certainly an area T3D could gain a lot. Lua is obviously known to a lot more people but i think squirrel would be a great choice because people already familiar with TS would not need to make such a huge adjustment when moving to squirel due to a similar syntax. The big difference is how much better squirrel would perform compared to TS.

#8 Oh I agree. TS needs to go away long-term, but I for one am focusing on the committee's immediate goals - now 3.6 (unit testing), then in 3.7 we'll be introducing some changes to TorqueScript to make it a bit more palatable for those of us who can't wait for an alternative. Those changes in 3.7 are where I intend to work on my understanding of the console and how we might modularise/subvert/rip it out.

#9 All good i understand, so much to do so little people ;-)

#10 Does Squirrel require semi-colon statement termination? That's one of the things I like about Lua - it does not. I can't tell you how much I hate that TorqueScript just silently fails to compile on many occasions if you leave a semi-colon out in just the right place - and other times it gives you errors in unrelated locations.

#11 Here's a decent overview of Squirrel and Lua differences.

EDIT: Sigh, reading the Squirrel manual makes me sad. It does unfortunately appear to be a good choice for its performance and ease of embedding, but the language itself is so... lacking in any sort of modernity. It's almost as bad as TorqueScript. Ah well. I need to learn to stop whining and do useful things instead.

#12 When I was evaluating bottlenecks in torque I couldn't find anything suggesting torquescript was having a direct impact on performance. Sure, it's slow in it's own regard. However it isn't, and shouldn't be, relied on for speed-critical things like per-frame function calling. Short of the postFX, in stock torque there's no torquescript functions called per-frame.
Tim Newell and I both tried removing the calls for postFX and moving them into C++ but tests showed no difference at all in performance. We couldn't find any examples where torquescript was the immediate cause of performance loss.

I guess my question is what kind of tangible benefits would we expect to see from a change in scripting language? Performance? Ease of use? "Power"? Would these impacts really be noticeable to the average user, and if not, could the same improvements be achieved by simply migrating performance critical code to C++ instead of TS?

#13 I think "Market Acceptance" is about all we can hope for, really. But then we're in the same discussion over and over again - go look at this long, waste-of-breath thread in the UE4 forums for the dialog you can expect. Everyone has a favorite and if you don't cater to each and every single individual one of them then you're a jerk. TorqueScript is a little "weird," but it's not the worst thing out there.

#14 I simply stopped as I felt it wasn't worth while changing it.

Quote:I need to learn to stop whining and do useful things instead.

I fall guilty of that statement too, but it's true.

I was talking with Andrew Mac how I've had thousands of lines of math and raycasting torquescript called per frame, and I've seen barely any performance loss at all. instead of 3ms per frame it was 6ms per frame.

I've seen a hundred raycasts called per frame + math code + other things and no performance loss that was implemented in a marble blast mod by another programmer.

I've seen some ugly things in TorqueScript called on a per frame basis, and I've never seen performance loss that was very bad. IMO at this point, it's not even worth while changing.

For our game, we chose this engine, and one of the reasons was TorqueScript. IMO TorqueScript should not go away forever (I'll never take it out of my engine).

What the Virtual Machine could use is some love, yes, but speed performance code should be implemented directly in the engine and exposed to the Virtual Machine via EngineMethod/EngineFunction anyways.

That's what I like about this engine too. It don't have to be totally script bound, while at the same time, has an easy high level way of going from Engine to script and vice-versa.

Just my 2 cents.

#15 Something interesting I found while digging through the console source: it's full of comments about how the console will be removed and everything will use engineAPI instead. Was that you guys?

Also, one of the big reasons for using Squirrel is that although it's not the most popular scripting language, it's still better-known than Torquescript. I personally don't mind TS; I actually do a lot of work in it for Blockland. However, an obscure language can really be a turn-off for new modders.

#16 That's from way back at the switch from TGEA to T3D - it refers to the template-based binding system for Torquescript. This wasn't completed - there are functional differences between the older macro-based binding and engineAPI that made the older system desirable in certain circumstances.

With the introduction of variadic templates in C++ 11 it would be possible to carry this forward without all of the weirdness associated with the earlier attempt, but it would entail moving the engine to the new standard - a whole different set of challenges.

#17 Okay, so to summarize, the only real reason to change out the scripting language is because no one recognizes torquescript?

Recognition aside, is there any particular reasons why people may have issues adapting? I mean, I've never heard of Squirrel script, and I never heard of TorqueScript before using this engine. In both cases I'd have the same reaction: "What's the syntax like? C-like? Okay, cool.". In either case you'll have to adapt to the nuances of a relatively unknown scripting language with c-like syntax. What's the difference?

If you're going to go for easy to use, commonly recognized, and easily adapted then there's one clear winner in all categories :P

#18 If anyone with the skills to understand how to jack into the engine wants to add ECMA script to Torque I will be there to help. I just don't understand how to properly rip out TS or jack in via the helper classes. I tried to get my head around that and started going insane. That is why I stapled Python onto the side of the package and called it good. Which is in itself another insane move...

If anyone who understands how to jack into the engine and make a modular scripting system (scripting languages as modules) that also includes TS I would love to learn how to do that. I would do all the footwork in the C++ and make it happen. I just don't have a clue how to do it or where to start. I have started many times to only end up shaking my head in frustration. I think such a modular system would do well for both T3D and T2D. I know people have mentioned LLVM and other tech which are bit beyond my experience or sphere of knowledge.

I also saw that AMD is moving toward LLVM type stuff in chip. I don't know what that does for future game engines, but I think there is change in the winds for microprocessors.

For the ECMA script engine I would recommend V8 as it is programmed by the TOP virtual machine designers in the world.

For the unwashed:
Javascript is not Java at all. It is ECMA script. FYI

#19 Language is language... as far as Torque is concerned I've yet to see a truly valid (and not personal preferences) for replacing it (TS)... no matter how often the discussion arises.

#20

Quote:Okay, so to summarize, the only real reason to change out the scripting language is because no one recognizes torquescript?

Over the years we've run into quite a lot of random bugs and quirks while modding for Blockland. Most of our issues could be fixed with some changes to TS though, which I think you guys have mostly done already. I didn't known about your TS improvements at the time, so I set out to see how hard it would be to change the scripting language. The answer? Quite frustrating.