0ace1b44b2 added setting some animation into a controller state,
but formation controllers don't have any animations.
Probably some code intended for individuals has been copied there
by mistake.
This likely caused the visual system to reevaluate the actor somehow
because the animation didn't exist.
Fixes#8817
Up to now `eslint-plugin-brace-rules` was used to enforce a common brace
style for JavaScript code. This plugin was however updated the last time
over 9 years ago and will be incompatible with ESLint v10, as that
[removes `context.getSourceCode()`][1], the plugin relies on.
To keep the eslint config working with ESLint v10, this replaces
`eslint-plugin-brace-rules` with the [`@stylistic/brace-style`][2] rule
from `@stylistic/eslint-plugin`, a package we already use.
While `@stylistic/brace-style` doesn't offer an option to format braces
in exactly the same way as before, the "allman" style seems to be the
one closest to the existing code.
[1]: https://eslint.org/blog/2025/11/eslint-v10.0.0-alpha.0-released/#removed-deprecated-rule-context-members
[2]: https://eslint.style/rules/brace-style
Co-authored-by: @Vantha
Add 'isIdleConfirmed' flag to distinguish between
entering IDLE state and being confirmed idle.
Only send 'MT_UnitIdleChanged' messages after the
100ms timer elapses while still idle,
preventing spurious notifications for units
that instantaneously enter and leave IDLE.
This prevent the GUI to display a flickering idle count
in most cases, for example.
Refs : #8591
Remove the ResetIdle method that was causing issues with the
'Stop units' command in formation combat
The method was originally added to prevent formation members
from appearing idle during patrol waypoints, but formation
controllers or its members no longer enter idle states
even without it
The ResetIdle method was sending MT_UnitIdleChanged messages
causing formation members to bug when using stop commands
Fixes: #8546
Co-authored-by: @Vantha
Centralize all calls to move units into formation in UnitAI
Allowing additional checks to be done
before calling members to reform formation
Fixes : #8545
Revised Formation methods and when they do call
on reforming formation
Fixes : #7328
Don't order formation members to go to a point
if the controller is stuck
Instead make the controller jump to the member
who is closest to the destination
Fixes : #8543
Correct 'filter(member)' instead of 'filter(ent)'
in GetClosestMemberToPosition (ex GetClosestMember)
Fixes : #5120
In case a healer is currently healing and is part of a selection ordered
to attack the healer gets moved along but the fsm state isn't changed
which leads to healer healing while gliding to the target.
Introduce a WalkToTargetRange function which does transition state in
addition by issuing an order instead.
Fixes: #6134
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
-During each attack on a low preference target unless player-directed, update the range query and find a new target.
-Adjust behavior for elephants to work better versus infantry.
fixes#1488
Since 71a61d5f50, formations regularly regroup. However, units already at their correct offset should remain idle. This doesn't happen as we cannot check if we are at destination.
This exposes that and handles things properly... Unfortunately UnitAI has already left the IDLE state at this point, so we still get counted as no-longer idle for a turn.
To fix this, try and detect that particular situation without triggering infinite loops.
Who says only players should be able to conduct diplomacy?
Also separation of concerns, more maintainable files.
Differential revision: https://code.wildfiregames.com/D4921
Comments by: @elexis, @Stan
Refs. #5894
This was SVN commit r27722.
Similar trick to D3446 / c87229aa48 - we can short-circuit if we find
units that match our best possible preference.
This is, in particular, almost a 40% wall time improvement on Combat
Demo Huge, but it should apply in a number of more normal cases.
Differential Revision: https://code.wildfiregames.com/D5020
This was SVN commit r27701.
Causing units to not show the gathering animation when close to a
dropsite.
We might want to move this stuff to their respective components.
Differential revision: https://code.wildfiregames.com/D4937
Comments by: @Stan
Fixes#6566
This was SVN commit r27550.
Discussed countless times on the forum.
We try this out this release.
Patch by: @marder
Differential revision: https://code.wildfiregames.com/D4697
Idea accepted by: @asterix, @wowgetoffyourcellphone, @chrstgtr
Comments by: ^ + @Stan
This was SVN commit r27399.
The motion parameters were calculated even without members, which caused
us to try set a undefined passclass.
Also were members added to previously merged twin-formations. Once
merged (i.e. disbanded), they are moved out of world now.
Some cleanups/deduplication whilst at it.
Reported by: @andy5995 at the forums
(https://wildfiregames.com/forum/topic/71578-feedbacks-from-a26-svn-tests/page/8/#comment-505078)
Differential revision: https://code.wildfiregames.com/D4727
Comments by: @Langbart, @marder
Tested by: @Langbart
Fixes#6580
This was SVN commit r26993.
Improves their functioning significantly.
Based on a patch by @lyv
Differential revision: https://code.wildfiregames.com/D4666
Reviewed by: @marder
Comments by: @Stan
This was SVN commit r26956.
As well as patrolling.
Formations kept moving, finding targets and instructing their members to
attack (thereby resetting their attacking state every time).
We now move into `MEMBER` upon finding a target.
Differential revision: https://code.wildfiregames.com/D4550
Comments by: @Stan
Fixes#6461
This was SVN commit r26741.
They fled whilst healing and not when idle. That is the other way around
than expected.
Introduced in healing introduction (c56f96040e); #999 specifically made
them flee, but it left quite undefined behaviour.
Reported by @BreakfastBurrito_007 on the forums somewhere.
Differential revision: https://code.wildfiregames.com/D4532
This was SVN commit r26618.
One needs UnitAI to be able to use a formation, so include the spec
therein (to keep information close to where it is used).
Modders can change their templates with the following script:
https://code.wildfiregames.com/P261.
Differential revision: https://code.wildfiregames.com/D4443
Comments by: @Stan
Idea accepted by: @wraitii
Fixes: #6399
This was SVN commit r26235.
`ElevationBonus` is vague, as discussions proved. Therefore it is
renamed to `Origin`, which, describes better what the value stands for.
`Delay` is also quite vague, so renamed to `EffectDelay`.
Differential revision: https://code.wildfiregames.com/D2016
Comments by: @bb, @nani, @Nescio, @Silier, @Stan, @wraitii
This was SVN commit r26074.
There was an infinite loop:
Order.Gather -> MustKill (L497) -> PushOrderFront(Attack) (L526) ->
NotInRange (L410) -> NotAbleToMove, thus finish order (L426/427) ->
Restart from Order.Gather.
We do two things here:
- Assume we don't have vision when garrisoned, which is not a bad
assumption.
- Check the range and if we are not able to move and not in range,
finish the order.
Introduced in: d3c3072c83
Reported by: @Langbart
Differential revision: https://code.wildfiregames.com/D4349Fixes: #6377
Tested by: @Langbart
Comments by: @Silier, @Stan
This was SVN commit r26044.
FinishOrder called SetWaitingOnController, although the order
(constructing) had pushed another order (gather).
This is done now by telling we finished the order only when really idle.
This seems to boil down to the question: If we issued an order to a
formation, and its members have wandered off (imagine attacking an
entity and our members have finished the initial target but attack
nearby ones) do we want the whole formation to continue attacking or
execute the next order.
Also fixes reforming whilst attacking when an attack order was issued by
the player.
Reported by: @Langbart at https://code.wildfiregames.com/D2175#182343
Differential revision: https://code.wildfiregames.com/D4282
Tested by: @Langbart
This was SVN commit r25947.
Fixes an infinite loop when the next treasure is outside LOS.
Differential revision: https://code.wildfiregames.com/D4286
Comments by: @Angen, @bb
Fixes: #6329
This was SVN commit r25946.
This allows a player to task entities to drop off their resources and
subsequently attack-move to a specified location with one button.
Patch by: @JCWasmx86
Icon by: @Stan
Differential revision: https://code.wildfiregames.com/D4149Fixes: #1364
Comments by: @Langbart
Based on a patch by: @Freagarach (https://code.wildfiregames.com/D1868)
This was SVN commit r25868.
Introduced in c87229aa48, FindWalkAndFightTargets returns after the
first UnitAI finds a target, instead of also querying the rest of the
members.
Differential revision: https://code.wildfiregames.com/D4208
Comments by: @Stan, @wraitii
Fixes: #6260
This was SVN commit r25847.
Attack orders can be and looks like are pushed in front of formationwalk
order.
That is generally also logic in single entity behaviour.
In case formation gets destroyed and then target dies, attacker is
supposed to stop attacking target immediately.
That essentially leads to getting to old formationwalk command, what was
not issue for packable units until 674cdae166, that introduced
formationcompoennt into the order.
Hovewer abandoning this order without being in formation makes more
sense. Probably this one and FormationLeave should be FORMATIONMEMBER
specific commands and error out in INDIVIDUAL state, but thats too much
refactoring and potential rabbit hole.
Differential revision: D4206
Reviewed by: @wraitii
Accepted by: @asterix
Fixes: #6263
This was SVN commit r25845.
When tasked to gather, entities looked for resources close to their
current location when the target was invalid (e.g. full).
Now on forced orders the entities will look for resources close to that
order's location, when possible.
Differential revision: https://code.wildfiregames.com/D4146Fixes: #6085
Reviewed by: @Imarok
Tested by: @Langbart
Comments by: @marder, @Stan, @wraitii
This was SVN commit r25776.
Formation controllers that were about to be destroyed could bug out.
It's plausible this bug would also happen with regular units, but
couldn't reproduce.
Differential Revision: https://code.wildfiregames.com/D4110
This was SVN commit r25730.
This overall decreases the deathball effect from units walking to each
other a bit.
- Fix formations - this cleans up a UnitMotion hack for formations,
making it possible to increase pushing ranges without breaking closely
knit formations like testudo.
- Make MINIMAL_PUSHING and the MOVE_EXTENSION configurable, and add a
STATIC_EXTENSION as well.
- Increase the pushing range significantly, making units sparser.
Differential Revision: https://code.wildfiregames.com/D4098
This was SVN commit r25708.