Veteran Unit Morph
Moderator: Moderators
I would add a new script command, morph-to("unitname"); and leave it up to the scripter to choose the condition he wants. I think it would be best to use only the FBI of the unit it morph to, and keep the script and model of the previous unit, because otherwise the unit would have to be reseted every time it morph, which would be bad because then the script has no way to keep track of what's going on, and the animation would jump, and stuff.That is an excellent list, zwzsg, but if you were trying to program those how would you do it in one definition?
If we force morphing inconditionnaly, then could have issues with for instance a small unit morphing into a unit with a larger footprint and ending stuck in a nearby feature, or a plane morphing into a kbot at the wrong moment and falling where kbot shan't be, etc... I'd rather execute the morphing command nonetheless and leave it up to the modder to make sure the morphing can't have annoying sideeffect, but if the engine had the possibility to refuse to do the morphing because of unsuitable terrain, then we'd need a way to inform the script the morphing was refused.
But I have no idea of the internal representation of unit in Spring and so don't know if it is possible to change the FBI property of a unit on the fly, while keeping position, hitpoints (or better, rescale hitpoints to new maxdamage), weapon reload state (yet while changing the weapons), damage, script and model state, etc... And we'd have to modify Scriptor to add the new command, because frankly, hijacking TA:K play-sound(...); is the ugly.
I think it'd have to be "morph-unit(1);" with references being placed in the fbi since the script can't contain unit names. And besides, I think the rules that define the unit's gameplay function should be kept in the fbi as much as possible.
And how about a "safe-morph" that checks if the morph can be done to that unit type (i.e. if this unit was gone, could the morph target be built at its position?) and if not refuses to morph while returning some error code? Could even tell other units in the area to get out of the future footprint.
Not sure how to carry values from different units but at least a unit that was morphed to should have a function "Morphed()" called so it can behave differently. Hm, how about making the morph call have parameters in addition to the desired morph that get passed to the Morphed function of the new unit? This same system could be modified to allow spawn-unit as well with the same parameters (though maybe to a Spawned() function instead of Morphed()).
And how about a "safe-morph" that checks if the morph can be done to that unit type (i.e. if this unit was gone, could the morph target be built at its position?) and if not refuses to morph while returning some error code? Could even tell other units in the area to get out of the future footprint.
Not sure how to carry values from different units but at least a unit that was morphed to should have a function "Morphed()" called so it can behave differently. Hm, how about making the morph call have parameters in addition to the desired morph that get passed to the Morphed function of the new unit? This same system could be modified to allow spawn-unit as well with the same parameters (though maybe to a Spawned() function instead of Morphed()).