I've got a working COB -> LUA decompiler and a partially built BOS -> LUA cross-compiler.
You can get the COb->LUA decompiler, here. It still needs some work done on getting it to read various info from an xml file instead of hardcoding, as well as some exact targetting of the LUA->game engine bindings.
Its writtin in C# 2.0, so you'll need VS.NET 2k5 to compile it or use the .NET framework 2.0 comand line compilers.
Towards a New Animation Format. Very long.
Moderator: Moderators
Argh: it will just be another way to add code to upspring. It will not be used for the animation itself. But it could be used to write a BOS exporter..
Xon: Ehm, nice, but I'm not sure how it can be used atm.
There are more good scripting languages in the world than just lua...If you're just going to use a new scripting language that's not LUA... um... what is it?
Xon: Ehm, nice, but I'm not sure how it can be used atm.
The bos syntax would be incredibly simple for anyone like you who master C++ Just look at any bos and you'll see it's plain understandable even if you have never learnt it. Or read the bos page inside TaDesign.zip for the complete reference list of all bos command and function. As for the bos->cob, well, we've got Scriptor source.Zaphod wrote:I think that would offer more options, and saves me from learning how to do BOS scripting (Which is something I'm really not interested in).
Bos syntax is not difficult no, but actually supporting a BOS exporter and getting all the features in that advanced BOS scripters want, well that takes a lot of time. Time that can be better spend on something more fun for me personally.
I might just use lua after all, depending on how well my own templated LUA binding will integrate into the rest of my code (I really hate boost so I refuse to use all the boost based LUA binders out there). I've also read about the LuaJIT project so it can fulfill my high demands for script execution speed :)
What is really cool is that there are LUA bindings for every API upspring is using, so you could potentially make the LUA part of upspring as powerful as the C++ part in terms of features to use. Such as making custom GUI/drawing/exporter components for upspring in lua.
Which is really what is needed when upspring needs support even a bit of what Argh wants with it. I'm not going to write an all-in-one spring unit package, but I'm willing to make it extendible so others can.
I might just use lua after all, depending on how well my own templated LUA binding will integrate into the rest of my code (I really hate boost so I refuse to use all the boost based LUA binders out there). I've also read about the LuaJIT project so it can fulfill my high demands for script execution speed :)
What is really cool is that there are LUA bindings for every API upspring is using, so you could potentially make the LUA part of upspring as powerful as the C++ part in terms of features to use. Such as making custom GUI/drawing/exporter components for upspring in lua.
Which is really what is needed when upspring needs support even a bit of what Argh wants with it. I'm not going to write an all-in-one spring unit package, but I'm willing to make it extendible so others can.
Just make sure the luabindings are in a seperate file that gets compild seperatly onyl when the bindings change and you'll be fine, thats how nfordia did it in spring.
Also you might consider luabind again since it adds support for classes and structures in lua other than just tables, something you woul have to delve deep into lua itself to try to implement.
That ro I believe there are extensions that will do that for you, aswell as programs that do nto require boost that you feed in header files and a formatted lua itnerface and it reels out a header file with the necessary glue functions to bind them together, rather than doing it at runtime with luabind.
You might also consider another interpreter derived from lua, which should be backwards compatible. I believe I posted many links and stuff to it only I've forgotten what it's called
squirrel? I think that might be it I aint sure.... It's written specifically for game environments, ahs numerous extensions, support for classes, and I found the squirrel binding explanations in the official source and wiki much easier to udnerstand than the lua ones....
Also you might consider luabind again since it adds support for classes and structures in lua other than just tables, something you woul have to delve deep into lua itself to try to implement.
That ro I believe there are extensions that will do that for you, aswell as programs that do nto require boost that you feed in header files and a formatted lua itnerface and it reels out a header file with the necessary glue functions to bind them together, rather than doing it at runtime with luabind.
You might also consider another interpreter derived from lua, which should be backwards compatible. I believe I posted many links and stuff to it only I've forgotten what it's called
squirrel? I think that might be it I aint sure.... It's written specifically for game environments, ahs numerous extensions, support for classes, and I found the squirrel binding explanations in the official source and wiki much easier to udnerstand than the lua ones....That's not an option for me, I want it to be integrated directly into my metadata system, so you don't have a situation where you are constantly extending the script interface to keep up with the actual code.Just make sure the luabindings are in a seperate file that gets compild seperatly onyl when the bindings change and you'll be fine, thats how nfordia did it in spring.
Squirrel sounds very cool and useful and better than LUA as far as I've read their webpage
Plus they say they have a more lightweight template binding which supposedly solves the bloat and compile time involved with luabind.
*dropping lua again*
I'm not sure if I'm going to do it for spring, although it could be possible. Spring already has a basic version of my class system in it (rts/System/creg), and what I'm doing in upspring is just an improved version of that.
Right now I just want to get the ported code working properly, then get my map renderer integrated in it. After that I'll probably reduce my spring activities to side-jobs like upspring and maintaining the map renderer. Getting full script support (Not only a binding but also actual usage in game), is something I want to leave to others.
Right now I just want to get the ported code working properly, then get my map renderer integrated in it. After that I'll probably reduce my spring activities to side-jobs like upspring and maintaining the map renderer. Getting full script support (Not only a binding but also actual usage in game), is something I want to leave to others.