Spring RTS Engine

Yup... let's talk about this topic.

Upgrade systems (global, individual units) are one of the major game design features Spring lacks. Please, do not clutter this thread with stuff about how upgrades suck- I am not proposing anything that would ever be used for a traditional mod like BA.

That said... let's talk about specific issues:

1. Upgrades need to be of two types: global replacement of Units with other Units, and singular per-unit upgrades that affect one Unit, also by replacing it and passing on certain important gameplay variable values to the new Unit. So far as I am aware, this is 100% OK in Spring- .take/.give will allow for such behavior. And, unlike actually changing Unit variable values for a particular user, which will (and should) cause desync, this should be completely compatible with existing code.

2. The secondary issue is one of UI- how do we provide Upgrade buttons inside of a Builder to give them ability to initiate these changes? How do we hook into the existing UI callouts and make this seamless and integrated with a mod?


My idea on this is very straightforward. Since the LUA GUI code can add/subtract Build icons for any Unit (I don't believe that Builder must == 1 but I'll await confirmation) and since LUA can do things like internal timers outside the normal game-state code, it's perfectly possible to have upgrades that merely cost time, for example. Doing upgrades that cost Metal or Energy, on the other hand, will be a bit harder. We'll need units that can Upgrade that way to have Builder == 1, workerTime != 0, and a buildDistance != 0 (however, a value of 1 is, for all practical purposes, 0) and a buildable "unit" that actually passes a LUA GUI callout when complete, replacing the previous Unit with the new one.

So... to rehash, and give a visual aid, for those who're wondering what I'm wanting, exactly... here's the path for the two types of Upgrade I would like to see made possible (I know that they're theoretically available now, I'm basically asking for somebody to please be a super cool and write this so that modders have it available to put into their mods):

The synchronized modrules lua handle can probably handle
the upgrades as is. It depends on what "game critical" data
needs to be transferred. It can give/take units to specific teams,
and can adjust the available commands (CommandDescriptions)
for individual units. For the global upgrade button, you might
want to attach it to a unit that can do global upgrades (iirc, AOE
used to have something like that).

There still seems to be confusion about what LuaUI is
supposed to do. It should not be expected to give and take
units in a normal game (ie: without .cheat). Even if the .give
commands are run synchronously, the controlling code is not,
and so should not be trusted (instant upgrades for cheaters...)

The synchronized modrules lua handle can probably handle
the upgrades as is. It depends on what "game critical" data
needs to be transferred.

Well, for upgrades to work right, the following data must be stored/retrieved:

Orientation XYZ
Position XYZ
Hitpoints
Experience
Cloaked State
Activated State
If the unit being upgraded is a Builder, then it needs to "remember" what it's working on, or it needs to display a message to the user, something like, "Cannot Upgrade while Building".

There still seems to be confusion about what LuaUI is
supposed to do. It should not be expected to give and take
units in a normal game (ie: without .cheat).

Ok... so how do we change the units without replacing them via .Give/.Take? Does this modrules thing actually alter the values according to parameters? Can we actually do stuff like, "if X is true, increase hitpoints by 10%, if Y is true, increase damage of Weapon1 by 25%", and have them both be true?

Can it reference a whole new FBI/COB/Model, so that we can display a visually-different Unit after upgrades are complete? That, by itself, is a super-big deal, if we're going to make stuff that looks and feels professional.

Can we send a state to COB, letting the COB know that it's time to do some animations while upgrading, do another one when the upgrade is complete?

What I really need, honestly, is simple examples to look at. I'd really like to see scripts that:

1. Can attach an icon to a Mex saying "upgrade mex", that, when hit, will automatically replace that Mex with the Unit of my choice at the end of the upgrade. That's something every mod that uses Mexes needs, which is why I picked it out.

2. Can attach an icon to the Commander saying "upgrade all mexes", that, when hit, will do the same thing as the first script, only to all qualified Units.

You'd also have to store the orientation of all pieces on the unit, whether they're hidden or not, and targetting info and orders - if a unit that's shooting / aiming at another unit is upgraded without this being stored it will look wierd

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.

Guessmyname wrote:You'd also have to store the orientation of all pieces on the unit, whether they're hidden or not, and targetting info and orders - if a unit that's shooting / aiming at another unit is upgraded without this being stored it will look wierd

This you could potentially hide by having a *flash* as the unit is upgraded, so that as the unit model is swapped over, this is obscured by the upgrading FX.

I don't know how you'd keep orders continuous for mobile units being globally upgraded; I don't think you could. But eh, I'm against global unit modifier upgrades from a gameplay perspective anyway

(Things like individual commander upgrades, on the other hand, I am not against)

I'm against global unit modifier upgrades from a gameplay perspective anyway

Those have their place, for StarCraft-like gameplay. And wouldn't it be nice to be able to upgrade all your Mexes everywhere at once, without having to laboriously micro-manage it? It might be a disaster economy-wise, but it'd sure save a lot of hassle...

I support this notion. I like being able to research and unlock tech, In all honesty I need to learn this lua stuff. thinking about it unit requirements is easily possible in the mod side lua correct?

If we ever got upgrade able units gundam would suddenly become much less of a fast paced mod :) not that I mine. I could make a research tree that would yeild really interesting results as far as army contstruction.

I like this. It would add a new dynamic to the game play, and make the "arms race" a bit longer, giving it a little more longevity. However, my question is, can it be implimented without a seperate LUA widget? If it required a seperate widget, it'd be a little more clunky to set the mod up properly, plus you'd have to disable the widget every time you wanted to play a different mod.

The idea in itself is great, but implimentation is a little dodgy.

First of all I though the LUAUI was one project, and the "making units scriptable with LUA" was another, but I may have gotten lost on this... I thing a great way to help the project (unless it slowed everything down) would be to allow units to be scripted with lua instead of an archaic compiler like scriptor...

main reason for this post... the simplest way to do unit upgrades would be to make it a script function to change one unit for another and pass variables to a "just morphed" function in the newly generated unit... scriptors would have to also have access to something to test if there is space to upgrade etc aswell... we also need to have a way to add/remove and script bind buttons... so you could have an "Upgread to Supar PEWWEE!" button on the PeeWee that would show up when a level 2 factory was owned by the player or something and this button would be linked to a script that would end in calling the "morph" function... sorry if I'm not clear here.

SinbadEV:

Yup, you are right. LuaUI, LuaCob, LuaGaia, and LuaRules are all run
n different LUA environments (the latter three having both synced and
unsynced sub-environments. They all share some base libraries, but they
can interact directly.

From LuaSyncedCtrl.h: And LuaSyncedRead.h: Those functions allow you to query, add, and modify buttons.