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

Considerably raise Locomotor WaitAverage and WaitSpread #15129

Merged
merged 1 commit into from May 22, 2018

Conversation

Projects
None yet
3 participants
@reaperrr
Copy link
Contributor

reaperrr commented May 10, 2018

This considerably reduces frequency of repathing attempts when blocked by other moving actors, without too much of an impact on in-game repathing speed, since most of the time the blocking actor doesn't move out of the way that fast anyway. In other words, this should reduce the percentage and number of failed re-attempts to enter a cell on the path quite a bit.

On my system, this cuts the number of Move entries in perf.log by more than half on RA shellmap.
According to additional manual testing, the average path ticks for a larger moving group - after the initial spike right after the order was given - are notably lower, which makes sense, since actors in large, moving groups happen to be blocked by actors moving in front of them quite often.

No update rule, because I expect any modder who already uses custom values to either a) already use similarly large values, or b) at least read the changelog of each release/playtest.

Considerably raise Locomotor WaitAverage and WaitSpread
This considerably reduces frequency of repathing attempts without too much of an impact of in-game repathing speed, since most of the time the blocking actor doesn't move out of the way that fast anyway.
@pchote

This comment has been minimized.

Copy link
Member

pchote commented May 11, 2018

IIRC there is a major gotcha hiding in here, which is why we haven't done this in the past. Please hold on this until I have time to try and find these earlier discussions, or try and find them in my absence!

@pchote

This comment has been minimized.

Copy link
Member

pchote commented May 21, 2018

On second thought, I may be thinking of the CloseEnough parameter.

@pchote

pchote approved these changes May 21, 2018

Copy link
Member

pchote left a comment

This is only used in the case where a unit is blocked, so this shouldn't regress anything too obvious. I expect and hope that players will complain during the playtests if this does hurt gameplay in practice.

Lets give it a try 👍

@pchote pchote added the PR: Needs +2 label May 21, 2018

@pchote

This comment has been minimized.

Copy link
Member

pchote commented May 21, 2018

#3288 is what I was thinking of, but IIRC at some point recentishly (I remember working on this PR, but not which one it was) we changed the way that the pathfinder handles delays. Can anyone confirm that this is true, and then we can close that issue?

@abcdefg30 abcdefg30 merged commit 9e95cd5 into OpenRA:bleed May 22, 2018

2 checks passed

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

This comment has been minimized.

Copy link
Member

abcdefg30 commented May 22, 2018

@reaperrr

This comment has been minimized.

Copy link
Contributor Author

reaperrr commented May 22, 2018

@pchote #3288 is still an issue, but it's caused by the internal averageTicksBeforePathing, while the Wait* delay only affects the automatic repathing after getting blocked by some moving obstacle.
I just tested bleed and this PR to make sure, but while #3288 clearly isn't fixed, this PR at least doesn't make it worse, for the reason above.

@reaperrr reaperrr deleted the reaperrr:higher-wait-avg branch Jul 5, 2018

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