1. Upgrades need to be of two types: global replacement of Units with other Units, and singular per-unit upgrades that affect one Unit
Upgrade needs to be of
three types: Global replacment of units with other units, singular per units upgrades that affect one unit,
and unlocking new build buttons.
For the two first types, I'd just like a is-there-such-unit-in-radius("unitname",[800]); script command (where "unitname" can also be a techname), and a morph-into("unitname"); script command that'll replace the FBI of the units with the FBI of another unit, while keeping the same model (or a model with similarly named pieces), same bos, and most importantly, without reseting them. That way, the unit can be animated to play a cool smooth transformation, the aiming isn't reseted, the action is was doing is kept, etc... The only problem I see with that is that if a unit with a small footprint is changed to a unit with a large footprint, then maybe the large unit could be stuck. I don't remember if in that case units can unstuck themselves, or remain stuck (which would be an issue). Also, weapons would be switched from old to new while keeping all variable like how long till next shot is loaded, target (if target applicable to new weapons), etc... but if the reloadtime of the new weapon is shorter than the reloadtime of the previous weapon, and that the previous weapon had just fired, then we'd have to wait only the length of the shorter reloadtime of the two.
However, maybe people would prefer to have a harsh transition between two completly different units, in which case we'd need to change and reset the script. Ideally, the morphing of a unit into another would check if the new model has the same pieces as the old model (just a texxing change), if so keep the same script without reseting it, if not quit current script and start new unit script (but maybe without reinitialising the static-var so the new unit still has some memory from its past form?). For a 3do with same piece but different origins, well it depends if the piece position is stored in absolute or relative. If piece position is stored relatively to their origin in the 3do, then no reset, if the piece position is stored in absolute (relatively to unit origin), then we need to reset (reset the script after a morphing into a unit with model piece with same name but different origins).
I'll try to sum that up:
- Unit script performs morph-into("unitname");
- The engine check if the new unit model is compatible with the old script.
- If yes, it simply change the FBI properties, while keeping and NOT reseting the previous script.
- If no, it changes and reset to new unit script, in addition to switching to new FBI properties.
- Either way, all units variable such as the target and reload state of every weapons is kept as best as possible whenever applicable.
Sometimes, the place the old unit isn't suitable for the new unit. For instance, a 1x1 unit in a tight place can't morph into a 4x4 behemoth without getting stuck, or a plane can't change into a ground unit if it's over impassable terrain. I guess for now we can just morph nevertheless, leave it up to the modder or the player to not do stupid thing like morphing ground units into boats, and if they do they'll just get their unit stuck, that bug would a small price for all the possibilties opened. But, to do things more cleanly, we'd need a way to not morph if it's unsuitable. Personnaly I'd like a script command to test if a place is suitable for a unit, like is-place-suitable("UNITNAME",xz); which would be also very useful for things such as automatic unloading and teleportation. However I guess it'll be easier to code a try-to-morph-into("unitname"); which would only work when possible. Or would be delayed until it becomes possible, I dunno what's best.
For the third type, tech research unlocking buildbutton, I propose to treat them like units, with FBI, but their FBI would be very small, it would only contain the unitname, the time, metal and energy cost, and a special tag saying they aren't units but "research". They'd be built by factories or cons or anything with buildpower, but however building them wouldn't create any real unit with model, script, collision sphere etc... just it would write somewhere in memory that this tech has been researched. And I suppose we'd need to disable the buildbutton once the tech has been built cause it's useless to build more than once the same tech. But we already have per unit unitlimit, right?
And then, either in the FBI of the unlocked units, either in the /download/*.tdf /guis/*.gui /gamedatat/sidedata.tdf, we'd have a new tag saying "this is only unlocked when tech X is available". Preferably with "tech X" being either such a researchable tech, or simply a unitname. So people who would like their research to be some vaporous variable, like in Starcraft, can have it, and people who prefer their tech to be a solid building, can too.
Having the UnlockedBy in the buildmenu instead of the FBI of the unlocked units would allow thing such as: Level 2 mech are normally buildable by level factories, but if you build an upgrade, then other factories or cons are allowed to build them to.
Hmm, my post has nothing to do with LUA or Argh pretty diagramms. I hope it's not out of topic.
