Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix transport being blocked by its own passengers. #16313

Merged
merged 1 commit into from Mar 26, 2019

Conversation

@tovl
Copy link
Contributor

commented Mar 15, 2019

When determining whether it can unload its cargo, a transport craft will now ignore transient actors. This prevents the UnloadCargo action aborting early due to some of its own passengers blocking the exits. This regression was introduced by #16060.

Fixes #16307 .

@@ -214,7 +214,7 @@ public bool CanUnload()
}

return !IsEmpty(self) && (aircraft == null || aircraft.CanLand(self.Location))
&& CurrentAdjacentCells != null && CurrentAdjacentCells.Any(c => Passengers.Any(p => p.Trait<IPositionable>().CanEnterCell(c)));
&& CurrentAdjacentCells != null && CurrentAdjacentCells.Any(c => Passengers.Any(p => p.Trait<IPositionable>().CanEnterCell(c, null, false)));

This comment has been minimized.

Copy link
@pchote

pchote Mar 21, 2019

Member

This will return the wrong result for cases like EjectOnDeath: true that need to know if it can unload an actor right now, without waiting for transient actors to move. This will lead to units being stacked on top of eachother in the same (sub)cell.

Adding a checkTransient or immediate or similar flag to CanUnload to distinguish these cases should help.

This comment has been minimized.

Copy link
@tovl

tovl Mar 22, 2019

Author Contributor

Done.

This comment has been minimized.

Copy link
@pchote

pchote Mar 25, 2019

Member

It turns out that pretty much everything else in the EjectOnDeath code is bogus, and so this issue already exists on bleed, and still exists after the changes here - see #16353 for details.

I can confirm that the change here does work after hacking around the other issues, which we shouldn't be trying to fix in this PR.

@pchote
pchote approved these changes Mar 25, 2019

@pchote pchote added the PR: Needs +2 label Mar 25, 2019

@obrakmann obrakmann merged commit 872bf73 into OpenRA:bleed Mar 26, 2019

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@obrakmann

This comment has been minimized.

Copy link
Contributor

commented Mar 26, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.