Lua as replacement for BOS/COB

[FLOZi]

I don't really see what advantage is has for axes though, it's just an added confusion.

And I'm sure I'm missing something blatant, but really what is the advantage of using radians for the animator?

[yuritch]

Hmm, probably that's what the engine uses internally? All of this lua unit script thing was meant to provide easier interoperation between scripts and the engine among other things, so it's only logical it will use the same units of measure.

[FLOZi]

Good point. Easy enough to use math.rad anyway

edit; though some current functions seem to use degrees:

gl.DrawListAtUnit
( number unitID, number listID, [ boolean midPos,
number scaleX, number scaleY, number scaleZ,
number degrees, number rotX, number rotX, number rotZ ] ) -> nil

[thesleepless]

very excited about this, would love to see an example script also.

i notice the functions take a UnitID as the first argument? how does that work?

[yuritch]

That probably means you can control multiple units from the same script (or just cause other units to do things). I'm not 100% sure it's intended to work like that though.

[thesleepless]

That probably means you can control multiple units from the same script (or just cause other units to do things). I'm not 100% sure it's intended to work like that though.

hmm i guessed that.. i suppose there's a variable defined to be the current unit's id.

[Tobi]

Why number axes?

It's fastest, and as yuritch said you can just use symbolic constants (well symbolic variables of course, since Lua doesn't have constants).

Maybe the to-be-written Lua framework will even define these variables automatically.

I don't really see what advantage is has for axes though, it's just an added confusion.

And I'm sure I'm missing something blatant, but really what is the advantage of using radians for the animator?

Radians is a unit known in the world outside OTA. Angles from -32768 to 32767 are used a lot less. Besides that math.sin et. al. operate on radians, many non-OpenGL Lua functions also return or expect radians (e.g. Spring.SetUnitRotation), and Spring uses radians internally.

Since a goal was to make it easier to integrate unit scripts with other LuaRules code, I think it makes sense to consistently use radians in new code.

very excited about this, would love to see an example script also.

i notice the functions take a UnitID as the first argument? how does that work?

Will be coming, I'm not finished yet, although the C++ part is

This is to aid in reusing a script for multiple units. If a script doesn't have static variables the same table of Lua script functions can be reused for all units of that type, because the unitID just gets passed around into the Move/Turn/Spin/etc. callouts.

If a unit has static variables, it either has to create new closures for every unit so the functions for each unit point to their own set of nonlocal variables, or use tables or something. Exact way that will be recommended depends a bit on framework.

That probably means you can control multiple units from the same script (or just cause other units to do things). I'm not 100% sure it's intended to work like that though.

Yeah, as side effect you will be able to move pieces of other units, but I would consider that bad practice (better to call a function in the other unit's script, which then does the animation).

i suppose there's a variable defined to be the current unit's id.

There isn't. That's why you need to pass the unitID to most of the callouts again. I considered it for a moment, but making all callouts state-full in this way would reduce flexibility a bit. For example, no easy way (ie. without CallCOBScript) anymore to trigger some unit animation in, for example, gadget:UnitDamaged.