Lua resource
by Joe Rossi · in Torque Game Builder · 01/31/2006 (2:05 am) · 7 replies
Well my LUA<->Torque bridge is basically done. I could have spent more time to emulate Torque calls in Lua and then replace client.cs with client.lua. Or maybe use SWIG or ToLUA on the entire engine, but I really like the simplicity of what I have now. Everything is mostly in one file, which should compile easily with either GCC or MSVC. There is plenty that can be done with this as-is. Plus the thought of completely removing TorqueScript seemed foolish. Expecting major changes, I was waiting for TGE 1.4 to post this.. but it seems to work the same as it did with TGE 1.3. Anyway I hope it helps someone.
Get it here
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9665
Get it here
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9665
#2
it says:
external symbol _errno not resolved....
Any ideas?. thnxs.
02/02/2006 (4:05 pm)
I'm having troubles trying to link this in VC++ 2003it says:
external symbol _errno not resolved....
Any ideas?. thnxs.
#3
Now, exactly how much stuff gets bound to Lua by this code? Is it just T2D functions, or is it pretty much everything (TGE stuff, datablocks, etc)?
BTW, maybe you should consider using LuaBind for your bindings. It lets you bind actual classes (indeed, going so far as to change the Lua language to add classes and deriving), so you can actually derive Lua classes from C++ objects.
Granted, it requires the use of Boost, which requires the use of the C++ Standard Library, which seems to conflict with certain parts of TGE. But breaking those parts of TGE seems a small price to pay, consdiering how much LuaBind offers (and they just had a new release). The maintainability of your code will increase by an order of magnitude.
02/02/2006 (6:17 pm)
Ohh, good times.Now, exactly how much stuff gets bound to Lua by this code? Is it just T2D functions, or is it pretty much everything (TGE stuff, datablocks, etc)?
BTW, maybe you should consider using LuaBind for your bindings. It lets you bind actual classes (indeed, going so far as to change the Lua language to add classes and deriving), so you can actually derive Lua classes from C++ objects.
Granted, it requires the use of Boost, which requires the use of the C++ Standard Library, which seems to conflict with certain parts of TGE. But breaking those parts of TGE seems a small price to pay, consdiering how much LuaBind offers (and they just had a new release). The maintainability of your code will increase by an order of magnitude.
#4
@Smaug: There are no Torque engine functions bound to Lua. This is as lightweight as I could make it. It simply allows you to access any Torque variable from Lua, run any Lua code from Torque, and vice versa. Sure, I looked at SWIG-Lua and toLUA++ but I decided not to go that route. I feel those add too much bloat and extra files to maintain. As it is, this resource only adds around 200KB to the EXE (which is mostly the Lua interpreter). The bridge is contained in one file and allows a developer to access only what he/she needs from the other language at any given time, as opposed to binding everything to Lua. I'd rather let TGE do the datablock stuff and handle events while Lua keeps track of game logic. I'll see about throwing together a demo perhaps based on the shooter, that can better illustrate this.. unless someone beats me to it! :p
One tricky thing someone could do now.. is add Lunatic-Python labix.org/lunatic-python and use that Python bridge inside of this Lua<->Torque bridge. But my head hurts to think about that...and I'm no good with Py.
02/02/2006 (10:20 pm)
@Adam: That's what happens when you build as a Single-Threaded Runtime Library "/ML". Try building it as a Multi-Threaded Runtime Library "/MT"... Trust me, I had trouble with this at first too ;D@Smaug: There are no Torque engine functions bound to Lua. This is as lightweight as I could make it. It simply allows you to access any Torque variable from Lua, run any Lua code from Torque, and vice versa. Sure, I looked at SWIG-Lua and toLUA++ but I decided not to go that route. I feel those add too much bloat and extra files to maintain. As it is, this resource only adds around 200KB to the EXE (which is mostly the Lua interpreter). The bridge is contained in one file and allows a developer to access only what he/she needs from the other language at any given time, as opposed to binding everything to Lua. I'd rather let TGE do the datablock stuff and handle events while Lua keeps track of game logic. I'll see about throwing together a demo perhaps based on the shooter, that can better illustrate this.. unless someone beats me to it! :p
One tricky thing someone could do now.. is add Lunatic-Python labix.org/lunatic-python and use that Python bridge inside of this Lua<->Torque bridge. But my head hurts to think about that...and I'm no good with Py.
#5
True, but someone must assign that variable a new value. Someone has to provoke the compilation of a new Lua chunk and execute code in that chunk that updates functions with their new contents. It's not as simple as changing a couple of lines in a file and the results appear in an already executing game; the game has to reload and process that file. It either is going to be told this manually (possibly by a level restart), or by asking the OS at regular intervals if the file has changed recently and reloading it if it has.
I just wanted to make clear that Lua isn't a system that associates compiled chunks with files and automatically reloads them anytime they're changed. That if you want to use the possibility that Lua provides for runtime editing of scripts, you have to do work to make it happen.
02/03/2006 (12:13 am)
BTW, Joe, about your comments in the discussion section of the resource:Quote:Metatables allow Lua to "see" when a variable, function, or object is assigned a new value, and then run a function in response to that change.
True, but someone must assign that variable a new value. Someone has to provoke the compilation of a new Lua chunk and execute code in that chunk that updates functions with their new contents. It's not as simple as changing a couple of lines in a file and the results appear in an already executing game; the game has to reload and process that file. It either is going to be told this manually (possibly by a level restart), or by asking the OS at regular intervals if the file has changed recently and reloading it if it has.
I just wanted to make clear that Lua isn't a system that associates compiled chunks with files and automatically reloads them anytime they're changed. That if you want to use the possibility that Lua provides for runtime editing of scripts, you have to do work to make it happen.
#6
You're right that once you compile a chunk it's compiled. But once that chunk is loaded into the interpreter those variables and functions can be changed all you like.
edit:grammar
02/03/2006 (12:39 am)
Smaug: I'm not too clear on what it is you need to do, so it's hard for me to picture how you might achieve it. I only suggest metatables because those functions, if set up properly, can theoretically scan and load a file whenever you type "level=X" as a game is running. I'm just not sure if Torque can dynamically load levels like that... of course you can probably docode() the appropriate TGE function(s) and change levels the Torque way. You're right that once you compile a chunk it's compiled. But once that chunk is loaded into the interpreter those variables and functions can be changed all you like.
edit:grammar
#7
02/03/2006 (7:37 am)
@Joe: thanxs, that was happening. 
Torque Owner Josh Williams
Default Studio Name