#3539 closed defect (fixed)
Pathfinder - Women can't dropoff at worker elephant
Reported by: | elexis | Owned by: | mimo |
---|---|---|---|
Priority: | Must Have | Milestone: | Alpha 19 |
Component: | Core engine | Keywords: | pathfinding |
Cc: | Patch: |
Description (last modified by )
Reproduce:
- Start match with mauryan civ
- Move the worker elephant near a resource
- Let a unit gather the resource
After the unit finished gathering, it often can't dropoff the resources.
Maybe a duplicate of #3530. However mimo's attachment:testLine.patch:ticket:3530 doesn't fix it (of course making corpses non-obstructing doesn't cut it either).
Attachments (3)
Change History (13)
by , 8 years ago
Attachment: | commands_woman_stuck_in_elephant.txt added |
---|
by , 8 years ago
Attachment: | woman_stuck_in_elephant.gif added |
---|
comment:1 by , 8 years ago
Description: | modified (diff) |
---|
comment:2 by , 8 years ago
Milestone: | Alpha 19 |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
This indeed seems to be a duplicate of #3530 :-)
Some debug_prints gave me the following call stack, which is looped every turn.
ERROR: CCmpUnitMotion::Move() attempts TryGoingStraightToTargetEntity ERROR: CCmpUnitMotion::TryGoingStraightToTargetEntity() ERROR: CCmpUnitMotion::TryGoingStraightToTargetEntity() calls cmpPathfinder->CheckMovement() ERROR: CCmpPathfinder::CheckMovement() calls cmpObstructionManager->TestLine() ERROR: CCmpObstructionManager::TestLine() Checking unit shape 0 (unitShape-id 1), clearance 1.000000 ERROR: Geometry::TestRayAASquare() a is outside, b is inside ERROR: CCmpObstructionManager::TestLine() returns path is blocked because of Geometry::TestRayAASquare ERROR: CCmpPathfinder::CheckMovement() cmpObstructionManager->TestLine says path is blocked ERROR: CCmpUnitMotion::TryGoingStraightToTargetEntity() returns path is blocked ERROR: CCmpUnitMotion::Move() attempting to move towards waypoint ERROR: CCmpUnitMotion::CheckMovement() m_PassabilityMapChangedRecently = false ERROR: CCmpObstructionManager::TestLine() Checking unit shape 0 (unitShape-id 1), clearance 1.000000 ERROR: Geometry::TestRayAASquare() a is outside, b is inside ERROR: CCmpObstructionManager::TestLine() returns path is blocked because of Geometry::TestRayAASquare ERROR: CCmpUnitMotion::CheckMovement() cmpPathfinder->CheckMovement() returns path is blocked ERROR: CCmpUnitMotion::Move() Couldn't move close because CheckMovement says wasObstructed ERROR: CCmpUnitMotion::Move() don't update position (since we actually didn't move) ERROR: CCmpUnitMotion::Move() oops we hit something ERROR: CCmpUnitMotion::Move() we don't follow a longpath, recompute the path ERROR: CCmpUnitMotion::BeginPathing() from { 393.968506, 289.929108 } to { 396.062927, 292.483795 } ERROR: CCmpUnitMotion::BeginPathing() m_Moving = true ERROR: CCmpUnitMotion::TryGoingStraightToTargetEntity() ERROR: CCmpUnitMotion::TryGoingStraightToTargetEntity() calls cmpPathfinder->CheckMovement() ERROR: CCmpPathfinder::CheckMovement() calls cmpObstructionManager->TestLine() ERROR: CCmpObstructionManager::TestLine() Checking unit shape 0 (unitShape-id 1), clearance 1.000000 ERROR: Geometry::TestRayAASquare() a is outside, b is inside ERROR: CCmpObstructionManager::TestLine() returns path is blocked because of Geometry::TestRayAASquare ERROR: CCmpPathfinder::CheckMovement() cmpObstructionManager->TestLine says path is blocked ERROR: CCmpUnitMotion::TryGoingStraightToTargetEntity() returns path is blocked ERROR: CCmpUnitMotion::BeginPathing() RequestShortPath ERROR: CCmpUnitMotion::RequestShortPath() ERROR: CCmpPathfinder::ProcessShortRequests() yields the following 1 waypoints: ERROR: CCmpPathfinder::ProcessShortRequests() waypoint { 394.532318, 290.616821 }
This stack is identical to the one looped by the corpse-gather-bug in #3530, just with clearance 1 instead of 0:
ERROR: CCmpObstructionManager::AddUnitShape() for entity ID 11 becomes unitShapeID 1, has clearance 1.000000
Notice both forms of this bug hits the case
ERROR: Geometry::TestRayAASquare() a is outside, b is inside
comment:3 by , 8 years ago
Milestone: | → Alpha 19 |
---|---|
Resolution: | duplicate |
Status: | closed → reopened |
It is not a dupplicate, even if the effect on UnitMotion is identical. This one seems to be due to an incompatibility between the obstructions taken into account by the pathFinder (the elephant one seems to not be taken into account) and the one taken into account in UnitMotion (which takes the elephant into account).
#3530 is about how to deal with entities of obstruction 0 (and was revealed by the same bug as this one, i.e. by the fact that these were taken into account in UnitMotion but not by the pathFinder). But the main problem is that what is done presently with entity of obstruction 0 is not correct, and this has nothing to do with that ticket.
By the way, clearance 1 for the elephant is wrong. It seems the passability large was missed in its template (that fixes your commands.txt testcase, but the problem of obstructions incompatibilities remains).
comment:4 by , 8 years ago
Looking a bit more at the code, the difference between obstructions in UnitMotion and short pathfinder are due to the group which is given to the obstruction filter (ControlGroupMovementObstructionFilter, collisions with the group are ignored).
Internally in CCmpUnitMotion, the group is m_TargetEntity for formation members, and the entity itself otherwise, which looks reasonnable. But when CCmpUnitMotion calls the shortPathFinder, it always gives m_TargetEntity as group, so the target obstruction is never taken into account.
Changing the group of the pathFinder should solve this incompatibility, but that would creates some problems in functions like tryGoingStraightToTarget which will never suceed as it will always find the way obstructed by the target itself. So that would require to define specific group for such functions.
comment:5 by , 8 years ago
I've tried the changes described in previous comment, and that indeed fixes the bug but the path used by the female was from time to time quite weird, making some unexpected detours. I've tracked this to be a bug in the function switching from square to circle approximation when the goal range is of the same order as the clearance. Correcting this fixes the original bug (even when not modifying the obstruction group as described in previous comment).
by , 8 years ago
Attachment: | groupObstruction.patch added |
---|
patch to fix the obstruction group problem described in http://trac.wildfiregames.com/ticket/3539#comment:4
comment:9 by , 7 years ago
Description: | modified (diff) |
---|
comment:10 by , 6 years ago
Description: | modified (diff) |
---|
Minimal replay for r17144.