We need to track models to update in a single place. SceneRenderer in
that case. It allows us to make ModelVertexRenderer implementations more
straightforward.
The last node needs to have distance "0" to next node. Do the inverse of
when adding nodes.
Also add some basic tests covering this bug.
Fixes: #4659
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
cmpPosition was declared but never read anywhere in the function,
likely left over from an earlier refactor — each unit's own position
is already fetched correctly inside the loop via unitPos. CmpPtr
construction is a pure lookup with no side effects, so removing the
unused instance doesn't change behaviour.
In `CCmpPathfinder::CheckBuildingPlacement`, the boundary check for the
vertical grid dimension (`j > m_TerrainOnlyGrid->m_H`) allowed `j` to equal
`m_TerrainOnlyGrid->m_H`. Since grid indices are 0-based (valid row indices
range from `0` to `m_H - 1`), this boundary condition allowed the loop to
execute with an out-of-bounds row index, leading to an invalid memory
read (`m_TerrainOnlyGrid->get(i, j)`) and potential segfaults.
This patch changes the comparison operator to `j >= m_TerrainOnlyGrid->m_H`,
ensuring that spans extending to or past the grid height bound are properly
flagged as out-of-bounds.
Follows db23584fc3 - the caller of GetEffectiveAttackRange's didn't
really use the NEVER_IN_RANGE result properly.
The C++ engine does not handle Infinity (treated as 0).
This also changes MoveToTargetAttackRange to explicitly try to get
closer if the parabolic range is not in range, but it seems like a flat
range could - on the assumption that once we get closer, the terrain
height difference is lower.
range.GetInternalValue() is an i32; multiplying it by 2 before the cast
to i64 could overflow instead of widening, corrupting the divisor. Cast
to i64 first.
Since 38b33b0484, the range check happened in CanAttack, however the
check there is too permissive.
This meant it was possible for towers to attack certain targets outside
their actual range, depending on the query results and unit AI focus
fire.
Following 38b33b0484, units on aggressive stance no longer chase beyond
their own vision, including on player-forced orders. This fixes that
regression.
(Note that approaching and chasing are a bit inconsistent).
38b33b0484 partly rewrote GetQueryRange but ended up with two
bugs/regressions:
- in standGround, melee units used an effective max-range of 0 instead
of their melee attack max range
- units that have a min-range did not see units within their min-range
(even though they can move).
This fixes these issues and rewrite the function in a simpler fashion
for readability.
38b33b0484 added a visibility filter to TestEntityQuery, active whenever
a query sets preferMirages - which UnitAI's attack range query does.
However, those filters do not work for Gaia, and so the query never
returned anything.
It was only a wrapper around `std::string::substr`. The interface
matches the usecase more. In some places it's better to use
`std::string::ends_with`.
In most places `fmt::format` is used because it's locale indidendant.
For the user reporter the locale dependant form of `fmt::format` is used
because it's shown to the user.
When temporarly leaving a multiplayer game the "I will return" button
didn't work. This was because there was no valid `closeSession`.
Since it requires accessing `this` the function can't be an arrow
function anymore.
Introduced in 2520c45220Fixes: #9086
GATHER.FINDINGNEWTARGET inserts a ReturnResource order ahead of the
next queued order when the unit is still carrying resources, but
skips doing so if the next order already returns those resources.
Unfortunately, the check was incorrectly written, missing a `.type`.
This meant we always added a fresh order.
Units could then sometimes return resources to the closest dropsites,
then move to the actually queued dropsite, which could lead to
unexpected pathing.
Introduced in 0dda3b579c where the feature was added.
The cache invalidation was incorrectly using forEach, which failed to invalidate the cache.
This never actually caused a bug because the game currently does not silently swap active player entities.
In `CCmpObstruction::ResolveFoundationCollisions`, the nested loop
intended to assign a persistent control group to colliding normal
entities was incorrectly iterating over `normalEnts` instead of
`persistentEnts`.
This caused the function to attempt to clobber default control groups
with other non-persistent groups, completely bypassing the intended
`ControlPersist` logic.
This patch fixes the inner loop to correctly iterate over
`persistentEnts`, ensuring foundations properly inherit persistent
control groups.
Fixes: 9ae084519f
Vladislav Belov