RE: Lua animation (cob replacement)

[lurker]

I don't think I agree with any of the points in your post, even if I want the same thing. I don't think bos is particularly easy to understand. Lua is faster. Why would you put a compiler on a text editor instead of in spring.

[IllvilJa]

Trepan, you already have said it is 'not likely' the code will be published for others to work with but what can be done to make it 'less' 'not likely'?

I'm only speculating here, but if you feel the code is not 'ready' for being publicly available then either let people get it "in private" so they can use whatever "wart-remover" they see fit (including fixing conflicts with current git) or maybe just take a deeeep breath and publish it with warts and all, resisting the tempting urge to "clean it up" first. Nobody will focus on any such "warts" in the code and point fingers at you, people will simply focus on the fact that you have contributed to the collaborative effort to get Lua animation become a reality which would be win for all and glory points for you.

[Forboding Angel]

@lurker, lua is a lot harder to understand.

However, someone was talking about something in lua that would essentially run bos, in which case, that would be nice.

[lurker]

Is lua harder to understand or are all the programs written in lua harder to understand? When's the last time you had a complex bos?

[jcnossen]

Lua has much more features. It takes some time before people understand closures or even types. COB has nothing of that.

[Argh]

BOS can get quite complex, I should say.

I have programs written for stuff in P.U.R.E. that are well over 500 lines. Most stuff I write in Lua is far shorter.

I would suspect that any practical animation system driven by Lua would be pretty simple for the average end-user to plug stuff into anyhow. The problem is getting from A to B, where A is doing it all from scratch, and B is "merely" designing pleasing, efficient loops of animation code.

But, as I said before, I think it's pointless to move from BOS to Lua. Better to spend that same development time on more modern model formats that include animations within them. Lua isn't going to free us from the problems presented by a lack of IK support, which makes working with a lot of things too time-consuming or just flat-out impossible.

[lurker]

Lua has much more features. It takes some time before people understand closures or even types. COB has nothing of that.

It has global vars and local vars. Nothing more complex should show up in a simple animation. Nor would anything other than floats and piece names.

[SpliFF]

Another pointless discussion.

1.) It's basically inevitable that a Lua interface will be written. I'll do it myself if that's what it takes. I mean, hell, the whole COB implementation is basically 1 file and really just interfaces with Spring in about 3 logical ways (moving pieces, hiding pieces and calling other functions).

2.) No sensible implementation would remove COB support because there are too many scripts already out there. The Lua and COB (and/or C and Java) interfaces would simply extend a generic script class that does all the actual work.

There's about 2 days work at best. Arguing over the merits of each language won't get it done.

[lurker]

1 file

This really convinces me you know the code.

[SpliFF]

You're nitpicking. I'm talking about CobInstance.

CobEngine, CobFile, CobThread and friends are only relevant to COB, not the execution of COB's behaviours - which is the relevant issue for Lua integration.

I could have been clearer about that but it's not relevant.

[lurker]

Cobthread is far more important imo; it handles callbacks. If you want me to take you seriously then either explain yourself or write this "two days work at best".

[SpliFF]

90% of this task is just code refactoring. Very little new functionality is required.

CobInstance renamed ScriptInstance
CobInstance now extends ScriptInstance
COB-specific behaviour gets copy-pasted to CobInstance. Becomes virtual in ScriptInstance.

LuaInstance extends ScriptInstance
LuaInstance interfaces get exported to Lua as Call-ins/Callouts

Move generic stuff in COB* classes that should go in ScriptInstance
Cleanup COBInstance pointers that should become ScriptInstance pointers
Cleanup unitdef references to '.cob' to also handle '.lua'

Profit.

2 days is an estimate, but not an unrealistic one. I'm knee-deep in incomplete model-loader code and projects at work or I'd do it right now to make my point. I don't believe it's particularly unrealistic but I'm not going to argue it either.

[Tobi]

I took a quick look at it and with only a handful of new callins (TurnFinished, MoveFinished, ...) and callouts (Turn, Move, Spin, EmitSfx, AttachUnit, ...) it seems possible to implement the required interface to make it possible to replicate COB-like functionality in Lua (using coroutines to implement CobThread).

The callbacks into C++ code could be done using an extra callout and a Lua userdata holding callback + cbParam1 + cbParam2.

[jK]

erm there was a reason why trepan's patch was/is 500kB large

The current system isn't capable to handle such many callins, instead you need to write a complete new handling of those.
So gadgets can dynamically link/create new callins, and they shouldn't go through the gadgetHandler anymore, also the gadgetHandler isn't designed for this at all, so you have to write two complete new handlers (one for the gadgets, one for the cobs). Also using coroutines for the unit scripts is very recommended.

[Tobi]

Using coroutines for unit scripts doesn't make sense to me ATM; AFAICS coroutines should be used for CobThreads, of which there can be any amount per unit...

And of course only a single Lua state for all COBs, otherwise a lot of time would be wasted calling code doing nothing. (when nothing in that unit is animating.)

(You could, with some imagination, view the Lua code as a replacement of GCobEngine, ie. the active CobThread/coroutine scheduler.)

[trepan]

Here's what I did:

1. Split the synced/unsynced script spaces into separate global lua states.
2. Improved call-ins speeds using LUA_CALLINSINDEX / LuaCallInDB
3. Added LuaLink for flexible inter-script access
4. Added LuaDelayQueues, which provides the following call-outs:

Code: Select all

    // call a function, or resume a thread
    static int delay(lua_State* L);        // seconds  
    static int delaysynced(lua_State* L);  // seconds as frames
    static int fdelay(lua_State* L);       // frames

    // has to be called within a thread
    static int sleep(lua_State* L);        // seconds
    static int sleepsynced(lua_State* L);  // seconds as frames
    static int fsleep(lua_State* L);       // frames

5. Have a c++ LuaUnitScript object per unit, and have it call into
the LuaRules synced script space.
6. Rewrote the lua event router.
7. Setup a unithandler.lua script, which made it easier to have
script generators for per-unit-type scripts (still allowing per-unit
scripts).

P.S. I'm sure there was more to it, but that gives some of the basics
relating to LuaUnitScript

[Tobi]

Status: almost finished.

[Pxtl]

So this is really going to happen? Awesome.