[PATCH] Turrets and/or sub-units

[Annar Hiid]

Currently an unit cannot have several pieces that animate independently, which is a great downside of the animation and unit system.

Adding some sub-unit system that could do this would greatly improve the usefulness of the engine and allow a lot of interesting stuff to happen, for example:

• Units capable of attacking on move without looking silly, e.g horse archers, chariot archers and modern tanks.

• Possibly, multi-actor animation stances (if one unit is allowed to assume ownership of another to achieve perfect visual position sync) - i.e, TotalWar or Dawn of War-like combined combat choreography sequences.

I do realise that the current state of 0ad the game can live without it well enough, and that implementing this feature would require visiting upon some rather innermost alcoves of pyrogenesis the engine. So "Nice to have" :)

[sanderd17]

A proposal

[sanderd17]

Here I have a proposal for turrets. IMO, the simulation position of turrets is important. It could have a separate attack (and mostly will), with a separate range etc. As the prop positions are not synchronised, it can't be derived from that. So I made a TurretHolder where you have to define the turret position relative to the main entity.

The CmpPosition is also made aware of turrets, and updates the turret position based on the parent position in the simulation. The visual position is calculated separately though, it uses the same transformation matrix as prop points, so non-network synchronised stuff (like position interpolation, or terrain alignment) doesn't cause visual problems. It is possible however that the visual and real position are slightly different.

By allowing complete entities as props, you can also make them selectable (e.g. to view some stats specifically for those turrets, like a different attack). You can give them health (so make it possible to first kill the turret, and then the main entity), and a whole bunch of other stuff.

I made the TurretHolder so that entities can have default turrets, but other components (like GarrisonHolder) can add any entity they want to it on a certain position (and also take them off again).

[sanderd17]

In 15246:

Add the Engine code for turrets + use them to get units on walls. The scripted TurretHolder isn't included due to lack of usability for now. Refs #2577

[sanderd17]

Not completely fixed yet. The map saving problems in atlas aren't resolved yet for objects that should start with a turret. So you currently can't create units with turrets by default at all.

[sanderd17]

Added some scripted stuff to turrets. Including a TurretHolder. Note that for working with Atlas, the init should be refined. There's also a TurretAI, based off BuildingAI. I see the diff is a bit messed up, so you might first want to copy BuildingAI.js to a file named TurretAI.js before applying the diff.

The TurretAI now works like BuildingAI, in that the Turret automatically chooses its targets. But once a target is chosen, it rotates towards that target, and sticks with it (to not rotatte like a mad man every second).

It needs refinement for sure, so I'm not eager to commit it without having some unit where it's really needed.

[sanderd17]

New patch, here turrets are not selectable, the main entity can't attack, but the attacks go through the turrets. The turrets will always attack anything near, but listen to attack commands from the main entity.

I'm not too happy with my changes to Attack.js. But disabling the attack for the main entity, while letting UnitAI believe it can still attack required either lots of changes to UnitAI, or a duplicated prototype under the IID_Attack interface. I think the changes to Attack.js cause as few problems as possible.

I also modified all chariots with at least two people on it. One is the driver, and can't attack. The others are turrets and can attack. Notice that it works with multiple turrets, see Ashoka. Tell me if I forgot a chariot.

[Josh]

1. The TurretsOnly option seems useless. I can't think of any case where an entity should only be attackable by a turret.
2. Attack.js never updates latestTarget so GetLatestTarget will always return INVALID_ENTITY, but as latestTarget is only used in TurretAI it shouldn't be stored in Attack.js anyway.
3. There are some extra brackets starting line 174 in TurretAI.js (on your if and for blocks).
4. More Doxygen style function documentation never hurts.

[Stan]

Don't know if it's linked to what Josh said but if you play in atlas, garrison units in a wall and save, then reload the map, units are said to be in an invalid state.

[Itms]

Hi Sander, given that you have less time to dedicate to the game currently, I'll push that to A18. Feel free to revert the change if you want to commit this patch before freeze.

[Stan]

It seems we already use it in a mod : this topic is relevant http://www.wildfiregames.com/forum/index.php?showtopic=18452

[leper]

Replying to Josh:

1. The TurretsOnly option seems useless. I can't think of any case where an entity should only be attackable by a turret.

You got that wrong. The flag is so a unit can only attack with its turrets.

In addition to the other comments:

• TurretAI.js has a strange comment on line 102.
• Some cleaning up of comments couldn't hurt (starting with capital letters and related issues).
• s/var/let/g This changed since the patch, but I wouldn't add new code without that now.
• SM now supports default values for parameters (TurretAI.SelectAnimation)
• There is still the TODO for Atlas.
• Are there some changes in UnitAI needed that aren't included?

[Itms]

Backlogging due to lack of progress.

[Stan]

Rebased version for r17136

[Stan]

Remaining :

• Atlas Todo (I need help)
• Best way to get the attack
• This could be extended to every cavalry units would fix the stuttering units.
• This needs to be extended to every turret compatible units (chariots,elephants)

[Stan]

This patch follows the order of the the parent, so it can capture, and attack while moving. Since the parent is always sending attack commands though, it will only be able to attack on unit at a time. Still need the fix for atlas, and * maur champion chariot * hero darius * hero xerxes Apart from that it's functionnal

[elexis]

Notice the men on the mauryan war chariots also walk when the chariot is being moved. Sounds like this ticket would/could solve this issue then too.

[Stan]

Attached patch fix the bug quoted above. It's totally unrelated to the ticket so can be commited separately.

[elexis]

In 17346:

Fixes a bug in the mauryan warchariot walk-animation. They were walking instead of standing on the chariot when it moves.
Patch by Stan. Refs #2577.

[bb]

Based on patches above I made some system for subunits where the turret has its own unitAI, so it can take orders and stuff. See ​https://github.com/bb-bb/0ad/tree/t2577_subunit

The concept I try to achieve is to have a turretHolder (with a unitAI or BuildingAI) and on top of that turrets. These turret may also be turretHolder of themselves. The turretHolder and turret can communictate with eachother via TurretHolder and TurretManager, turretHolder for messages from holder to turret and TurretManager for the opposite direction. The turrets of themselves also have a unitAI or BuildingAI. The turrets for now can't be selected (as they would cause some problems in the gui) but they do get orders from input.

Some notes:

• The git has template changes for all champion cavalry as test, but this can be extended, this is just a test.
• Test fails, but playtest works
• Patch have some deprecated logic e.g. the CanMove logic can be removed I guess.
• In this approach all units need the TurretManager component, maybe this can be changed.
• Visible garrison (wall) should be done the same way.

refs #4000

[Stan]

Hey thanks for working on it, I really appreciate it :)

[Imarok]

Move tickets to Simulation as UI & Simulation got some sub components.

[Freagarach]

In 25192:

Allow to specify subunits on creation.

This basically does two things:

• Allow turrets on moving entities (fixes serialisation in cmpPos).
• Allow an entity to be present on another when the other is created.

That makes it basically a boiled down version of a prior patch, omitting the part where orders could be passed on.
This does allow e.g. ranged units on chariots that fire while the chariot moves.

Original diff by: @sanderd17
Redone by: @Stan
Differential revision: D1958
Comments by: @Alexandermb, @Angen, @bb, @Langbart, @Nescio, @Stan, @wraitii
Refs. #2577 by implementing the entity on platform case.