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 bug in production queue projections #1603

Merged
merged 1 commit into from Jun 13, 2017

Conversation

Projects
3 participants
@Dilvish-fo
Member

Dilvish-fo commented Jun 12, 2017

A bug introduced with the shift to percentage completion caused early termination of calculations relating to elements with a repeat count greater than 1, which would then often cause elements later in the queue to show substantially premature projected completion times (up to hundreds of turns difference).

A simple test case I used to compare results was starting up a single player game with mostly default stats, but no monsters, no AIs, and choosing Gysache. I advanced for 5 turns with no other actions, to get the production meter to plateau, and then added 5x2 Scouts (5 repeats of a 2-unit block), 20x2 Outpost ships, 10x5 Outposts ships and another 10x5 Outpost ships. Without this correction the projections for first completions show projected as happening after 2, 13, 73 and 117 turns; with this correction they are projected at 2, 15, 184 and 384 turns (which appear as accurate as I can reasonably confirm without deleting all ships as they are produced).

Even if we are not too concerned actually about predictions of things 70+ turns in the future, a discrepancy of ~15% already 13 turns out, which apparently can steadily increase up to 150% at ~75 turns out, seems like enough that I think if we do wind up doing a bugfix release for 0.4.7, that this should be included in that (should we have a label or milestone for that?)

@Dilvish-fo Dilvish-fo added this to the v0.4.8 milestone Jun 12, 2017

Show outdated Hide outdated Empire/Empire.cpp Outdated
Fix bug in production queue projections
A bug introduced with the shift to percentage completion caused early termination of calculations relating to elements with a repeat count greater than 1, which would then often cause elements later in the queue to show substantially premature projected completion times.
@Dilvish-fo

This comment has been minimized.

Show comment
Hide comment
@Dilvish-fo

Dilvish-fo Jun 13, 2017

Member

OK, I've augmented the comment and pushed a replacement commit.

Member

Dilvish-fo commented Jun 13, 2017

OK, I've augmented the comment and pushed a replacement commit.

@geoffthemedio geoffthemedio merged commit a74075f into freeorion:master Jun 13, 2017

2 checks passed

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

@Dilvish-fo Dilvish-fo deleted the Dilvish-fo:prod_queue_sim_correction branch Jun 16, 2017

@Vezzra

This comment has been minimized.

Show comment
Hide comment
@Vezzra

Vezzra Jun 19, 2017

Member

should we have a label or milestone for that?

I think a milestone (something like "0.4.7.1 bugfix release") should fit the bill. I've opened a thread to discuss the suggestion of making a bugfix release and a proper procedure for that.

Member

Vezzra commented Jun 19, 2017

should we have a label or milestone for that?

I think a milestone (something like "0.4.7.1 bugfix release") should fit the bill. I've opened a thread to discuss the suggestion of making a bugfix release and a proper procedure for that.

@Vezzra Vezzra added this to Proposed in 0.4.7.1 Bugfix Release Aug 11, 2017

@Vezzra Vezzra moved this from Proposed to Accepted in 0.4.7.1 Bugfix Release Aug 20, 2017

@Vezzra Vezzra modified the milestones: 0.4.7.1 Bugfix Release, v0.4.8 Aug 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment