Units in formation can occasionally request many short paths (and thus
introduce crippling lag) if their offset is obstructed.
This particularly happen when the formation is idle, since the offset
then always remains obstructed.
To prevent this, it is OK to immediately stop pathing on any motion
message (obstructed, failure, success). This does not break formation
movement since messages are only sent when the formation controller is
not moving (this finishes what was started in 0535eb9b92).
Ideally, this hack could be removed if the short-pathfinder was quick
enough / units were better at aborting.
Fixes concern raised by Freagarach on a7da40ac2f.
Refs #5624 in that the max-short-path range is the source of the lag.
Reviewed By: Angen
Differential Revision: https://code.wildfiregames.com/D2871
This was SVN commit r23867.
Changing Grid.h should recompile faster, as it is now included in fewer
TUs.
Differential Revision: https://code.wildfiregames.com/D2784
This was SVN commit r23774.
Range manager has several `std::vector` for fixed-size arrays and 2D
grids. By using proper data structures, the code readability is
improved.
This also moves around the LosVisibility enum.
Comments by: Stan`, nani
Differential Revision: https://code.wildfiregames.com/D2770
This was SVN commit r23769.
This is the same commit as 2abd9cead2 / D1418, fixing noted issues.
This addresses two related issues:
- Units visibly garrisoned on gates keep the gate open.
- Units visibly garrisoned on entities keep their pathfinding blocker
flags.
De-activate the obstruction of visibly-garrisoned entities, fixing the
2nd issue.
Keep a list of entities that cannot move and thus should not count
towards gate-opening logic.
Packing logic is kept separate: it is more related to entities having
'alternate forms' with different capabilities than being currently
incapable of moving.
Based on work by temple
Fixes#2679.
Fixes#5151.
Differential Revision: https://code.wildfiregames.com/D2775
This was SVN commit r23731.
Player-testing has revealed QA issues, so reverting these for now.
Differential Revision: https://code.wildfiregames.com/D2773
This was SVN commit r23714.
This addresses two related issues:
- Units visibly garrisoned on gates keep the gate open.
- Units visibly garrisoned on entities keep their pathfinding blocker
flags.
Remove the block-movement flag from visibly garrisoned entities.
Keep a list of entities that cannot move and thus should not count
towards gate-opening logic.
Packing logic is kept separate: it is more related to entities having
'alternate forms' with different capabilities than being currently
incapable of moving.
Based on work by temple
Comments by: Freagarach
Tested by: Nescio
Fixes#2679Fixes#5151
Differential Revision: https://code.wildfiregames.com/D1418
This was SVN commit r23710.
This fixes an off-by-one error that led to entities sometimes getting
stuck against obstructions.
It also increases the max-range of the short pathfinder to help entities
find their way around corridors and house blocks.
Fixes 2ff8614ce2 (off-by-one error) and reverts the range changes from
32e8ed51aa
Reported By: Freagarach
Fixes#5586 . Refs #5624
Differential Revision: https://code.wildfiregames.com/D2754
This was SVN commit r23699.
This allows Atlas not to rely on eval() to get access to the attack
component.
Add a quick test for the added method.
This fixes the animation speed matching that of the actor instead of the
template.
Remove some dead code after af2abb8cbfFixes: #5129
Reviewed by: @Angen
Comments by: @elexis
Differential Revision: https://code.wildfiregames.com/D2464
This was SVN commit r23592.
This is adding support to handle garrisoned entities defined in map
files by game engine and atlas allowing future extension for atlas ui
and solving recreation of entites on init in D1958. Also solving
deepfreeze described in D2562.
Differential Revision; https://code.wildfiregames.com/D2597
Ticket: #3008
Patch by: Freagarach
Comments by: elexis
This was SVN commit r23529.
Check for player being out of bounds after m_TerritoryCellCounts may be
recomputed.
Differential Revision: https://code.wildfiregames.com/D2046
Reviewed by: @Stan
This was SVN commit r23510.
Fail movement for formationmember when cannot find path to destination
and formationcontroller is not moving so formationmember will enter idle
state or follow next command relying on member stopping movement first.
Introduced in a1dc9cadd8.
Differentail Revision: https://code.wildfiregames.com/D2438
This was SVN commit r23496.
Avoids computing the square of the compared value every call.
Differential Revision: https://code.wildfiregames.com/D2058
Reviewed By: Vladislav
This was SVN commit r23489.
Allows to place buildings a bit faster and more perfectly aligned. Also
it helps to find a nearest placeable position in some cases.
Reviewed By: elexis
Comments By: Stan, wraitii
Differential Revision: https://code.wildfiregames.com/D2079
This was SVN commit r23330.
Problem description:
When unit gets command to move to the range exactly X units from some
point/entity, what means minRange == maxRange, that triggers computing
goal when distance < minRange with result distance(goal, target) >
maxRange, because minRange computation uses clearance even when is
treating target as circle.
Solution:
Do not use clearance when treating target as circle, so computation when
distance < minimum range is done in same way as computation when
distance > maximum range and so computed goal has correct position.
Reported on forum:
https://wildfiregames.com/forum/index.php?/topic/27384-strange-landing-on-the-island-and-unable-to-attack/
Differential Revision: https://code.wildfiregames.com/D2512
Tested by: gameboy
This was SVN commit r23283.
Replace std::deque by std::vector
Replace some casts by cpp casts
Move the class and struct declaration to a separate file for clarity.
Fixes db864f10c3 by removing offending function
Refs #5288
Refs D1681
Reviewed by: @vladislavbelov
Differential Revision: https://code.wildfiregames.com/D1682
This was SVN commit r23029.
Following d592bf9cb6, paths were computed at the end of turn N, and then
messages were sent at the beginning of turn N+1. However, the path
requests were removed at the end of turn N and so weren't serialised,
and neither were computed paths. This meant rejoiners would OOS when the
game was serialised with pending path results.
To fix this in preparation for threading, the architecture needs to
change slightly so that requests are kept and serialised correctly, and
rejoiners can compute the paths after deserialisation, in order to send
the messages at the beginning of turn N+1.
Fixes#5604
Reported By: elexis
Differential Revision: https://code.wildfiregames.com/D2317
This was SVN commit r22979.
This moves the "async" pathfinding computations to a worker, preparing
the architecture for threading.
Tested By: Kuba386, Stan`
Differential Revision: https://code.wildfiregames.com/D1918
This was SVN commit r22902.
Make that function static, so that it can be used for these functions
without slowly having to obtain the ScriptInterface instance using
GetScriptInterfaceAndCBData just to get the JSContext again.
Remove few redundant conversions for CreateObject arguments.
Differential Revision: https://code.wildfiregames.com/D2128
Tested on: gcc 9.1.0, clang 8.0.1, Jenkins
Tedious performance testing in: D2128, D2127
This was SVN commit r22894.
D1987/99a341f379 introduced logic to predict the target movement, which
fixed unit chasing. However, sometimes fleeing units would then predict
that their target will end up in front of them, so they turned around
towards the attacker.
This is fixed by not anticipating the position when it would cause the
vector towards to target to change direction.
Reported By: Freagarach
Tested By: Freagarach
Fixes#5541
Differential Revision: https://code.wildfiregames.com/D2275
This was SVN commit r22885.
The function was put in an anonymous namespace to avoid linking errors
should another one be defined elsewhere.
Reviewed By: elexis
Differential Revision: https://code.wildfiregames.com/D2243
This was SVN commit r22825.
By leveraging custom ordering in std::set, MakeGoalReachable and
FindNearestNavcellInRegions can be optimised and the code simplified.
Differential Revision: https://code.wildfiregames.com/D1882
This was SVN commit r22817.
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.
In some rare cases, units could be stuck in the special state of 3
failed path computations, making them always compute long paths instead
of trying short paths again. This can happen when they compute a long
path successfully, but the unit cannot actually move as it gets
obstructed right away.
Make sure this state is never kept for more than one turn to fix this
problem.
Refs #5569 (probable fix but kept open for further investigating).
Differential Revision: https://code.wildfiregames.com/D2239
This was SVN commit r22815.
The ModifiersManager system component provides an interface to add and
remove modifiers, and get modified stats.
The goal is to merge all the different stat-modifying systems 0 A.D. has
implemented over the years.
This commit makes technologies and auras use ModifiersManager. Some
cheats and AI bonuses also have a similar stat-modifying effect that
have not yet been updated.
Further, this system component makes it possible for e.g. triggers to
easily add modifiers, enabling the writing of Castle Blood Automatic,
RPG or Tower Defense maps without the need for mods or hacks.
The 'Modifier' name was preferred over 'Modification' as it is shorter
and more readable, along with the logic that 'modifiers' store
'modifications' and this stores modifiers. Renaming of other functions
and classes has been left for future work for now.
Internally, this uses a JS data structure. If performance issues arise
with it in the future, this data structure or the whole component could
be moved to C++.
The performance has been tested to be about as fast as the current
implementations (and specifically much faster for global auras with no
icons). Testing showed that sending value modification messages was by
far the slowest part.
Comments by: leper, Stan, elexis
Differential Revision: https://code.wildfiregames.com/D274
This was SVN commit r22767.
Optimise MakeGoalReachable using global regions, by leveraging the fact
that we can easily know which goal regions we can reach. Particularly
for point-goals, it becomes almost instant.
This does not change hashes.
Differential Revision: https://code.wildfiregames.com/D1835
This was SVN commit r22653.
A call to SelectAnimation("idle") was left over.
Reported by: elexis
Fixes#5552
Differential Revision: https://code.wildfiregames.com/D2169
This was SVN commit r22648.
This moves the renderer options into their own class to:@
- allow one to only include the rendering options, not the whole
renderer header, when one wants access to rendering options.
- centralise rendering changes and their side-effects.
- clean up code.
Tested by: historic_bruno, Freagarach
Commented by: historic_bruno
Differential Revision: https://code.wildfiregames.com/D1929
This was SVN commit r22610.
Use the "pretend correct path" behaviour for short goals too. This is a
fix for #5545, since the position check now works correctly without
needing to add a tricky check for path-vs-path distance.
Simplify HandleObstructedMove to use ComputePathToGoal more. This means
we occasionally compute a long path when stuck, which fixes two cases of
stuck units reported in #5547.
Move some common calls into functions for convenience.
Make sure the short-path-waypoint-range-relaxing introduced in
32e8ed51aa doesn't happen for the last waypoint, which caused units to
occasionally never get in range of the last waypoint.
Clear short path waypoints when computing a long path.
This won't fix all instances of unit dancing, but it should improve most
of them.
Fixes#5545, Fixes#5547
Differential Revision: https://code.wildfiregames.com/D2135
This was SVN commit r22609.
A random phenotype can be chosen by giving multiple tokens to the
template.
This allows giving different looks to the same template.
Comments By: stan, vladislav, elexis
Patch By: Freagarach
Reviewed By: wraitii
Differential Revision: https://code.wildfiregames.com/D1955
This was SVN commit r22586.
BeginPathing renamed to ComputePathToGoal, as that is what this function
does.
IsMoving renamed to IsMoveRequested, as the function returns true when
the unit has a move request going on, not when it is actually moving
across the map, which was misleading.
UpdateMovementState's implementation moved closer to where it is used.
PathIsShort and WAYPOINT_ADVANCE_MAX are currently unused, thus deleted.
Differential Revision: https://code.wildfiregames.com/D2067
This was SVN commit r22568.
This helps with #3144 and units not going idle when ordered to clump
together.
By rejecting paths that would not take the unit closer to the goal than
it is, we can avoid the case where a unit at A finds a short path to B,
goes there, gets stuck, finds a new short path to A, etc. ad infinitum.
It doesn't completely fix the problem since two units moving might still
occasionally become stuck against one another, but it makes it rarer
(unit pushing would probably finish solving this).
This assumes that being as close as possible to the goal is the best
behaviour when trying to move somewhere, even when it is unreachable.
Refs #3144
Differential Revision: https://code.wildfiregames.com/D2075
This was SVN commit r22566.
This fixes a regression introduced by 055c848c1a: when an entity is
ordered to move to a target within short path distance (or direct path
distance), it no longer computed at least one long path, which meant it
could be stuck forever if the target was not actually reachable (such as
behind a wall).
To fix this, compute a long path after 3 failed computations, which
should result in a delay of 1-3 turns. The previous code did this after
1 failed try - the decision to make it 3 is mostly based on the idea
that in most cases, being stuck means we ran into units, not that we
were ordered somewhere close. Should there be complaints, it could be
lowered to 2 or 1.
This fixes a second issue, reported in #4473: units sometimes get stuck,
particularly when trying to garrison a turret from 'inside' the walls.
The issue is that the turret is not accessible via the inside as its
obstruction + garrison range is blocked by the surrounding walls.
However, as introduced by 6e05a00929, TryGoingStraightToTargetEntity
ignores all entities with the obstruction group of the target (the
reason for this being that otherwise it would never succeed, since the
line towards the target would likely go through the target).
For walls and formations, this means ignoring possibly too many
entities, and in the case of #4473, ignoring wall pieces. The unit thus
mistakenly thought it could direct-path to the turret, and got stuck.
To fix this, we can ignore specifically the targeted entity's
obstruction tag. This can be considered a fix to 6e05a00929.
temple accepted an earlier version of this patch (specifically elexis'
version).
Fixes#4473
Based on a patch by: elexis
Differential Revision: https://code.wildfiregames.com/D1424
This was SVN commit r22533.
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.
Units right now try going to their next long waypoint using the
short-range pathfinder. This works, but it tends to leads to units
clumping together when shuttling for example.
By switching to short paths earlier, and by scrapping the long waypoints
when doing so, we can make movement more natural until we have unit
pushing.
Some cleanup in how the short-path domain range gets handled, and
increase the max-range by one tile to improve rare cases.
Differential Revision: https://code.wildfiregames.com/D2095
This was SVN commit r22507.
As reported by @bb in #5512, catapults and other big-range units might
not approach targets correctly when trying to get in range.
To be sure that we will be in range of a square obstruction approximated
as a circle, we need to consider the inscribed circle and not the
circumscribed circle.
Reported by: bb
Fixes#5512
Differential Revision: https://code.wildfiregames.com/D2086
This was SVN commit r22495.
