CA morph gadget: Cmd ID?

[Licho]

Having features in engine just blocks progress and innovation.

For example we would already have things like constructor assistable morph.

Or capturing which makes ally units stop shooting unit being captured.

But because building and capturing is engine implemented and there isn't enough control we can't have them.


Also engine has very slow development cycle and often brings up new bugs. Modders can fix bugs much faster.

[hoijui]

moving commands to Lua is only viable if the engine can still know stuff about the commands, even if it is only for exporting that info to AIs.
if you think native AIs do not matter, forget about the idea in the first place.

[slogic]

What prevents that now? What reusability you mean? What prevents reusability now?

Open Lua prevents standardization. Each mod can have modified copies of scripts. Mod devs need to organize Spring ISO and follow it rules which sounds for me like creating perfect universal AI for you.

We touched two sides of benefits of Spring evolving. Lua gives faster implementation of original ideas & flexibility. On the other side engine gives standardization & very fast implementation of general ideas + all bonuses which depend on standard.

Spring as engine provides (or should provide) basic & convenient functionality with ability to _override_ it. Your complaints about making hacks to overcome some hardcoded Spring logic means this logic is not designed to be extended and should be fixed if the need appeared.

"Lua everything" slogan just makes Spring a GFX + pathfinder extension for Lua language. Viva Lua coders! Others should join or quit.

[CarRepairer]

Having features in engine just blocks progress and innovation.

For example we would already have things like constructor assistable morph.

Or capturing which makes ally units stop shooting unit being captured.

But because building and capturing is engine implemented and there isn't enough control we can't have them.


Also engine has very slow development cycle and often brings up new bugs. Modders can fix bugs much faster.

These could be done if the engine had a general "do something to ally" command type. To describe it a different way, call it a "buff" which would behave the reverse of attack. A unit would buff allies automatically just like the way it attacks an enemy automatically, with the option of turning off "buff at will" like fire at will.

The problem with existing custom command types is there's no nice way to associate it with a "range" which requires the unit to walk up to the target and spawn an effect. You can probably guess I'm thinking mostly of "spells" and such for my mod.

Such a buff command type would allow the modder to rewrite anything, including repair, build, assist with this or that, or whatever.

[zwzsg]

Eh, that's actually a pretty cool idea CarRepairer. I hope you got dev connection so it can get implemented.

Little problem though, how would the Lua inform the engine a given unit doesn't need buffing or has been sufficiently buffed? Because, otherwise, the buffer would cast spell on the first unit in range, forever, without switching.

[jK]

The problem with existing custom command types is there's no nice way to associate it with a "range" which requires the unit to walk up to the target and spawn an effect. You can probably guess I'm thinking mostly of "spells" and such for my mod.

erm:

Spring.SetUnitMoveGoal (used by default commands to get in build-,attackrange etc.)
( number unitID, number x, number y, number z,
[, number radius = 0 [, number speed = unit->maxSpeed * 2 ] ] ) -> nil

[CarRepairer]

The problem with existing custom command types is there's no nice way to associate it with a "range" which requires the unit to walk up to the target and spawn an effect. You can probably guess I'm thinking mostly of "spells" and such for my mod.

erm:

Spring.SetUnitMoveGoal (used by default commands to get in build-,attackrange etc.)
( number unitID, number x, number y, number z,
[, number radius = 0 [, number speed = unit->maxSpeed * 2 ] ] ) -> nil

Okay, but there is no explanation on how this works. radius is how close to the x,y,z it can be? If I call this, how does the unit know it needs to get to its goal before it can activate its command? Do I need to have allowcommand check radius each time and requeue if it's too far? I have never seen an example.

[Niobium]

Okay, but there is no explanation on how this works. radius is how close to the x,y,z it can be? If I call this, how does the unit know it needs to get to its goal before it can activate its command? Do I need to have allowcommand check radius each time and requeue if it's too far? I have never seen an example.

The areaattack gadget makes use of custom command and setunitmovegoal, you could also write up some small tests yourself.

[FLOZi]

http://spring1944.svn.sourceforge.net/v ... eClear.lua

Uses SetUnitMoveGoal, but doesn't use radius (I am also a bit confused over radius)

[knorke]

so how exactly can a widget, gadget or LuaAI morph a unit?
I tried
Spring.GiveOrderToUnit(unitID,31210,{UnitDefNames["bmetaltruckdepot"].id},{})
and variations but it does nothing.

using this version of the morph gadget:
http://code.google.com/p/conflictterra/ ... _morph.lua

[SirMaverick]

31210 is lowest morph command id. Each possible morph gets an own id. So you need to check for proper id.

newData.cmd = CMD_MORPH + MAX_MORPH
newData.stopCmd = CMD_MORPH_STOP + MAX_MORPH
MAX_MORPH = MAX_MORPH + 1

[zwzsg]

knorke: Well, the new ability of my own version of the morph gadget only work if you use that new version of the gadget, you know. Neither CA nor CT bothered to update, so you do have to update the morph gadget with this version yourself.


SirMaverick: Yeah, hence this whole thread, and my making of this version to solve that issue.

[knorke]

yes seems obvious
by oksnoop posting in the thread i asumed he had updated already...

anyway, new problem:
this version of morphing does not align buildings to the 4 facing directions. (both for button triggered and lua triggered morphing)
this is bad for units that morph into buildings.