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.
Also refactors the order a bit to be more equal to other orders.
Removes the `autocontinue` because it was not useful (since that is more
about doing other tasks than the one ordered).
Follows ea96e8109897addf2aa7.
Differential revision: https://code.wildfiregames.com/D3942
Tested by: @Langbart
Fixes: #6175
This was SVN commit r25421.
Don't let entities waste a repeat time when they've killed their target.
Done by storing a list of attackers in cmpResistance (since that cmp is
obligatory anyway).
Differential revision: https://code.wildfiregames.com/D2129
Comments by: @Angen, @wraitii
This was SVN commit r25368.
Followup on 1e0a6f66f0.
This gives a better image of the amount of units which are gathering.
By decision, entities are _not_ accounted from when the player tasks
them to return their resources.
Refs. #643
Differential revision: https://code.wildfiregames.com/D3226
Comments by: @wraitii
This was SVN commit r25345.
While gathering resources entities may be tasked to gather near a
position. The range check for that is 10 m. However, the relaxed range
check for the walking state is this.DefaultRelaxedMaxRange, which is 12
meter, currently. Meaning it would lead to a slow infinite loop.
Differential revision: D3839
Comments by: @wraitii
Tested by: @gameboy
(https://wildfiregames.com/forum/topic/38131-tutorial-bug/)
This was SVN commit r25249.
- `initPos` was used wrong.
- There were two `CanGather` functions in `cmpResourceGatherer`.
- Reduced some duplication in the ReturnResource order.
Differential revision: D3838.
This was SVN commit r25243.
Following 21e866fcf0.
Also support leaving a turret by using a hotkey.
Currently the hotkeys are by default bound to the same ones as
garrisoning.
Differential revision: D3773
Icons by: @wowgetoffyourcellphone and @Stan.
This was SVN commit r25240.
Keep responsibilities separated, allow easier modding of attacking
behaviour.
Ideally the BuildingAI attacking routine would be merged in here as
well, but not done for now.
Part of #5810
Differential revision: D3816
Comments by: @smiley, @Stan
This was SVN commit r25235.
Don't pretend it to be a callable function, while it is certainly part
of the FSM.
(Also makes it easier for us to implement a duration for the trading in
the future, might we ever want to.)
Differential revision: D3813
Comment from: @Angen
Closes: #6135
This was SVN commit r25216.
Allows for non-moving entities to drop resources. (When someone checks
those cases in the order.)
(Also makes it easier for us to implement a duration for the dropping in
the future, might we ever want to.)
Differential revision: D3817
This was SVN commit r25215.
Moves the building logic from UnitAI to Builder.
Makes it easier for modders to change building behaviour, e.g. letting
structures build.
Differential revision: D3812
Comment by: @Angen
This was SVN commit r25208.
Moves the healing logic from UnitAI to Heal.
Makes it easier for modders to change healing behaviour, e.g. letting
structures heal (instead of using an aura).
Differential revision: D2680
Comments by: @Stan, @wraitii
This was SVN commit r25207.
Moves the gathering logic from UnitAI to ResourceGatherer.
Makes it easier for modders to change gathering behaviour, e.g. letting
structures gather.
Refs. #4293 by optimising a bit.
Differential revision: D2662
Comments by: @bb, @Stan, @wraitii
This was SVN commit r25206.
This basically does two things:
- Allow turrets on moving entities (fixes serialisation in cmpPos).
- Allow an entity to be present on another when the other is created.
That makes it basically a boiled down version of a prior patch, omitting
the part where orders could be passed on.
This does allow e.g. ranged units on chariots that fire while the
chariot moves.
Original diff by: @sanderd17
Redone by: @Stan
Differential revision: D1958
Comments by: @Alexandermb, @Angen, @bb, @Langbart, @Nescio, @Stan,
@wraitii
Refs. #2577 by implementing the entity on platform case.
This was SVN commit r25192.
Not all orders were checked, which would cause problems when receiving
an order that needed moving and that did not handle not being able to
move properly.
Differential revision: D3771
This was SVN commit r25164.
21e866fcf0
Crossbowmen should be able to turret (noted by @Nescio).
TurretHolders should be able to pick entities up.
Differential revision: D3744
This was SVN commit r25163.
Makes for less duplicated logic, easier modding and better split
responsibilities.
Differential revision: D3638
Closes: #5884
This was SVN commit r25139.
While they often look alike, their behaviour is totally different.
This split has some implications:
- There are now separate auras for garrisoning and turrets.
- Entities can now have both turret points and garrison slots,
independent of eachother.
In general previous behaviour is maintained as much as possible.
Differential revision: D3150
Comments by: @Nescio, @wraitii
Tested by: @v32itas
This was SVN commit r25123.
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.
Freagarach