Fix waiting attackers becoming stuck when target flag becomes unreachable. #1865
+183
−55
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…able. When the defender kills the current attacker (at the flag) `FindAttackerNearBuilding` is used to get the next one for the defender to fight. This takes the closest attacker that is ready, i.e. waiting around the flag and calls `AttackDefenderAtFlag` which usually causes the attacker to start walking to the flag. However if there is no path to the flag (anymore, e.g. after destroying a road) the attacker won't do anything and the function returns `false`. As this isn't checked the defender will keep waiting for it. This can lead to use-after-free if the attacker is destroyed (defeated in free fight, went back home, ...) as the defender will then have a dangling pointer to it. Fixes Return-To-The-Roots#1863
The point can be considered invalid if it is too far and the attacker would abort on the next event handling. Defenders with now missing attackers will still come out of the building and go right back in which looks weird.
Flamefire
force-pushed
the
stuck-attacker
branch
from
8bddd93 to
0860af4
Compare
Flow86
reviewed
Jan 19, 2026
| // Check all points around the flag and take shortest | ||
| unsigned min_length = std::numeric_limits<unsigned>::max(); | ||
| MapPoint minPt = MapPoint::Invalid(); | ||
| ret_radius = 100; |
Member
There was a problem hiding this comment.
should this then start at MAX_ATTACKING_RUN_DISTANCE too?
Member
Author
There was a problem hiding this comment.
Actually this assignment could be removed. It is never used because the value will be overwritten when minPt gets set and if it isn't then ret_radius has no meaning
Member
There was a problem hiding this comment.
can we explicitly make it std::optional then? maybe its even eases up the do-while?
Member
Author
There was a problem hiding this comment.
Wait, this is used as the max value in the loop.
So it corresponds to GetPointsInRadius.
Added a constant to clarify
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When the defender kills the current attacker (at the flag)
FindAttackerNearBuildingis used to get the next one for the defender to fight. This takes the closest attacker that is ready, i.e. waiting around the flag and callsAttackDefenderAtFlagwhich usually causes the attacker to start walking to the flag. However if there is no path to the flag (anymore, e.g. after destroying a road) the attacker won't do anything and the function returnsfalse.As this isn't checked the defender will keep waiting for it.
This can lead to use-after-free if the attacker is destroyed (defeated in free fight, went back home, ...) as the defender will then have a dangling pointer to it.
Fixes #1863