Opened 8 years ago

Closed 8 years ago

Last modified 6 years ago

#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 elexis)

Reproduce:

  1. Start match with mauryan civ
  2. Move the worker elephant near a resource
  3. Let a unit gather the resource

After the unit finished gathering, it often can't dropoff the resources.

https://trac.wildfiregames.com/raw-attachment/ticket/3539/woman_stuck_in_elephant.gif

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)

commands_woman_stuck_in_elephant.txt (15.5 KB ) - added by elexis 8 years ago.
Minimal replay for r17144.
woman_stuck_in_elephant.gif (358.7 KB ) - added by elexis 8 years ago.
groupObstruction.patch (4.4 KB ) - added by mimo 8 years ago.
patch to fix the obstruction group problem described in http://trac.wildfiregames.com/ticket/3539#comment:4

Download all attachments as: .zip

Change History (13)

by elexis, 8 years ago

Minimal replay for r17144.

by elexis, 8 years ago

Attachment: woman_stuck_in_elephant.gif added

comment:1 by elexis, 8 years ago

Description: modified (diff)

comment:2 by elexis, 8 years ago

Milestone: Alpha 19
Resolution: duplicate
Status: newclosed

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 mimo, 8 years ago

Milestone: Alpha 19
Resolution: duplicate
Status: closedreopened

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 mimo, 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 mimo, 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).

comment:6 by mimo, 8 years ago

In 17145:

fix switch between square or circle approximation in UnitMotion, refs #3539

comment:7 by mimo, 8 years ago

In 17146:

fix passability of mauryan support elephant, refs #3539

by mimo, 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:8 by mimo, 8 years ago

Owner: set to mimo
Resolution: fixed
Status: reopenedclosed

In 17154:

fix obstruction of target entity not taken into account in short pathfinder, closes #3539

comment:9 by elexis, 7 years ago

Description: modified (diff)

In r17184:

revert r17145 which was based on misunderstanding of the algo, and fix the inverted_circle case, refs #3577

comment:10 by elexis, 6 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.