Allow to cancel trade route setup when only origin market is set.
Reported in D2285.
Differential Revision: https://code.wildfiregames.com/D2643
Reviewed by: Freagarach
Reported by: Freagarach
Comments by: elexis
This was SVN commit r23521.
delete not needed variable
var -> let
rename nearby variables to reflect what they are referencing
Differential Revision: https://code.wildfiregames.com/D1940
Comments by: Stan, Polakrity
This was SVN commit r23497.
Move call to SetDefaultAnimationVariant to leave function upon leaving
GATHERING state instead for every one substate leave.
Differential Revision: https://code.wildfiregames.com/D2565
This was SVN commit r23474.
Function introduced in 6bc99c47e1, GetRange can return undefined when
required component does not exist. Fixing two oversights, when check is
needed.
Differential Revision: https://code.wildfiregames.com/D2608Fixes: #5666
This was SVN commit r23471.
Do not create range query with no enemies as that triggers warning in
range manager.
This situation occurs when player has no enemies so empty list is
returned.
Fixing CCmpRangeManager: No owners in query for entity 0 warning
refs 38b2e37a61
Differential Revision: https://code.wildfiregames.com/D2601Fixes: #5666
Reviewed by: @Freagarach
This was SVN commit r23467.
This patch unifies the different GetRange calls to one function in
UnitAI. Split from D1958 and makes further changes to be done easier at
one place.
Differential Revision: https://code.wildfiregames.com/D2328
Patch by: @Freagarach
This was SVN commit r23465.
Update this.repairTarget in UnitAI when target renames.
Transfer builders among renamed entities.
Differential Revision: https://code.wildfiregames.com/D2360
Patch by: @Freagarach
Comments by: Stan, elexis
This was SVN commit r23449.
Status effect can apply modifier to the entity (armour strength, walking
speed, ...)
This is also hiding status effect icons by default in selection detail.
Fixing smaller related bugs.
Differential Revision: https://code.wildfiregames.com/D2281
Patch by: @Freagarach
Comments by: Stan, wraitii
This was SVN commit r23448.
Fixing oversight from e7ab2c9b3f. Switching to columnar formation,
adding or removing formation members does not reset animation variant
passed by last order.
Also adding remaining combat variants for formationwalk.
Differential Revision: https://code.wildfiregames.com/D2556
This was SVN commit r23359.
In 4ca448a686 : Make sure that formation members that end up in
INDIVIDUAL.IDLE go back to FORMATION.IDLE for sanity and for better
housekeeping
Differential Revision: https://code.wildfiregames.com/D2558
This was SVN commit r23357.
Allows to pass variant name when moving units to formation used by
UnitAi when formation is moving. That variant will be passed as
parameter of order FormationWalk so formationmember can set requested
variant.
This passed variant will be ignored if formation defines own variant
based on position of member.
When none of above is true, that means nor formation nor order defines
variant, member will fallback to default variant in order to show
carried resources if has some what makes it more consistant with
animation variants used in individual state.
Differential Revision: https://code.wildfiregames.com/D2550
This was SVN commit r23352.
After formation member ends walking, he tries to face target point.
However that eliminates rotation set by SetInPosition from formation
component. Partly fixed in 9d0b4db973 with setting correct rotation in
idle state, but one could still notice that there is glitch when unit
does quick turn to target point and then back. However that solution
would be still required if logic in SetInPosition would not be changed
to always set correct rotation. Another alternative would be to unset
unit at position with every walking order but that would have the same
effect and this is just more performance friendly to not splice member
from position every time.
Notice that information from inPosition is currently not used, so that
change in it is not braking anything.
This was SVN commit r23346.
When entity is in "enter" phase of state and it was called SetNextState,
code have to return true in order to abort current state to work
properly ( else return false ).
Differential Revision: https://code.wildfiregames.com/D1943
This was SVN commit r23300.
Cancel packing when next command requires unpacked state and cancel
unpacking when next command requires packed state.
Fixing unit refusing to move because keeps unpacking to attack targets
in range.
Partially Fixes: #4015, #5328
Differential Revision: https://code.wildfiregames.com/D1520
Patch by: @causative
Comments by: elexis, Freagarach, Stan
This was SVN commit r23298.
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.
