[Bug] Workers underestimate improvement build times

Zetetic Apparat

Warlord
Joined
Jul 19, 2006
Messages
276
How to reproduce:
Set worker building an improvement.
On each subsequent turn examine the turns remaining.

Expected behaviour:
'Turns remaining' steadily decrements (4,3,2,1),
and then the improvement is completed on the following turn.

Actual behaviour:
'Turns remaining' decrements in the following fashion - 4,3,2,1,1 - before improvement completion on the following turn. (This means that for all but the last turn, the worker has been lying.)

Other information:
Based on my inspection of the Lua, calling :GetBuildTurnsLeft(buildType, 0, 0) on a plot, returns the same (wrong) values as shown in the UI.

Thalassicus corroborates my report here. Although ZXTT seems to corroborate this bug here, here later seems to have withdrawn the report here. I am now fairly sure that there is a real issue here.

This is different to this possible bug.
 
I'm sure other people must have noticed this but it's just a minor annoyance: The number of turns it takes a worker to finish an improvement is displayed incorrectly. During the last 2 turns, it always displays as 1 turn remaining.

It's also weird that the first turn adds 200 build points while each of the following turns only add 100. Lastly, when chopping a feature for the build, pre-chopping is not taken into account in the tooltip when you switch over to another build (for example when you build a mine on a jungle but have pre-chopped, it isn't taken into account in the calculation for the mine)
 
i'd guess this is due to rounding down for the display when you have the pyramids or the worker construction rate policy... i don't think i've seen this happen without one of those?

ie instead of 8 turns it should take 5.33, which actually takes 6 turns, but says 5 initially
 
i'd guess this is due to rounding down for the display when you have the pyramids or the worker construction rate policy... i don't think i've seen this happen without one of those?

ie instead of 8 turns it should take 5.33, which actually takes 6 turns, but says 5 initially

No, the game rounds correctly, it's the underlying function that's broken and I'm 100% positive that Pyramids or Citizenship don't matter for this bug.

There is actually another bug with Pyramids and Citizenship. They aren't coded as a cost decrease like the tooltip suggests but as a speed increase. Normally a worker adds 100 points per turn to an improvement (200 for the first), with Pyramids he adds 150 (300 for the first). This means that, for example, a Farm takes 700/150 - 1 = 3.67 turns (rounded up to 4) instead of the expected 3, and is once again an example of the devs failing at the most basic mathematics: 1/(1+x) != 1 - x except for very small x
 
No, the game rounds correctly, it's the underlying function that's broken and I'm 100% positive that Pyramids or Citizenship don't matter for this bug.

There is actually another bug with Pyramids and Citizenship. They aren't coded as a cost decrease like the tooltip suggests but as a speed increase. Normally a worker adds 100 points per turn to an improvement (200 for the first), with Pyramids he adds 150 (300 for the first). This means that, for example, a Farm takes 700/150 - 1 = 3.67 turns (rounded up to 4) instead of the expected 3, and is once again an example of the devs failing at the most basic mathematics: 1/(1+x) != 1 - x except for very small x

i was wrong. where are those numbers from?

regarding the effects, they both say "increase worker construction rate" which is what they're doing. they don't say "decrease time to construct things."
 
i was wrong. where are those numbers from?

regarding the effects, they both say "increase worker construction rate" which is what they're doing. they don't say "decrease time to construct things."

Looks like I fail at basic language comprehension rather than the devs at basic maths, you're right. The numbers are from querying the build progress in Lua and comparing to worker build results. Let me do some maths:

If your worker speed before the modifier is s and worker speed after is s', with cost c and turns to build t:

t = (c - s)/s = c/s - 1

while

t' = c/s' - 1

So t/t' = (1/t')/(1/t) [the ratio of rates] = s'(c - s)/(s(c-s')) = s'/s * (c-s)/(c-s') instead of the expecetd s'/s; for a farm c = 700, s = 100, s' = 150 then t/t' = 1.63... (t' = 3.667 turns)
 
ah ha.
i bet the problem is they use the same formula for original calculation as they do for time left, and they're different because of the first turn 'bonus' construction.

it initially says 6 turns for farm, which requires 700 time units of work.
100 units of work are immediately completed when you click build farm the first time, maybe for the purpose of adding the incomplete farm graphic or maybe just poor programming
if you click back on the worker immediately after build farm, it says build farm (5) when it is still going to take 6.
 
ah ha.
i bet the problem is they use the same formula for original calculation as they do for time left, and they're different because of the first turn 'bonus' construction.

it initially says 6 turns for farm, which requires 700 time units of work.
100 units of work are immediately completed when you click build farm the first time, maybe for the purpose of adding the incomplete farm graphic or maybe just poor programming
if you click back on the worker immediately after build farm, it says build farm (5) when it is still going to take 6.

No, that doesn't really explain it because then the time left should display correctly instead of staying at "1 turn left" for two turns. Without seeing the code I can't really tell, but Firaxis should have enough info to fix this annoying bug. Heck, I can even fix it in a mod (and will do so in the next version of PWM)
 
No, that doesn't really explain it because then the time left should display correctly instead of staying at "1 turn left" for two turns. Without seeing the code I can't really tell, but Firaxis should have enough info to fix this annoying bug. Heck, I can even fix it in a mod (and will do so in the next version of PWM)

it could explain it. it might not be true but it makes sense to me, and fits the behavior.
ie

TurnsToComplete()
{
return (TotalImprovementTime - CurrentImprovementTime) / (ConstructionRate + 1)
}

TurnsToCompleteDisplay()
{
int time = TurnsToComplete()
if (time > 1)
return time.ToString() + " turns to complete"
else
return "1 turn to complete"
}


i suspect this because it does initially display correctly, and as soon as you've started building displays incorrectly until it's done
 
Top Bottom