Move some pickup logic to Approaching state from parent Garrison state
to react to state changes among childrens of Garrison state properly.
Reported by: causative
Patch by: causative, Freagarach
Fixes: #5557
Differential Revision: https://code.wildfiregames.com/D2174
This was SVN commit r23268.
cc1ea7cca0 changed order in which cheer order is given and old orders
copied. That lead to replacing all orders with cheering order.
Patch by: Freagarach
Differential Revision: https://code.wildfiregames.com/D2358
This was SVN commit r23267.
Set formation member rotation to the same angle as formation has when
member stays idle.
Differential Revision: https://code.wildfiregames.com/D2469
This was SVN commit r23248.
When unit is idle in formation and promoted, it enters INDIVIDUAL.IDLE
incorrectly.
When unit is moving as part of formation and formation is ordered to
stop, unit enters INDIVIDUAL.IDLE but should keep FORMATIONMEMBER.IDLE.
Differential Revision: https://code.wildfiregames.com/D2468
This was SVN commit r23236.
Formation variants for members are not set correctly once they move
because their ranks changes but variants do not get updated.
This was SVN commit r23233.
b807c39e6a Introduced a infinite loop in which formation members keep
receiving the order to formation walk to their proper position. This was
due to this.formationOffset is not deleted when member gets in offset
position, what means he recieved motion update and it was not because of
failure.
Patch by: @Freagarach
Differential Revision: https://code.wildfiregames.com/D2424
This was SVN commit r23217.
Units can be stuck in gather states when the target ought to be
collectable from, but it's actually unreachable.
A new FINDINGNEWTARGET intermediate state for GATHER will try and find a
new, different target to collect from. This should generally improve the
behaviour (perfect reachability checks would be required to completely
fix it).
Use this also when the target is knowably unreachable / uncollectible.
Fixes#5529
Differential Revision: https://code.wildfiregames.com/D2120
This was SVN commit r22816.
This moves most of what was in the Damage system component to a helper,
and renames that component DelayedDamage.
It also introduces a new global script with all possible attack effects.
Comments Taken From: Freagarach, Stan, bb
Differential Revision: https://code.wildfiregames.com/D2092
This was SVN commit r22754.
Fixes for 5568bd4c16:
- units could occasionally ignore range checks when attacking.
- attacking a formation wouldn't pick new targets correctly.
While testing, I also think the walk then walk and fight behaviour
should be changed to just walk and fight or units might just run towards
enemies and not attack them, which looks rather odd.
Reported By: Angen
Fixes#5530
Differential Revision: https://code.wildfiregames.com/D2119
This was SVN commit r22567.
This improves hunting behaviour, as targets may still be in FOW on the
second try, and the unit would go idle - instead it'll now gather near
position, which is more likely to find a proper resource.
Differential Revision: https://code.wildfiregames.com/D2071
This was SVN commit r22565.
When units are hunting, they push an attacking order in front.
That attacking order keeps track of the target's last known position to
efficiently hunt. However, if the unit goes out of LOS,
ShouldAbandonChase triggers and the unit goes back to the gather order -
which hby then as a hopelessly out of date "LastPos".
By updating the LastPos of the gather order as well, Gather can recover
efficiently.
Differential Revision: https://code.wildfiregames.com/D2072
This was SVN commit r22543.
As reported by #5521, Ordering units to walk to a point in a forest can
lag terribly, as units will end up computing long short paths in the
forest, which can result in `ComputeShortPath` calls that individually
take upwards of 80ms.
This can be alleviated by allowing units to stop a bit earlier. A23
handled this in UnitMotion directly, but it's better to handle this in
UnitAI to avoid surprises and to make it customisable on a per-state
level.
This diff further speeds up using the short pathfinder by starting with
a smaller search range, limiting the max-range more and moving the range
slightly towards the goal.
This also refactors UM sending messages to UnitAI so that we may in the
future push more information (in particular, the entity_id that a unit
was obstructed by could be interesting for COMBAT).
This doesn't fix the possibility of lag, but it reduces its occurrence
to levels that should be similar to A23 and thus acceptable enough.
Tested By: Freagarach
Fixes#5521
Differential Revision: https://code.wildfiregames.com/D2105
This was SVN commit r22526.
This restores A23 formation behaviour, changed by 4ca448a686. Units will
now start attacking nearby enemies when the formation goes idle (such as
when the abort order button is clicked).
This introduces a change that formation units that actually go idle will
try to move back in formation shape, so it looks more like they're still
in formation.
Fixes#5519.
Differential Revision: https://code.wildfiregames.com/D2097
This was SVN commit r22506.
Calls to FaceTowardsTarget were missed in the REPAIRING, GATHERING and
GUARDING unitAI state, leading occasionally to units pointing the wrong
way. This was not an issue prior to 0c20afdfda, which called
MoveToTargetRange, which itself called FaceTowardsTarget when it was
already in range, but it now needs to be explicitly handled in unitAI.
Attacking and Healing already handled this correctly.
Fixes#5518
Differential Revision: https://code.wildfiregames.com/D2096
This was SVN commit r22505.
Entities may never get to a distance of "0" when trying to reach other
entities, as that would mean they are right next to each other, or even
overlapping, which can fail.
Always give some leeway to distance when trying to move to a target with
no specified max-range.
This fixes WalkToTarget orders which resulted in units being stuck on
mines or on dropsites occasionally.
Reported by: elexis
Fixes#5510
Differential Revision: https://code.wildfiregames.com/D2087
This was SVN commit r22496.
The game currently has several infinite loops, and the stack trace is
always a variation on the same pattern that units go through IDLE as a
default state, immediately try another order (possibly entering a new
state), failing, and goes back to IDLE.
IDLE.Timer is a general workaround for this issue. It wastes a turn
every time a unit goes idle, so should a better solution be found for
the general problem of infinite loops in UnitAI, it should be removed.
This revert 8bab09d37c which was intended as a safety net, but couldn't
protect againt infinite loops between two different states.
Fixes#5460
Differential Revision: https://code.wildfiregames.com/D2041
This was SVN commit r22475.
Units move the InitPos of the heard to the last known position when
going through Order.Gather, which they do multiple times when hunting,
thus making them mistakenly move the herd position and unable to find it
back.
Differential Revision: https://code.wildfiregames.com/D2073
This was SVN commit r22471.
Reorder code flow, handle long paths and short paths in a more explicit
manner, and only fail after a certain number of failed path computations
to avoid going idle too easily.
Make sure WALKING orders in UnitAI stop when the move fails to avoid
units being stuck.
Differential Revision: https://code.wildfiregames.com/D1907
This was SVN commit r22464.
This fixes a number of issues with formations:
- Gives the controller an obstruction. This fixes the bug where units in
formations can't gather from a tree.
- Stop special-casing formation members in PathResult. This fixes
formation members being stuck in-place when they run in an obstruction.
- Makes sure units stay in Formation.IDle when they are idle so that
D1337/D1901 can work correctly in the IDLE state.
- Warn if animals enter this state.
- Make sure that formation members that end up in INDIVIDUAL.IDLE go
back to FORMATION.IDLE for sanity and for better housekeeping (refs
#3144 - fixed completely upstream).
Differential Revision: https://code.wildfiregames.com/D2048
This was SVN commit r22447.
Use UpdateMovementState to inform the visual actor of the unit's speed,
which cill update the movement animation accordingly.
The removes the need for UnitAI to handle movement animation using the
special "move" state.
Differential Revision: https://code.wildfiregames.com/D1901
This was SVN commit r22446.
The animation overrides are a little awkward. Instead, use animation
variants, which allow defining different animations (and props and such)
easily for different units in a formation.
This lets us clean up the special C++ code to override the walk
animations.
It continues the work started by 8446b92f1b.
Original Patch By: temple
Differential Revision: https://code.wildfiregames.com/D1337
This was SVN commit r22442.
- Garrisoning cleanup (return true in some cases in ENTER when we do
change the state)
- Fix animal walking speed until D1901 lands
- Fix trading behaviour which occasionally bugged out.
Differential Revision: https://code.wildfiregames.com/D2045
This was SVN commit r22440.
8a38cfb7cf introduced an issue, as it expected "this.order.data.initPos"
to always exist. But going through `GatherNearPosition` did not set it.
Fix this by setting that variable in `GatherNearPosition`.
Use the opportunity to still fallback to the unit's position if the
variable were to not exist for some reason (defensive programming
against future changes).
Re-enable "return resource" behaviour as the final fallback case - The
GatherNearPosition call previously always passed thus this no longer
triggered.
Possible follow-up: try gathering near the dropsite found.
Differential Revision: https://code.wildfiregames.com/D2039
This was SVN commit r22434.
This is a partial revert of 4fda917f46, which skipped the
"MoveToTargetAttackingRange" in APPROACHING. I (incorrectly) assumed
that the original order was still perfectly fine, but in fact the
attacker's max range may have changed as that depends on the relative
elevation between attack and target - and so the original order might
never get us in range!
This was introduced originally in 8c74df2acd.
Add a comment to clarify this.
Further, this makes sure UnitMotion still is aware that it has a target
even if it is in range from the beginning, as that could lead
to stuckiness (and did when chasing sometimes). This was done in D1984
anyways.
Fixes#5478.
Differential Revision: https://code.wildfiregames.com/D2035
This was SVN commit r22429.
In A23, units that are approaching an enemy (Combat.Approaching) will
carry on moving to their last waypoint if the target dies, and then go
idle.
As of 69d3e76fd2, this no longer happens and units stop in their tracks,
staying in attacking forever.
This lets Combat.Approaching explicitly handle the error, deciding what
is best to do:
- go to the next order (for hunting and queued orders)
- find new targets nearby (in case the attack wasn't a forced order)
- walk to the target's last known position and find units to attack
there (in case it was). This is A23 behaviour.
Differential Revision: https://code.wildfiregames.com/D1992
This was SVN commit r22425.
For now, we use the nearest-edge to nearest-edge distance for min-range
checks (following much discussion on D981).
This was missed when committing it in c219ee54b2.
UnitMotion was already correctly not using opposite edge checks.
Differential Revision: https://code.wildfiregames.com/D2031
This was SVN commit r22416.
The reason was that the unit immediately tried gathering nearby instead
of going to the unit's last known position.
Related to D1997.
Differential Revision: https://code.wildfiregames.com/D1996
This was SVN commit r22414.
Due to an issue in 4a15cc3b9f, animals incorrectly tried going towards
the roaming point instead of away from it.
With that fixed, MovementUpdate still did not trigger as the min and max
range were the same.
Use -1 as max range (= infinite) instead since we want to move
arbitrarily away.
Having an infinite max range was broken in c219ee54b2, this
re-implements that.
Further, other calls with equal min and max range have been changed
likewise.
This does not entirely fix whales, which run in other problems because
of their large roaming range.
Differential Revision: https://code.wildfiregames.com/D1980
This was SVN commit r22413.
0c20afdfda made states more caller-independent but did not change some
callsites to be compatible with that. This fixes those.
This does not fix chasing entirely however since unitMotion does not
always recognize that the target moved enough that the entity will never
be in range.
This will be fixed upstream.
Differential Revision: https://code.wildfiregames.com/D1968
This was SVN commit r22367.
4fda917f46 introduced mistakes in range checks which sometimes broke
garrisoning and repairing.
Reported By: gameboy
Differential Revision: https://code.wildfiregames.com/D1963
This was SVN commit r22353.
UnitAI is now solely in charge of moving and stopping, making UnitMotion
behaviour easier to predict, which will ultimately help with unitAI
development. It might temporarily make units more resilient than before
however.
UnitMotion also tells UnitAI that it's arrived with "MoveCompleted"
messages, but these actually could be wrong - unitAI could decide that
we didn't want to stop after all - so change the name for something less
misleading.
Differential Revision: https://code.wildfiregames.com/D1886
This was SVN commit r22351.
"MoveStarted" messages were sent by UnitMotion when the unit started
moving (sort of) or failed to do so. This was used by formations and
guarding but was not really necessary as this can be done in "enter" or
in a timer.
Differential Revision: https://code.wildfiregames.com/D1885
This was SVN commit r22350.
These functions were placed in UnitMotion, which had nothing to do with
range checks and made them available only to moving entities for no
particular reason.
This patch also adds support for square-square range checks and
shape-shape distance checks.
Modified from a patch by bb on top of work from wraitii.
Differential Revision: https://code.wildfiregames.com/D981
This was SVN commit r22345.
Reuse the timer code in the gathering sub-state to avoid broken
duplication.
Reported By: minohaka
Test By: Angen
Differential Revision: https://code.wildfiregames.com/D1956
This was SVN commit r22342.
0c20afdfda had two issues:
- some of the unitAI code did not return true when switching states in
the "enter" phase
- missed a return false in unitMotion.cpp
This fixes the issue noticed by @bb.
Differential Revision: https://code.wildfiregames.com/D1947
This was SVN commit r22339.
This also moves the actual "moving" code to states instead of orders,
making states more self-contained and removing the change of errors when
cleaning up a state.
Differential Revision: https://code.wildfiregames.com/D1865
This was SVN commit r22313.
This:
- cleans up a code duplication and clarifies the intent.
- reorders things around for clarity
- improves variable names.
Commented By: elexis
Differential Revision: https://code.wildfiregames.com/D1840
This was SVN commit r22277.
def47cb7ae had an issue where the move speed was not correctly reset
after chasing a unit.
Reported By: Angen
Reviewed By: Angen
Differential Revision: https://code.wildfiregames.com/D1861
This was SVN commit r22275.
