FindWalkAndFightTargets is used during attack-walk (and a few other
situations) to find new entities to attack. This function can be a bit
slow, taking large chunks of time during battles.
This optimises it by assuming that one of the surrounding unit will
match preferred criteria (which, for most soldiers, are 'Human'), thus
returning the first attackable entity. In the worst case, it should
still be slightly faster than the current code.
Differential Revision: https://code.wildfiregames.com/D3446
This was SVN commit r25102.
Which were autofixable, with slight modifications.
Not done are the slightly more complex changes.
Refs. #5524
Patch by: @Krinkle
Differential revision: D2279
Comments by: @elexis, @Stan
Reviewed by: @wraitii
This was SVN commit r25087.
HEAL can infinite loop: if the HEAL.APPROACHING:MoveTo call fails, the
unit will fallback to FINDINGNEWTARGET, which looks for new targets to
heal, which can loop around.
In #6106, the cause was that the target was not visible despite the
order being given (presumably a rangemanager/los incompatibility issue).
When MoveTo() fail, orders usually call FinishOrder as that's
irrecoverable.
Further, GATHERING/COLLECTINGTREASURE also did not FinishOrder - there,
we do want to consider new resources if the target is e.g. unreachable,
so add an explicit check for AbleToMove.
Reported by: moiman
Reviewed By: Freagarach
Fixes#6106
Differential Revision: https://code.wildfiregames.com/D3689
This was SVN commit r25075.
The "GARRISONED"-state was quite strange, for entities being garrisoned
can just as well perform other tasks (see e.g. turrets).
Also, the need for keeping a "garrison" order on the stack is removed.
Fixes: #6022
Differential revision: D3656
Refs. #6081
This was SVN commit r25069.
Since the only way of garrisoning is using `cmpGarrisonable`.
025a00340e introduced the `this.isGarrisoned`-flag, its meaning was
discussed in https://code.wildfiregames.com/D1403.
Refs. #5979, #6081
Differential revision: D2379
Comments by: @elexis, @Stan, @wraitii
This was SVN commit r25030.
This should bring the behaviour back to pre-A24 and means entities will
stray a lot less when gathering.
The entity will search close to the current position, which is mostly
next to a dropsite.
When there is nothing found there, the entity searches nigh the initPos.
Differential revision: D3607
Comments by: @wraitii
Tested by: @Nescio
This was SVN commit r25000.
Follow-up to ea96e81098.
Also adds the ability to gather near a position (e.g. when ungarrisoning
with a rally point set on a treasure that is gone).
Gathering treasures should now behave exactly the same as prior to the
split.
Differential revision: D3580
Comments by: @wraitii
This was SVN commit r24999.
Removes some hardcoding and allows for easier modding of treasures.
Refs.: #5888
Differential revision: D3303
Comments by: @Imarok, @Nescio, @Stan, @wraitii
This was SVN commit r24989.
Fixes d038b3c4f2, by partially reverting it.
If the new order is rejected, PushOrder() will call FinishOrder. If
there are no more orders on the queue, this calls SetNextState("idle"),
with the intention os switching the unit to IDLE. However, this only
works from within an FSM call, and thus does nothing if a new command
gets rejected.
The problem is that this.order/this.orderQueue is already replaced by
the point the order is rejected when called via ReplaceOrder. Ideally,
this would not happen (but doing so isn't trivial).
The current code avoids having 2 different ways to reject an order, thus
isn't a complete revert of d038b3c4f2. It triggers an IDLE re-entry that
wasn't there before if the unit is IDLE when it receives the rejected
order, which at the moment basically never happens.
Refs #5771 (reopened)
Reported by: gameboy
Comments by: Freagarach, Angen
Differential Revision: https://code.wildfiregames.com/D3618
This was SVN commit r24978.
Allows entities to change their resource amount over time, possibly with
some constraint.
This is a not-so-bare minimum, but can certainly be improved and/or
extended later.
Part of: #1973
Original patch by: @smiley
Redone by: @Stan
Standing on the shoulders of giants: @Freagarach
(Revisions: 59; Inlines: 209)
Differential revision: D1718
Comments by: @Angen, @elexis, @Imarok, @Langbart, @nani, @Nescio,
@smiley, @Stan, @wraitii
This was SVN commit r24963.
- PushOrderFront could lead to an infinite loop if walking fails.
- Move units in formation before issuing the move order (or the
formation may not exist).
Differential Revision: https://code.wildfiregames.com/D3411
This was SVN commit r24961.
In our current UnitAI implementation, the states are responsible for
whether we are moving or not. If a request to stop moving is made from
outside the state that initiated the moving order that is (mostly)
wrong. This fixes that.
Differential revision: D3289
Comment by: @wraitii
This was SVN commit r24954.
18b317bc19 (#563) introduced an ANIMAL-state from a separate
AnimalAI-component (introduced in e19146cf25).
This patch merges that separate state and brings the ROAMING and FEEDING
(renamed to LINGERING) under the INDIVIDUAL.IDLE-state.
This enables e.g. city-building mods to have human units that linger and
roam or animals that behave like humans.
The specific values for animals might need tweaking after this.
Differential revision: D2646
Fixes: #1832, #5593
Comments by: @Angen, @Langbart, @Nescio, @Stan, @wraitii
Refs.: #3919
This was SVN commit r24953.
The formation is set to an empty state upon disbanding which does not
have a `MEMBER`-substate.
Caused by c57a4d90a1.
Fixes: #6052
Differential revision: D3588
Reviewed by: @wraitii
This was SVN commit r24935.
- e7e218a3bc contained a small mistake: this.order wasn't cleared when
clearing the orderqueue, which led to a broken codepath in
PushOrderFront.
- Since 71a61d5f50, formation orders their members to reform in IDLE.
This will automatically pack any unpacked siege.
Reported by: langbart
Tested by: langbart
Fixes#6018
Differential Revision: https://code.wildfiregames.com/D3561
This was SVN commit r24895.
When giving several queued formation-walk orders, then a queued
non-formation order (such as gathering), the gather order would be
silently dropped. This did not happen if only one formation-walk order
was given, which is why this issue was not noticed in 59d0885d68
To fix it, explicitly only drop pre-"leave formation" orders in the
queue for formation members.
Reported By: faction02
Differential Revision: https://code.wildfiregames.com/D3550
This was SVN commit r24869.
COMBAT.APPROACHING will fallback to WalkAndFight if the order is forced
and the movement fails (happens e.g. on target death).
That behaviour was added in 5568bd4c16 (and tweaked in d9c6879450), to
make the unit move to the general position asked by the player as a
fallback.
However, it did not allow capture, which meant units would occasionally
start attacking structures, instead of capturing (the default).
This makes that fallback allow capture in all cases, which is generally
more expected than the reverse.
Fixes#6003
Differential Revision: https://code.wildfiregames.com/D3548
This was SVN commit r24866.
5d96346ac5 proved unsufficient to fix formation 'waltzing'. This is a
better fix, which makes sure units actually try to reach their
designated offset in the first place.
Further, it removes code that recalculated offsets un-necessarily, which
led to an issue with "sloppy" formations such as open and closed orders.
Fixes#5997
Differential Revision: https://code.wildfiregames.com/D3543
This was SVN commit r24865.
FSM states would be left/re-entered, resetting the timer, which did not
happen pre a16e7c0a56 and is undesirable in general.
This explicitly checks for a few cases where timers are relevant.
Essentially a Patch by: Freagarach
Differential Revision: https://code.wildfiregames.com/D3531
This was SVN commit r24855.
Issue described in #5945.
Unit finishing the order such as walking, will reach destination and if
attacked, imediately reacts to the attacker.
Hovewer, more desireble is for unit to look around since entering idle
state and pick the target if any using preference and then react to
attacker.
This issue rised up after finding of new targets have been moved from
enter to timer to avoid infinite loops after alwaysenterstate logic
removal.
Only downside here is unit will receive few hits before reacting as we
are waiting to the timer first. This happens only if unit goes idle.
Differential revision: D3504
Reviewed by: Freagarach
Comments by: wraitii
Fixes: #5945
This was SVN commit r24818.
Unit Motion currently checks if the unit is at destination during the
MT_Update_Motion* step, which happens late in the turn (notably, after
Timer.js) and moreover happens while entities are being moved (e.g.
entities with lower IDs have moved already, entities with higher IDs
have yet to do so).
This changes UnitMotion to instead check at turn start, which:
- benefits from in-turn path computations for more fluid movement
- ensure that distance checks aren't done against an entity that has
already moved for the turn.
The latter issue led to units failing to get in range of their target
when chasing them, in some situations.
As a side effect, this means that UnitAI move requests always take one
turn to succeed, so orders should be updated to check for range (or
they'll waste a turn). This is done for garrisoning, other orders were
already doing so.
Also includes a small tweak to avoid units rotating randomly when they
have no movement to accomplish.
Patch by: bb
Reviewed By: wraitii
Refs #5936
Differential Revision: https://code.wildfiregames.com/D3230
This was SVN commit r24797.
Units no longer stop when ordered to stand ground. Use the Stop
command/hotkey instead.
Reviewed By: Freagarach
Fixes#5975
Differential Revision: https://code.wildfiregames.com/D3463
This was SVN commit r24791.
Units sometimes ignored targets that entered their LoS. The cause is
d0fc8ff67d: range queries returned units farther away, and those units
might actually be out of range if distance is computed center-to-center,
which both UnitAI and LOS do. This meant that code relying on range
query updates was possibly broken, and indeed units missed things (see
ticket).
This introduces a boolean to switch between pre-d0fc8ff67d behaviour
(entity-as-point, center-to-center range queries) and post-d0fc8ff67d
(entities-as-circumscribing-circle, edge-to-edge range queries).
The former is used for UnitAI (where the new behaviour bugged), auras
(where varying structure sizes made it awkward) and build
restrictions(which simply did not really need it).
Reverts 7f1ee23d88, 050c5401b1 (with the exception of the iber monument
footprint), and the template changes in d0fc8ff67d itself.
It also reduces alertRaiser ranges slightly, this was missed in the
original diff.
#3381 is not reopened as BuildingAI still uses the new range queries.
Reported by: Freagarach
Comments By: Angen
Fixes#5968
Differential Revision: https://code.wildfiregames.com/D3456
This was SVN commit r24776.
Introduced in e543b01077.
Units entering cheering from idle state, may not check their surrounding
for pottential targets yet, so they will react incorrectly when
attacked.
Pointed out by @Freagarach in
https://code.wildfiregames.com/D1977?id=10404#inline-52415 and turned
out to be issue.
Differential revision: D3455
Fixes: #5966
Reviewed by: @wraitii
This was SVN commit r24774.
Make sure that any pending cheering order is deleted when leaving the
Cheering state, otherwise other unitAI states can behave weirdly.
This fixes issues with units cheering at incorrect time, then not
correctly picking their next target in a fight.
Reported by: snelius
Reviewed By: Angen
Refs #5966
Differential Revision: https://code.wildfiregames.com/D3452
This was SVN commit r24773.
Since 59d0885d68, there is a "LeaveFormation" order to support
queued-disbanding. However, I misread the code paths and FinishOrder()
isn't always called.
This fixes that oversight.
Reported by: Freagarach
Differential Revision: https://code.wildfiregames.com/D3450
This was SVN commit r24771.
(setting waypoints to more than 2 markets still does not work properly,
but it also did not in A23).
Fixes#5923
Differential Revision: https://code.wildfiregames.com/D3400
This was SVN commit r24676.
This made citizen workers show up in the 'idle worker' GUI button when
e.g. formation-patrolling between two points (since 6778fc4ea6 / D2913)
Co-written with: Freagarach
Differential Revision: https://code.wildfiregames.com/D3335
This was SVN commit r24596.
When an entity promotes it autogarrisons in the turret position but
because `GARRISONE.enter` returns early a turret never reaches the
`IDLE`-state and thus won't automatically react on nearby enemies.
This is explicitly a temporary fix.
Differential revision: D3293
Reviewed by: @wraitii
This was SVN commit r24521.
Large units risk being stuck between other units. This is true in
general, but particularly weird with formations, since individual units
may well not be stuck, only the invisible formation controller.
This alleviates the issue by ordering units to move individually when
the controller appears stuck.
It introduces a new "VERY_OBSTRUCTED" unit motion message, which
triggers when a unit has failed to move for several turns.
Reported By: Angen
Reviewed By: Freagarach
Fixes#4935
Differential Revision: https://code.wildfiregames.com/D3209
This was SVN commit r24511.
This allows choosing a "default formation", which is activated
automatically for units given walk orders (and attack-walk etc.).
Conversely, units in formation that are given a gather/build/... order
are taken out of formation and given the order individually.
The default formation can be selected by right-clicking on any formation
icon.
This leverages formations for walking, where they are quite efficient
(in fact, perhaps too efficient), while circumventing issues with
various orders.
Choosing the "null formation" as the default formation de-activates the
behaviour entirely, and plays out exactly like SVN.
This makes it possible to queue a formation-order then a
noformation-order (i.e. walk then repair), though the behaviour isn't
very flexible.
For modders, it should be relatively easy to change the setup for each
order, and/or to force deactivating/activating formations in general.
Tested by: Freagarach, Angen
Refs #3479, #1791.
Makes #3478 mostly invalid.
Differential Revision: https://code.wildfiregames.com/D2764
This was SVN commit r24480.
Idle formations re-arrange whenever a member leaves the formation.
Because Idle formation entities can attack nearby units (the formation
stays idle for this), any death will re-arrange the formation, causing
the entities to move in formation before going back to attack.
This looks odd and makes formation less usable. Given that it's tricky
to change the controller state with the current code, this instead
reforms the formation on a timer, only when all members are IDLE.
It fixes the issue and looks generally similar in other cases.
Reported By: wowgetoffyourcellphone
Reviewed By: Freagarach
Differential Revision: https://code.wildfiregames.com/D3236
This was SVN commit r24467.
In earlier revisions units fled more slowly with fewer hitpoints.
Since def47cb7ae this is not the case anymore.
Differential revision: D3229
Reviewed by: @wraitii
This was SVN commit r24404.
`ConstructionFinished` is obselete since 88dc6d8e1e.
These messages are only sent when the entity is in a specific state (or
states).
Differential revision: D3044
Discussed with @wraitii
This was SVN commit r24402.
This makes 'dancing' impossible with patrol, for both single units and
formations.
It further makes the formation and regular patrol code more similar.
The diff harcodes an integer wait time as it relies on timer calls
instead of range queries, as that was much simpler to implement.
Animations for the waypoint-waiting is also unimplemented.
Reviewed By: Freagarach
Refs #5106
Differential Revision: https://code.wildfiregames.com/D2913
This was SVN commit r24360.
And total gatherers next to the population icon.
Closes#643
Patch by: @mammadori
Differential Revision: D3155
Earlier revisions reviewed by: @Angen, @wraitii
Comments by: @Nescio, @s0600204, @Stan
This was SVN commit r24357.
Since relics ought to be undestroyable, a health component makes no
sense. This makes that the Invulnerability-flag can be removed and
relics can be captured again (after 0f91c5ac61#inline-5236).
Differential Revision: D1268
Original patch by: @temple
Reviewed by: @wraitii
Comments by: @bb, @elexis
Fixes#5007, #5847, 0f91c5ac61#inline-5236
This was SVN commit r24327.
