Cheer after combat when no enemy units are in range
rP24034
Actions

Description

Cheer after combat when no enemy units are in range

Cheering as is done now is highly unfair and illogical. Cheering units are immune to all damage for 2.8 seconds.
That means unit A attacking cheering unit B is wasting its attack and doing 0 damage while taking damage from anyone attacking it (unit A).
That can save cheering unit with 1 HP from being killed what is not fair to the attacker.

Changes:
removing immunity to damage while cheering
do not forcing cheering order so unit can respond to attacks
removing cheering from promotion
cheering after unit cannot find more targets(units) while in combat and has nothing else to do
tell units around to cheer as well

Differential Revision: D1977
Reviewed by: Freagarach
Accepted by: goldie, borg-
Comments by: Stan, wraitii

Details

Auditors

wraitii

Committed

Silier

Sep 10 2020, 6:37 PM

Reviewer

Freagarach

Differential Revision

D1977: Cheer after no enemy entities left in range

Parents

rP24033: Allow guards to guard a guarding guard.

Branches

Unknown

Tags

Unknown

Build Status

Buildable 13160
Build 26178: Post-Commit Build	Jenkins
Build 26177: Post-Commit Build (macOS)	Jenkins

Event Timeline

Silier committed rP24034: Cheer after combat when no enemy units are in range.Sep 10 2020, 6:37 PM

Silier added an edge: D1977: Cheer after no enemy entities left in range.

Harbormaster completed building B13160: rP24034: Cheer after combat when no enemy units are in range.Sep 10 2020, 6:42 PM

wraitii awarded a token.Sep 11 2020, 9:24 AM

wraitii rescinded a token.

Tnx god, tnx angen.

See https://trac.wildfiregames.com/ticket/5945#comment:10 & corresponding replay (works on rP24757 to rP24767)

Typical pattern:

Enter Cheer
In Cheering state, get attacked/notice a target. PushOrderFront("Attack", newTarget). This just pushes 'Cheer' back onto the order queue.
Target is killed, FINDINGNEWTARGET::FinishOrder -> Cheering is found -> back to step 1.

The correct behaviour in case (3) would be instead to find new enemies first, because it's quite likely that there are some. In the replay above, the unit actually starts cheering again a whooping 200 turns the initial order.
(this is compounded by the fact that when cheering the entity reacts to attackers, since those might not be the closest unit).

Further, there are issues with the range checks, see inline.

/ps/trunk/binaries/data/mods/public/simulation/components/UnitAI.js
3401–3409	These are somewhat dangerous and rely on assuming that on "enter", there are no valid targets around. Otherwise the entity might suddenly start attacking a new unit that crosses into the range threshold instead of a unit closer. Typically, if the cheering order is queued somehow, it's problematic.
3403	This should probably have been RespondToTargetedEntities ?

This commit now has outstanding concerns.Jan 22 2021, 8:40 PM

wraitii mentioned this in D3452: Fix issues with Cheering and PushOrderFront.Jan 22 2021, 8:52 PM

Enter Cheer
In Cheering state, get attacked/notice a target. PushOrderFront("Attack", newTarget). This just pushes 'Cheer' back onto the order queue.
Target is killed, FINDINGNEWTARGET::FinishOrder -> Cheering is found -> back to step 1.

Ok, this is problematic. I think i would need to do check when queuing orders to replace it.

/ps/trunk/binaries/data/mods/public/simulation/components/UnitAI.js
3401–3409	there are supposed to not to be. only 2 cases when cheering order is accepted are in idle and findingnewtargets. all checks for nearby targets are in enter in findingnewtargets only problematic is idle, when they can get order while they are not really idle [fixed] we got into the state to cheer so we cheer, any checks if we should get into this state should be when processing order
3403	see IDLE
3408	here should be this.AttackEntitiesByPreference(msg.data.added), i think i copied this from combat [fixed]