CA morph gadget: Cmd ID?

[zwzsg]

Let's say there is another mod using the morph gadget from Complete Annihilation:
http://trac.caspring.org/browser/trunk/ ... _morph.lua

Let's say one wants to make a new gadget, and have that new gadget sometimes tell some units to morph. Using Spring.GiveOrderToUnit seems the obvious choice.

So, in that other gadget, I have a unit, of which I know the unitId, of which I know the unitDefID, of which I know it can morph into x. But how do I know the CMD ID of the morph to x command? Looking into the source of the morph gadget, I see each morphing has its own command ID, assigned at run time. Are they stored in some place accessible in other gadgets? What's the best way to find the morph command IDs available for a known unit?

Sure, I could issue all commands between 31210 and 31210+GG.MorphInfo["MAX_MORPH"], or I could hack away the unit_morph.lua gadget to store in a globally shared var a conversion table between unit_def_id and morph_command_id, or other dirty ways. But, this gadget looks so refined already, surely a better cleaner way to retrieve morph command ids is provided already?

[CarRepairer]

I've thought about this in the past as well.

You could modify the gadget so that it always assigns
morph cmdid = 31000 + (unitdefid of unit to morph to)
and have an easy way of getting it later.

This however doesn't cover the scenario where your mod has unit type A morph to type C and unit type B can also morph to type C with a different cost and/or prerequisite. Then you'll need two different morph commands to morph to type C and the above formula won't work.

[zwzsg]

Ok, I've edited unit_morph.lua then.

From CT's unit_morph.lua, I got the impression that Alantai Firestar's Shard can send through gadget:AICallIn messages such as "Shard|morph|45" when it wants to morph the unit of ID 45. This was clearly broken mod-side, but was it implemented Shard-side? Are there other AI that do, or would like to, use morphing? How would AI dev want the morphing gadget to interface with their AI?

Currently I'm populating a table of table:

• key: unitDefID_from
• value: a subtable
  • key: unitDefID_into
  • morphCmdId

Because, yes, a given unit may have several morphing command available, and yes, each morphing has its own command id.

I know how to share a table between gadgets (GG.), but I don't know how would I send it to AI, nor if AI dev want it this way, nor if there's even one AI dev caring about morphing.

morph cmdid = 31000 + (unitdefid of unit to morph to)

Sounds clunky, what if a mod has a thousand unitdefid and it starts overlapping other cmdid? What if two different morph command have the same target unitdefid? And the whole idea of having to recopy the 3100 in other gadgets is ugly.

[zwzsg]

Well, I thought that forcing other gadget or AI to retrieve and make use of that big table of table just to find out the proper command ID for morphing would be horrible. So I added a simpler interfacing method.

All Morph Cmd ID have been shifted by 1.
The base Morph Cmd ID is now a generic morph command id working for every morphing. It takes an optional parameter, the unitDefId of the unit to morph into.

So, an AI or another gadget can morph unit u simply with with:
Spring.GiveOrderToUnit(u,31210,{},{})

If unit u can morph into both x or y, the gadget will pick the first it finds in the morphDefs.

If you want to morph into a y specifically, y being a unitDefID, then use:
Spring.GiveOrderToUnit(u,31210,{y},{})

This should simplify greatly interfacing morphing with AI and gadget.

I still kept the table I talked about in the above post, should other gadget want to know what can morph into what. I don't know how to send such table to AI, but I suppose it would be much easier to have a static AI config file specifying the one unique morph command id, and what unitname can morpth into what other unitname. AI can then easily convert unitname into unitDefId and then issue order to unit it wants to morph.

Nonetheless I not only kept but fixed the gadget:AICallIn I found. However, it does not work because apparently Spring.GiveOrderToUnit from unsynced gadgets are ignored. Would like to know why btw.

I find it slightly unpretty that I stored in GG.MorphInfo both numeric keys corresponding to unitDefIds and string keys corresponding to some constants. Might want to reorganise that. Then I dunno, it's not that important unless you iterate over ever pair and forget to use type(key)=="number" which has thricely no reason to happen.

I thought there may be a reason the CA team used a different command ID for each morphing, so I left that in place. There's just an extra "generic" morph command ID.

[SirMaverick]

I thought there may be a reason the CA team used a different command ID for each morphing, so I left that in place. There's just an extra "generic" morph command ID.

Afaik there was no reason for this. It's just how it was implemented.

[slogic]

I know how to share a table between gadgets (GG.), but I don't know how would I send it to AI, nor if AI dev want it this way, nor if there's even one AI dev caring about morphing.

If morphing can be considered as converting unit of def A into unit of def B and nothing more, then it can be supported by Spring engine (thus such morph command could get _standard_ id). And AI could get everything it needs via API.

[zwzsg]

Afaik there was no reason for this. It's just how it was implemented.

Let's not forget the human interface!

When you push a button, it's the engine that decide what values should the parameters be.

If morphing can be considered as converting unit of def A into unit of def B and nothing more

Different mods might want different kind of morphing. Then morphing are not more varied than building units, which is already handled by engine, so...

then it can be supported by Spring engine

You're going in exact opposite direction of other devs there. The movement is to have less and less in the engine and more and more in the mod's Lua.

And AI could get everything it needs via API.

I figured any AI that handle mods different enough to use morphing would require some sort of config file anyway, where it would be no big deal to declare CMD ID for special actions.

The problem was that with the previous version of the gadget, there was no easy way to know which morphing used which CMD ID. By reading "LuaRules/Configs/morph_defs.lua" you could count in which position each morph is and then try to calculate a corresponding CMD ID, or you could write some temprary extra code to echo the CMD ID you want, but that's convoluted and would have to be redone every time a new morpdef is added or removed.

With my version, there is a single CMD ID, 31210, which is all you need to ask a unit to morph. Sure, in another mod, the modder might have decided to edit the gadget to use another CMD ID just because he could, but then that other modder could also have recoded a wholly different implementation of morphing.

Though I do think the list of who can morph into what should be done by custom UnitDefs tag, instead of "LuaRules/Configs/morph_defs.lua", sounds better to me that an hypothetical AI wanting to know who can morph would look into the UnitDefs than loading a Lua file.

then it can be supported by Spring engine

The biggest problem with having so much code in gadgets and widgets is that, once found, a bug will never be corrected in all copies that spread everywhere.

For instance, no mod will swap their morphing gadget with my one from my thread, which will soon get buried in the forum.

Or yesterday, I playing with unit restrictions, and noticed the Red UI inside lastest BA still has the greying bug I reported and fixed 11 monthes ago.

[oksnoop2]

z, I am trying to use your gadget but like i pointed out to in chat either it, me or the AI is failing at some point. If you would like to see this particular gadget propagate please work with me and help me understand what exactly is going wrong and how it can be fixed.

[yuritch]

With my version, there is a single CMD ID, 31210, which is all you need to ask a unit to morph.

Does your version only support one morph per unit? I ask because some S1944 units can morph into 2 or more different things (factory upgrades), and as I see it, this will require 2 CMD IDs.

[zwzsg]

oksnoop2: At the top of Spread_n_Deploy.lua, change both 31233 and 31226 into 31210.

yuritch: There is an optional parameter, UnitDefID of the target.


I build upon the existing CA morph gadget, I added functionnalities but didn't remove any. The CA morph gadget handles several morphing buttons per unit, my update still does. The only changes is that the first CMD, of ID 31210, is now a "generic morphing command" instead of the "first specific morphing command". The "specific morphing command" work as before, using plenty of command ID. The "generic morphing command" picks the first morphing that unit has when issued with zero parameters, or read what it should morph into from the first parameter if one is given.

So the only trouble you could have would be if you have some gadget or AI where's you have written the id of a specific morpthing command, like I had in oksnoop2's Spread_n_Deploy.lua, then you'd have to shift by one, or replace by my new interface. I doubt there are many such gadgets or AI, as the whole cause of that thread was the lack of a clean way to get those CMD ID. I guess I could have used 31209 instead of 31210 for the generic morph cmd id to avoid that, but that's really nitpicking, since I don't think anyone interfaced with the morph gadget using command id, beside me and my ugly gadget hack for C.T., which prompted me to write the better interface this thread is about.

Edit: Oops, had forgot the case of factories in my modified gadget, and more worryingly, forgot to skip the req in my new interface. Now fixed, I edited my above post to change its attachment.

[oksnoop2]

I think the morph gadget is causing things to turn inside out.

http://img440.imageshack.us/i/screen00002.png/

At least is seems to happen after a unit is built, moved, then morphed.

For instance i built some metaltrucks from the factory and morphed. They turned inside out.

I cheated in some metaltrucks left them still, then morphed they did not turn inside out.

I morphed the very same trucks back into mobile form and moved them. Then I morphed them into storage mode. They turned inside out.

I build a factory and morphed it. It did not turn inside out.

So to my ignorant eyes it looks like they only break after being moved. Since you are the only other one with the gadget i was hoping you could verify. It is happening 100 percent of the time for me under the above circumstances.

http://pastebin.ca/1941742 --Infolog


If anyone has some insight as to why it's doing this that would be great.

[SirMaverick]

I think the morph gadget is causing things to turn inside out.

morph = remove old unit and create new one
So it should happen with units you cheated in, too.

[FLOZi]

I think the morph gadget is causing things to turn inside out.

http://img440.imageshack.us/i/screen00002.png/

At least is seems to happen after a unit is built, moved, then morphed.

For instance i built some metaltrucks from the factory and morphed. They turned inside out.

I cheated in some metaltrucks left them still, then morphed they did not turn inside out.

I morphed the very same trucks back into mobile form and moved them. Then I morphed them into storage mode. They turned inside out.

I build a factory and morphed it. It did not turn inside out.

So to my ignorant eyes it looks like they only break after being moved. Since you are the only other one with the gadget i was hoping you could verify. It is happening 100 percent of the time for me under the above circumstances.

http://pastebin.ca/1941742 --Infolog


If anyone has some insight as to why it's doing this that would be great.

It's a classic bug in morph; iirc to do with not setting cardinal directions for the facing parameter of CreateUnit. Supply trucks used to do it in S44.

How old is your morph gadget / where did you get it? Current CA and S44 versions should not suffer from this bug.

[oksnoop2]

I am using the one Z linked to above.

[slogic]

then it can be supported by Spring engine

You're going in exact opposite direction of other devs there. The movement is to have less and less in the engine and more and more in the mod's Lua.

Here is my point of view. Engine could be called an engine if it speeds up game development. One way of speeding up is creating tools which implements some basic abilities. Currently I'm talking about _standard_ morphing so Engine provides standard command ID & conversion tables which are available via AI API. AI can calculate effectiveness of morphing and take decisions.

If everything is going to be Lua (move, attack & other commands) it means the death of binary AIs and each mod maker should provide its own Lua AI. So, no troubles at all.

Also note, that if game dev gonna make non-standard morphing it will require hacking AI anyway.

If standard morphing covers > 50% cases of morphing requirements why not to implement this in the engine? Game dev then can choose: implement standard morphing and get working AIs for free or make its own morphing and create AIs from scratch.

[zwzsg]

How old is your morph gadget / where did you get it? Current CA and S44 versions should not suffer from this bug.

The one I posted here is made from CA lastest, merged with a couple change I saw in CT's version, and with the addition of my new interface. So it should be up to date. But it's interesting to know the bug oksnoop has with inverted models has to do with with not setting cardinal directions for the facing parameter of CreateUnit, now I know where to look.

[oksnoop2]

If standard morphing covers > 50% cases of morphing requirements why not to implement this in the engine? Game dev then can choose: implement standard morphing and get working AIs for free or make its own morphing and create AIs from scratch.

This would be nice. The less things i have to do to make a cool game the better.

[Licho]

Engine should implement implement features that benefit from being engine-implemented.

Morphing is highly mod-dependent, needs to be customizable and is not performance hungry ->
zero benefit from having it in engine.

[zwzsg]

Morphing is highly mod-dependent, needs to be customizable and is not performance hungry

Same can be said for the process of building units. Building is only handled by the engine for historical reasons.

zero benefit from having it in engine.

The benefit, according to slogic, would be standardisation and the ensuing reusability.

[Licho]

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

We keep changing morphing on the go, there were tens of edits past year, I don't want to wait for next engine version if I need change vital gameplay mechanism.

Also I'm all for moving building into LUA sphere actually! It would solve lots of problems and hacks we have to use.

You don't have to worry about say AI as long as command stays.
And anyway general non-mod specific AI's are imo pipe dream. They are not working well without extensive configuration.