use Lua in place of torquescript

#21 Actually, your right, that would work but may also be confoosing to some. Though, it's a lot cleaner. If someone is doing a wholesale replacement anyway, that would definitely be a good way to go. Nice Richard.

Though now I'm curious.. has anyone else checked out squirrel? www.squirrel-lang.org

#22 Virtual memory paging != Memory segmentation to make up for a limited address space. The memory segmentation is what was first mentioned (although it was called paging). The 68K series did not need to do this because of its 24 bit address space and flat memory model. I was responding to Davids comment about segmentation and I used the wrong term calling it paging when I should have called it segmentation.

#23 @smally

I checked out squirrel a while back. Quite neat, and it has a nice c-like syntax without things being too restrictive (like, say... AngelScript). The only thing I found odd about it was the "<-" operator. If I was seriously replacing the scripting in the engine that would be a strong candidate.

#24 I'm not a fan of it's odd <- syntax or the local keyword syntax either. Outside of those 2 things, it's pretty decent. The biggest win with squirrel over lua to me here is the gc rework. It truly is much more predictable and for games, that's what you really want for a gc. Plus it has a way to deal with extending C++ classes, though it's not standard to the language and is an add-on instead.

@Demo I didn't say vm paging = mem segmentation. Memory segmentation was just about the only memory model available to the x86 until the late 286 models (unreleased) and early 386. The paging used in conjunction provided the basis of the later vm paging mechanism. It's not connected to flat or segmented memory. Two completely different mechanisms. Not trying to keep this going. Would rather focus. My personal opinion is that I liked the 68k more. ;)

#25 @smally, 68k was a great assembly language, I could never seriously take such a big step back to x86 It's bad enough using 'C' (not ++) when you know you could do the same faster in 68k, shame it only works on that chipset, 68k assembler for the x86 chipset anyone? Lol

#26 6502 asm! ;p

Since Lua allows you to disable gc, as an exercise one could disable it and then enable it on a schedule to allow it to clean up. You'd have to watch this very carefully though - plenty of opportunities for issues. If it works well then it could help to make gc more predictable in Lua.

Or one could always tweak the gc system for their specific application - but I'm not big on writing memory managers....

#27 This is a must Lua is much more powerful and is widely used. Torquescript is not as a powerful and requires learning lots of syntax for a custom scripting language only used in torque.

#28 Now that's just silly. If you need more "power" in TorqueScript, just add it.

Of course, if you're that excited about using Lua (not "LUA") you can just add that, too. As has already been done with Torque, by several people. In fact, if you actually read the posts in this thread you'll see that there are available implementation examples for many different languages for Torque....

Or is there some new language called "LUA" that I haven't seen yet? We are talking about Lua, right?

#29 The power! The unimaginable power!

DefineEngineFunction(makeMyGame, bool, (const char* designDocument, const char* exeFilename),,
    "Generates an appropriate exe based upon the design document.\n"
    "@param designDocument - A string that provides the games conceptual design in English and UTF8 format.\n"
    "@param exeFilename - The filename of the target executable file (exe).\n"
    "@return bool - True if the generation of the .exe file was successfully generated.\n")
{	
    return 0;
}

#30 Ok, so - where's the button?

#31

Quote:Ok, so - where's the button?

Some assembly may be required...

#32 I have to write it in assembly?!? WAAAAAaaaaaiiiiiiiillllllllll