LuaPlus binding with Tilde debugger.

#1 Just setup a git repo for it, no need to wait for the steering committee ;)

No doubt it will stir some interest in the community.

#2 Sounds interesting!

Worked on something similar for Torque2D. See https://github.com/jamesu/Torque2D/commits/scripting_refactor

(There have also been a few past attempts with integrating Python which can be found in the resources section)

The scripting changes in the development branch are also meant to help with integrating more generic script types by changing the traditional thunk code from using const char* to generic ConsoleValueRef references. Though it maybe be better for overheads if a custom thunk template was used in the engine function macros.

As you mentioned though, it's hard to support everything TS supports especially if you go the generic route since most scripting languages implement their own idea of an object system.

I did plan on extending my code so namespaces were better reflected in lua, though I eventually came to the conclusion that in the end I'd just end up with an unfriendly mess. I had also originally intended to make use of LuaJIT, however I discovered it doesn't quite work properly on OSX 64bit unless you manipulated the memory allocations which sounded risky at best. Thus I just gave up and decided to just concentrate on improving TS instead. ;)

Performance-wise I have come to the conclusion just about every interpreted scripting language is slow provided it's overused, the thunks into the engine code typically being bad. Though seriously, you shouldn't be calculating Fibonacci in script. That bit should be written in C++. ;)

@Timmy

One can only hope.

#3 It is currently set to wait for the "Tilde" debugger. So it will most likely hang.

I will put up a zip including some example lua scripts and a tilde project soon.

https://github.com/antonyjones67/Torque3D

the source is in engine/source/scriptbinding and engine/source/scriptbinding/lua

also source in luapluslib and tildelib you still need the tilde executable.

One reason i didn't put it up here earlier were possible concerns with licensing.

https://github.com/jjensen/luaplus51-all
https://github.com/jjensen/lua-tilde

After talking with Josh Jensen I do not think this is going to be a problem.

I would like to point out for legal reasons that other than LuaPlus and LuaTilde that this is my work and has no similarity with the work that I do for my employer. They have been very gracious about letting me share this.

#4 James: Sorry I didn't properly reply to your comment. I was in a hurry for work and I wanted to get the information up there. I would very much like to hear any suggestions you might have. I could really use your help. I'm not really sure what the best way to get a zip file to people with the luascripts and the tilde project. Any suggestions other than email? If you email me i can send them to you. Let me know what you want to do.

#5 I think HNGamers upload site is still active. It was kind of the de facto standar dplace to upload things when gg.com stopped accepting resource uploads. You should probably keep the file size to a minimum there though (i.e. only what's not included in the repo).

#6 I hope your okay with this Dan, but I added t3d-bones as a template. It has 2 lua files and a tilde vcproj file in it. The lua files are /game/main.lua and /sys/main.lua these basically just call the torque script files. But if you have a tilde executable you can open the game/vcproj file, connect with LocalHost i.p. 127.0.0.1:10000. It will then break at the beginning of game/main.lua. Anyway let me know if you guys are having any problems.

#7 I'm quite happy about that, actually :D

#8 I was thinking a good next step would be to point the TorqueScript c code to the scriptbinding functions. So if there are future changes to this code it will happen in only one place.

sceneObject.cpp, line 1234

DefineEngineMethod( SceneObject, isMounted, bool, (),,
"@brief Check if we are mounted to another object.\n\n"
"@return true if mounted to another object, false if not mounted." )
{
return object->isMounted();
}

Change To:

#include "scriptbinding.h"

DefineEngineMethod( SceneObject, isMounted, bool, (),,
"@brief Check if we are mounted to another object.\n\n"
"@return true if mounted to another object, false if not mounted." )
{
return SceneObject_isMounted( object );
}

#9 I really need input on the above. Because I'm not gonna do the above work unless I know this is going to be integrated into the main branch. Because ultimately it makes a lot of work to maintain it. So I really need input from the Steering Committee.

#10 Whoah what's this SceneObject_isMounted function? Ohh, I see, it's in here. Oh gosh that's terrifying ;P. Given such an intrusive change to the entire engine source, I have to wonder whether it's worth it. How do those script binding files get generated? I.e. where is the code inside them pulled from? And what's the 'one place' future changes would be made? I don't understand this work well enough to understand why it'd be useful...

#11 Whoa! I'm glad that scriptBinding.h is auto-generated. With functions like SceneObject_isMounted( object ), this is a massive change to the source of T3D, it will take a long time for it all to be tested and accepted. Please don't let that put you off, just saying is all.

#12 My thought was a long term one. I wanted to separate the torquescript binding from the classes like sceneObject. The file sceneObject really shouldn't have the bindings in them. The class should act independently of what scripting language is used. That is my thoughts. So my thoughts were to redirect things. Then gradually remove the dependencies. It seems like the only way to truly run Torque3d with out torquescript. Unless you guys would prefer a lua2Torquescript bridge like James was working on. I was just presenting a long term plan of removing Torquescript as a dependency. With lua bridging the gap. Ultimately when finished you could use any scripting language you wanted. Including a visual based one like BluePrint from Unreal. But If I can't get public support it is not worth my time.

#13 It would be nice if I could get James Urquharts input on this. Since he has probably put a lot of thought into this, working on a lua 2 torquescript bridge.

#14 I haven't really mussed with the Engine/Console macros much, so I'm fairly ignorant in my suggestion here.

But couldn't you modify those functions to generate hooks to your binding functions?

So instead of needing to rewrite everything, the define engine/console functions would also create the necessary calls.

#15 Jeff: Answer is yes, this is what I refer to as a bridge. I can do this, but it doesn't ultimately get us any closer to running Torque without a dependency on TorqueScript. I'm just not sure why we would want to run 2 different scripting languages. If that is what we want to do, i'm fine with that. Currently the way I have it is a first step to simplifying things.

#16 Are people just not understanding what I am proposing or are people too nervous about the amount of work?

#17 I'm in both those camps :p. A common reason bring up for keeping TS usable is that all the editors are written in it. Dump TS and we're back to square one with editors.

I don't mind this, long term, but in the short term be aware that's an important consequence.

#18 I created a new branch called lua_intrusive. You will notice that I was able to pull out all of the MACROS like IMPLEMENT_CONOBJECT, DefineConsoleMethod and more. I moved them into scriptbinding/torquescript. This leaves SceneObject, SimSet, and SimObject free of any scripting bindings. I haven't done it yet, but we then point the script functions to the ones that I added in ScriptBinding. So that both lua and TorqueScript point there. Sharing the same block of code. This all can be done without upsetting anything. But at the end you will have 2 separate bindings.

right now things look like this:

source/scriptbinding/lua
source/scriptbinding/torquescript


later on we can add others like

source/scriptbinding/python

they will all share the same code in scriptbinding

I'm not sure how this could hurt anything and then later on we can figure out a way to handle the editors.

I could even write something that will convert torquescript to lua script.

But the important thing is that people start making changes in scriptbinding and not all over the place.

Anyway this is just an idea.

#19 I think I see. Right off the bat, having those massive single files seems like a mistake, no? Those files will have to include basically every single class header in the engine. And it seems like if someone then wants to, for example, expose a new method to script, that they'd need to go and change each language implementation file, wouldn't they? They'd have to add a new DefineEngineMethod as well as whatever the Lua equivalent is.

However, I definitely like the idea of getting scripting-language-specific code out of places they don't belong.

I was originally encouraging to push you to get this work in public so we can have discussions like this - and I'm applying harsher criticism as you're asking for real feedback with the intent of taking the engine in this direction. It means I have to view stuff with a harder edge than if you just wanted to use this and make it available to others for their own use as well. Please don't take this as hostility - I think the work you're doing is great, and something that has been sorely needed for a while! I really appreciate that you've stepped up to actually work on it.

#20 I have no problem, with constructive criticism. It shows you care about the final product. These are good questions that everyone has brought up. And trust me i think it would have been easier to do the bridge. But I thought this would also address the complexity of torque. The binding and the source really should be separated. i know that the binding files are currently one big file at the moment but it is that way only initially. it makes it easier for me to manage at the moment, but i am fairly certain i can generate new files by class, fairly easy after the transition. you can see how simple sceneobject.cpp is without the macro muck. normally bindings call functions within a class, it has become more complicated because they added code as part of the binding in torque. and each macro has a slightly different spin on how arguments are passed. just so you know i have a tremendous amount of respect for the guys at garagegames i have been in the industry for 15 years and i really respect and appreciate what they have done.
i would really appreciate honesty on this. if there is no intension of pulling this into development. please tell me now so i can make other plans.