Build times are affected by game speed about singularity HOT 6 CLOSED

Yes, you are right. My bad. There are a lot of different timing issues.

Every tick, the game calculate how much it could complete yours base. The result is the maximum
percentage of completion and is a float. Now to have the real amount, it needs to multiply it with total cost. The result is very close to a integer except you have float and float have rounding errors and floating point errors. It's sufficient to allow to spend one more minute in your base building every some tick.

The code use the ceiling function. With the rounding function, the error is gone.

Replace
cost_paid = numpy.maximum(numpy.cast[numpy.int64](numpy.ceil(raw_paid)), was_complete)
by
cost_paid = numpy.maximum(numpy.cast[numpy.int64](numpy.round(raw_paid)), was_complete)

Another solution could be using the minimum between the amount spent and the amount that can be spent. But I think it's overkill. The only case when the percent is not close to a integer is when percent is capped. But in this case, by definition, it can't be superior to the capped number (in float representation).

P.S.: I have done my test in speed 3. It works. I didn't check it in other speed.
In my case, the base is finished at 23:48.

from singularity.

That fixes it for me too, and I tested in speeds 2, 3, and 4. I think you should make a pull request for it.

Oh, and the reason the base finished at 23:48 for you is that you didn't switch to speed 2 at 23:44 like I did.

from singularity.

@dwentz89 , care to see if this issue was fixed?

from singularity.

Sorry, it's still happening exactly as I described.

Base construction uses mins_passed, not secs_passed, so that change shouldn't affect it at all.

from singularity.

I found the origin of the problem. Tick are played completely. But some action can be finished before tick end time. In most game, it's not a problem because tick are very fast. But we have very long tick with the slower speed settings.

Correct solution would allow tick to be partially played and abort with the time passed. But we need a major rework of the main game loop.

from singularity.

@Xenega That'd be a nice change too, but I don't see how it'd help this issue. The issue I found is that builds finish sooner than scheduled on low game speeds, but the issue you describe causes builds to finish later than scheduled on high speeds.

To use a variant of my example above, if you start a 24 hour build on day 5 at 00:30 and run at speed 2 until it finishes, it'd finish on day 5 at 23:07 because of my issue. If you instead run at speed 4, it'd finish on day 6 at 04:00 because of your issue. If both issues were fixed, it'd finish on day 6 at 00:30 regardless of game speed.

from singularity.