Obstruction cluster are found in walls. Since position of walls would never change, that erroneous code path was probably never executed, hence it never caused any observable problems. Fixing this anyway in case it would be relevant in future.
It was implemented on Windows only. It doesn't really contain a useful
for us information which can not be obtained by diagnostic tools like
dxdiag when needed.
To follow other maps name syntax (`<name> (<number of players>)`), "players" is
removed from the name on the following maps to keep only the number:
- Cycladic Archipelago (2p, 3p)
- Libyan Oasis
- North African Savanna.
The filter was rarely used. The implementation was overly complex and
might have filtered out strings that should have been printed.
Tags like "FILES|" have been removed.
For the loader a macro `LOADER_LOG` has been introduced.
Mods may dynamically request icons
(e.g., [icon=\"emblem_${civ}\"], [icon=\"icon_${res}\"]) that
don't exist when another mod introduced the new civ or resource
but hasn't added that icon.
This results in excessive error log spam during normal gameplay.
Auras.CanApply called Visibility's GetPreview(), which doesn't exist,
so auras were applying in preview. Introduced in eb2ff98883.
Add GetPreview() to Visibility.
Fixes#9225
f39e71cca0 moved the player data refresh after a diplomacy change
into a diplomacy colors change handler, which only runs when
diplomacy colors are enabled. With them disabled, the diplomacy
dialog's stance buttons didn't reflect the new stances.
Refresh the player data directly in the diplomacy notification
handler, before the diplomacy colors are recomputed, and remove
the now redundant diplomacy colors handler registration.
To follow other maps name syntax (`<name> (<number of players>)`), "players" is
removed from the name on the Watering Holes map to keep only the number.
sortEntitiesForEngagement projects both attackers and targets from
the same origin (avgAttackers) onto the same vector,
so reversing the target array was incorrect.
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.
stevenlau