building system idea

[hokomoko]

Would like your opinions/RFC - hot or not, and is it worth the effort.
(note that I only mention building, but the following will apply for assisting, repairing etc. as well)

The idea is to model the building system after the weapons one (in parallel, these won't be weapons):

A unit will have several "build weapons" it can use, each can aim/operate independently
This will allow:
1) Building while moving
2) Building multiple things at the same time
3) Automatic assisting for nanos without having a patrol order
4) Lots of other stuff I didn't think of.

do try to be clear, concise and to stay on topic.

[Super Mario]

Wouldn't that blur the line between units and buildings?
Did you take your building system take into account when it comes to different types of economies? (Let's try to move away from the hard coded metal, energy logic here)

[Anarchid]

I've been thinking of a moving builder for some time (e.g. ZK mason could be a repairer-on-the-move to have an interesting Vehicle ability).

My problem with the concept was always not the technical impossibility (because it could be done with a builder unit attached to a mobile platform; one moves, while other builds), but the UI.

How do i tell the mobile builder to stop building without stopping to move, or to stop moving without stopping to build?

[hokomoko]

I think it can be kinda like the set target interface.
Assisting Firestate can be amusing too...

[gajop]

Just let Lua handle the *effect* of the unit ability (weapon) with callins+callouts instead?
You've noticed how Flove projectiles heal, and how some games have impulse weapons (although those can be a bit hacky as we both know).

I'm not convinced what you're suggesting can't be implemented right now with custom commands, and having the unit shoot at unfinished buildings while changing the building completed status via appropriate callouts.

I think I would much rather appreciate if the focus was there to abstract weapons into abilities, where each ability is defined by general things such as CD, range, projectile type, valid targets/collision, and similar (all things that still exist), while leaving the result of the impact to the game Lua. This would make it a lot easier to implement a number of arbitrary unit->unit/terrain interactions we can see in other RTS/RPG/misc games.

[Silentwings]

I pretty much agree with everything said by gajop and Anarchid. Some extra thoughts:

I think its quite close to being implementable using only the current weapons infrastructure, but:
(1) The number of weapons a unit can currently have is limited (32?). Moreover, there is persumably a good reason for the limitation.
(2) "Fake" weapon implementations using custom commands and/or SendLuaRulesMsg have no interaction with all the lua callins/outs, textactions, etc that relate to weapons and (if they were to be used for building) build progress/commands too. To my eyes this lack of interaction is absolutely debilitating, so I guess that having the build side of this functionality automatically present from within something like the infrastructure of weapons is the main point of this idea?
(3) I estimate that re-implementing the vast number of associated callins/outs from (2) as "lua calling other lua" would eat far too much perf to be worth it. I don't think the engine can reasonably expect lua to be doing more work, here.
(4) SetWatchWeapon is optional (and generally kept off for most weapons) because it has a cost; afaics to avoid losing functionality you'd need a close equivalent of it to be near perma-on for all "build" weapons.
(5) Iirc its already possible to move/fire any unit/weapon while building anything using FPS mode, although this is due to the wtfness of FPS mode and not really related.

In general I think although from a purely abstract point of view it would gain alot, in practice the difficulty of handling it in the UI would mean that it wasn't much used. Two small things that (imo) would do most of the work would be
(1) A callout to produce (the engines - most games don't want lups here, it seems) nanospray on demand.
(2) A new weapon type that handles the aiming/pathfinding/etc side of firing a weapon (so the weapon has range, los, etc) but once the weapon is fired has zero effect, allowing a gadget to easily pick up and implement an effect of choice. Probably this can be implemented already with a little hacking, but a natural weapon type for it would be much nicer.

Without seeing a more detailed design of the idea, I don't think I can say more.

[abma]

(2) A new weapon type that handles the aiming/pathfinding/etc side of firing a weapon (so the weapon has range, los, etc) but once the weapon is fired has zero effect, allowing a gadget to easily pick up and implement an effect of choice. Probably this can be implemented already with a little hacking, but a natural weapon type for it would be much nicer.

the idea of a "lua weapon" sounds goood. but not sure which events would be useful / required to make it useful.

as Anarchid already wrote, i think its a problem, to make an ui for a single unit with multiple builders.

wouldn't it be more useful, to attach multiple units into a big unit and the attached units can still control their weapons / have their own health / can be still selected / hovered?!

maybe i/we are not aware of the current problem with the current building system. whats the specific issue atm?

[Silentwings]

maybe i/we are not aware of the current problem with the current building system. whats the specific issue atm?

I guess the two big limitations of the current system are,
(1) unit has to stand still to build.
(2) unit can only build one thing at a time.

For me, at least, both of these things are exactly what the games I work on want, so I've no complaints with the current system - but maybe others have more specific use cases?

The use case I do know of is the new airbase mechanics; previously the engine had hardcoded airbase specific behaviour to allow an airbase to heal multiple landed aircraft at once. Now its done somewhat hackily with SetUnitHealth and no nanospray.

[PepeAmpere]

The idea is to model the building system after the weapons one (in parallel, these won't be weapons):

A unit will have several "build weapons" it can use, each can aim/operate independently
This will allow:
1) Building while moving
2) Building multiple things at the same time
3) Automatic assisting for nanos without having a patrol order
4) Lots of other stuff I didn't think of.

Hi, from those few lines i get some idea and I have just few general notes.

• From things you listed I can imagine the most of them can be somehow done using current API and Lua
• I wouldn't say I was not thinking about similar game mechanics, but in general i think there is not strong argument why exactly such feature should have support in engine (e.g. why this should be there and why fuel sim was dropped - its matter of the personal preference, both are objectively similarly universal)
• In general Im for stronger maintenance of current engine with current features or adding modular general and universal updates (personal resources simulation, some AIlib, pathfinding API, animation module, multithreading, etc.). Adding something which presume there some "building" mechanic is way to the similar fuel hell.

So, I you would rephrase it to something like "there is not easily possible to create modular unit where each module is handled as a separate unit/entity and we want to create engine support for it", i think it would get wider consensus easier as well.

Anyway, I appreciate your effort in asking questions and moving the development somewhere so I hope my clearly expressed opinions are not taken as a personal attack.

[hokomoko]

Anyway, I appreciate your effort in asking questions and moving the development somewhere so I hope my clearly expressed opinions are not taken as a personal attack.

Not at all.
It seems that there's a consensus here that my time is best spent somewhere else, which is exactly why I asked this in the first place.

[Google_Frog]

Put effort into improving the weapon system. I think the weapon system is almost at a point where it can fully replicate construction. I have not checked whether the missing features are in Spring because I have not wanted to replace construction. Some potential issues:

• Reclaim - Weapons were bad at targeting features when I last checked.
• Armed Constructors - Weapon targeting in Spring is difficult. For the set target gadget I call SetUnitTarget every slow update because otherwise the target can be overridden. We need the ability to set weapon targets individually and to make weapons which only receive targets from lua, not from inbuilt commands (Attack, guard, firestates etc..).
• Leashing - Moving units into range is fiddly in lua. A function SetUnitWeaponLeash(unitID, weaponID, targetID) would be useful for generalized weapon systems. This function would cause the unit to move such that weaponID has a clear line of fire on targetID, as with the current weapon and attack command. We would also need to set which weapon is the leash for attack commands.

These improvements would also be a step towards a more general ability system. The leashing problem is patched but ManualFire but ideally that command would not need to exist. I don't think replacing construction with generalized weapons would have too much performance cost. We are most of the way there in ZK already, AllowUnitBuildStep is used for priority and to fix the broken resource allotment system.

as Anarchid already wrote, i think its a problem, to make an ui for a single unit with multiple builders.

wouldn't it be more useful, to attach multiple units into a big unit and the attached units can still control their weapons / have their own health / can be still selected / hovered?!

I agree that the main problem is UI. The engine should not try to tackle this problem. A UI for complicated actions such as construction set target will have tradeoffs which are dependent on the requirements of the game. Just provide a decent generalized weapon API to make the mechanics easy to implement. Attaching units into a mega unit is a solution which may work for some games.

(2) A new weapon type that handles the aiming/pathfinding/etc side of firing a weapon (so the weapon has range, los, etc) but once the weapon is fired has zero effect, allowing a gadget to easily pick up and implement an effect of choice. Probably this can be implemented already with a little hacking, but a natural weapon type for it would be much nicer.

We already have script.BlockShot to do exactly this. It does not make sense to make this a weapon type because weapon type controls the basic physics type of a weapon (arcing, propelled, laser etc..). If you want a nanobeam type weapon which never fires then use a avoidNothing StarburstLauncher. If you want it to have 3D range then use a avoidNothing BeamLaser.

[8611z]

weapons that target and fire at units of same team/ally

[raaar]

1) Building while moving

That'd be a interesting change by itself. We could have it as an extra option through unit defs or something (default behavior should remain the same).

After giving the order to build, the unit moves into position and starts building. After that, if given an order to do something else (e.g. move). If the order lets the unit remain in range and doesn't require it to use its builder powers for something else, it should keep building what it was building while still in range.

[Anarchid]

I like the Unit States approach to the UI problem. Something like:
- Busy mode: always apply buildpower to applicable items in range, prioritize ones that were last given order upon. (and walk to freshly auto-acquired targets if not on holdpos?)
- Normal mode: apply buildpower to previously specified targets as long as they are viable, don't auto acquire new targets, cancel existing targets on stop.
- Lazy mode: only apply buildpower on a target specified by a current standing order, don't auto acquire targets.

[PicassoCT]

If you want to encode behaviour, either only expose getters and setters, or make it right - no enumeration, just a dsl for state machines and callbacks from that.