#3538 closed defect (fixed)
[PATCH] OOS on rejoin, moving through new obstructions with hierarchichal pathfinder
Reported by: | elexis | Owned by: | wraitii |
---|---|---|---|
Priority: | Release Blocker | Milestone: | Alpha 19 |
Component: | Core engine | Keywords: | pathfinding |
Cc: | Patch: |
Description (last modified by )
Units can go through obstructions, as reported in #3410. This ticket should deal with one particular case.
Reproduce:
- Build something
- Create a big unit (siege or ship)
- Tell the big unit to move inside the new building (make sure it's a longpath)
By showing the pathfinder overlay in the developer menu, you see that the returned longpath has a goal inside the obstruction. The unit will follow that longpath and enter the building.
Notice the bug only applies to obstructions that are added after the game has started. If the building existed when the game started, the goal of the longpath will be outside the obstruction and the unit will not enter the building (besides #3532)
(Units in formation count as a single big unit (clearance 4) and also get a goal point inside the obstruction. But they disband when hitting the obstruction and don't enter it.)
Together with #3532, this bug accounts for the "ship on land" thing, which has been reported here https://wildfiregames.com/forum/index.php?showtopic=20083 and happened to me in some games (uploaded in #3513 and #3471). Replaying those games showed that ships always entered the land by moving through the obstructions of docks.
The bug occurs with all obstructions that are added after the game started:
While obstructions that exist when the game started are handled correctly:
Sometimes the chosen path is too long (hopefully only occurs when having this obstruction bug. The catapult started near the fortress and was ordered to move near the center of the temple, see attachment:commands_path_too_long.txt):
Attachments (8)
Change History (23)
by , 9 years ago
Attachment: | siege_inside_obstruction.gif added |
---|
by , 9 years ago
Attachment: | newly_constructed_dock.jpg added |
---|
by , 9 years ago
Attachment: | prebuilt_dock.jpg added |
---|
But if the dock existed when the game started, it works as expected (besides #3532).
comment:1 by , 9 years ago
Description: | modified (diff) |
---|---|
Summary: | Longrange-pathfinder ignoring new obstructions when moving big units → Longrange-pathfinder allows goals inside new obstructions when moving big units |
by , 9 years ago
Attachment: | commands_path_too_long.txt added |
---|
Minimal replay for r17144 where a catapult was ordered to move near to the center of the temple. The longpathfinder returns a path allowing to enter the obstruction. Strangely the chosen path is about 3 times as long as it should be (i.e. chosen path is not a shortest path). The catapult receives only one walk-command. Hopefully only occurs when having this obstruction bug.
by , 9 years ago
Attachment: | path_too_long.jpg added |
---|
comment:2 by , 9 years ago
Description: | modified (diff) |
---|
comment:3 by , 9 years ago
Summary: | Longrange-pathfinder allows goals inside new obstructions when moving big units → OOS on rejoin and moving through new obstructions |
---|
mimo correctly guessed that this is a serialization issue. This bug occurs with the host, but not with the rejoined client.
comment:4 by , 9 years ago
This bug, i.e. getting longpaths with the goal inside new buildings and sometimes getting weird / too long paths then exists since r16751.
comment:5 by , 9 years ago
Reproduce OOS:
- Start match with late-observer-joins enabled, enable pathfinder overlay
- Build dock, make ship and move it away
- Join with observer, enable pathfinder overlay
- Order the ship to move inside the dock (must be a longpath)
Obervations
- In the pathfinder overlay you will see that
- The host has the invalid path with the goal inside the building.
- The rejoined client has the valid path with the goal outside of the building.
- The OOS will occur instantaneously after the rejoined client has issued a move order into a new building, but not earlier.
Related tickets:
- This ticket might be a duplicate of #3292, since this is surely one way to get different waypoints.
- Notice changing the obstructions creates the OOS in #3450 for one turn. So maybe this is related/duplicate.
Further Observations: Also notice that for the host,
- The shortpathfinder does take the new obstruction into account
- The longpathfinder also seems to take it into account, as some segments of the path are often aligned with the edge of the new obstruction
HierarchicalPathfinder::MakeGoalReachable()
is called for both clients, but the code afterif (reachableContainingGoal.empty())
is only called for the rejoined one!! (So we could be able to deduce from that which update is missing for the host)
by , 9 years ago
Attachment: | hierarchical_pathfinder_not_being_updated.jpg added |
---|
By changing "default" to "ship" in BuildTextureRGBA
of HierarchicalPathfinder.h
, you can visualize the regions on the water. The dock at the left is newly built, the other one existed when the game started.
comment:6 by , 9 years ago
The dock at the left is newly built, the other one existed when the game started.
Notice though that the visualization seems inaccurate, as the region seems to end at the dock, not at the clearance (RegionContainsGoal
returns true in HierarchicalPathfinder::MakeGoalReachable
when issuing a longpath request with the goal near the old dock).
comment:7 by , 9 years ago
Keywords: | patch review added |
---|---|
Summary: | OOS on rejoin and moving through new obstructions → [PATCH] OOS on rejoin, moving through new obstructions with hierarchichal pathfinder |
Executing m_PathfinderHier.Recompute
after adding an obstruction solves the problem, but only m_PathfinderHier.Update
is called from CCmpPathfinder::UpdateGrid()
as m_ObstructionsDirty.globallyDirty
is false when adding new obstructions.
We don't want a global recompute though, only one for the hierarchichal pathfinder, so maybe a new dirty-boolean should be introduced for the hierarchical pathfinder (or can this be solved by partially recomputing it too?)
by , 9 years ago
Attachment: | t3538_recompute_hierarchichal_pathfinder_every_turn_WIP_v1.patch added |
---|
comment:8 by , 9 years ago
A partial recompute sounds ideal, but what do you think about doing a full recompute for A19 and pushing partials to A20?
Edit: Elexis; nice job with the ticket description, I really like the gifs.
by , 8 years ago
Attachment: | HierachicalFix.patch added |
---|
comment:10 by , 8 years ago
Above patch should fix the issue. The problem was a for/if inversion, which meant that we once we processed for the "default" class all the other passability classes were skipped.
This probably caused a TON of bugs that we just never noticed, since if I'm right all large passability classes had the same issues.
comment:13 by , 8 years ago
Keywords: | patch review removed |
---|
comment:15 by , 5 years ago
Description: | modified (diff) |
---|
The ship receives a longpath with the goal inside the obstruction (both goals inisde the clearance and inside the building are available).