Production overflow explained and the return of MM
- Thread starter karmina
- Start date
karmina said:Thanks -- and no (unless Physics count)
Wait until I finish the spectral analysis of the random number generator. I have the strong suspicion that the chances of getting a "lucky result" is not independent of previous battles...
(just kidding...about the spectral part)
Hehe.
Actually did something similar for the civ3 RNG a long while back when it first came out. People were complaining so ferociously that it the results it produced were 'streaky' that I had to test it. 
So, I used the editor to remove all defense boni and sprinkled a map with warriors. After a rather meticulous counting of outcomes (the fact that civ3 saved the RNG seed in saves was helpful for experimental validity, IIRC) I found no reason to reject the hypothesis that they were anything but independent bernoulli trials. I haven't read through all your work, but i think there is a mistake at the very beginning. I guess you already know it, in that case, please don't mind my message: I'll give two examples.
Example 1:
Let's imagine i am to build a 75 hammers building, with a s bonus of 50% (i don't care about the g bonus).
My base production is 100 hammers.
So:
BP = 100
s = 50%
NP = 75
TO = BP*(1+s) - NP = 150 - 75 = 75
O (expected) = 100 - 75 = 25 (since i am not supposed to benefit from the s bonus)
In that case, C = 50.
Example 2:
BP = 100
s = 50%
NP = 85 (the building costs now 85 hammers)
TO = 150 - 85 = 65
O (expected) = 100 - 85 = 15
C = 50
As you can notice, C and s are still the same, but TO as changed. That's enough to prove that C cannot be calculated as a percentage of TO.
Actually, C should be BP * s (which is 50), and
O = Max{TO - BP*s;0} (max because it shouldn't be below 0)...
But maybe i am wrong, since my formulae is quite simple and both firaxis and you are calculating it otherwise.
Example 1:
Let's imagine i am to build a 75 hammers building, with a s bonus of 50% (i don't care about the g bonus).
My base production is 100 hammers.
So:
BP = 100
s = 50%
NP = 75
TO = BP*(1+s) - NP = 150 - 75 = 75
O (expected) = 100 - 75 = 25 (since i am not supposed to benefit from the s bonus)
In that case, C = 50.
Example 2:
BP = 100
s = 50%
NP = 85 (the building costs now 85 hammers)
TO = 150 - 85 = 65
O (expected) = 100 - 85 = 15
C = 50
As you can notice, C and s are still the same, but TO as changed. That's enough to prove that C cannot be calculated as a percentage of TO.
Actually, C should be BP * s (which is 50), and
O = Max{TO - BP*s;0} (max because it shouldn't be below 0)...
But maybe i am wrong, since my formulae is quite simple and both firaxis and you are calculating it otherwise.
KrikkitTwo
Immortal
- Joined
- Apr 3, 2004
- Messages
- 12,418
totororo said:
Actually looking at your examples it depends on how you think of the bonuses working
Project=10
BP=10
Bonus=100%
now does that mean that
1. Base production is added to the project and Then Bonus production seperately (problem being this leads to MM being effective)
2. imagine each Point of production added one at a time through out the turn and each one getting its bonus.
Project: BP
0:10
+2(+1+100%): -1
2:9
4:8
6:7
8:6
10:5
so 5 BP left
This is the most effective way to model it because this minimizes the 'effect of the turn' which leads to errors of rounding/grouping production into clumps, etc. When production is grouped into clumps like that it leads to the painful unintuitive type of MM being effective.
KrikkitTwo
Immortal
- Joined
- Apr 3, 2004
- Messages
- 12,418
Well the update supposedly has changes in it, maybe they caught this bug (which also appears in research)
DaviddesJ
Deity
Krikkitone said:
Where did you see that? I don't see anything about production overflow in the 1.52 change notes.
KrikkitTwo
Immortal
- Joined
- Apr 3, 2004
- Messages
- 12,418
I didn't see anything but there were supposedly some undocumented changes. (that's why I Hope they fixed it)
DaviddesJ
Deity
Zombie69 said:
Do you still get penalized on your carryover if you keep building the same thing with the same bonuses?
DaviddesJ
Deity
Zombie69 said:
That sounds great! I'll have to look at it carefully once I finish GOTM 1 and can switch.
DaviddesJ
Deity
I checked out the claims about production overflow being fixed in v1.52, and there's one oddness. Overflow appears to be what it should be (in the cases that I checked), except that there's a cap on the possible overflow equal to the production cost of the last thing you built. So, e.g., if you are building a warrior (cost 15), and you're at 10/15, and you chop a forest for +30, and you add another 2 hammers from regular city production, you would expect overflow of 10+30+2-15 = 27, but instead the overflow is capped at 15.
This may be a "feature" rather than a "bug", but, in any case, it's important to be aware of.
This may be a "feature" rather than a "bug", but, in any case, it's important to be aware of.
LordTerror
Chieftain
- Joined
- Sep 9, 2005
- Messages
- 73
Wow, that's interesting. Thanks for finding this.DaviddesJ said:
I have one question though. You said "...equal to the production cost of the last thing you built", but in your example, you only have the current production (a Warrior). Did you mean to say "...equal to the production cost of the thing you are currently building", is your example wrong, or do I not understand what you are trying to say?
StevenJoyce
Chieftain
- Joined
- May 11, 2004
- Messages
- 31
I don't think the overflow cap is new -- I noticed under 1.09.
DaviddesJ
Deity
LordTerror said:
If you just finished a Warrior (cost 15), and you had 42 hammers of production toward the Warrior, then you'll get only 15 hammers of carryover, not 27. This applies regardless of what you decide to build with the carryover.
When you're applying the carryover, then, by definition, you're not building the same thing any more. It's finished---that's why you are getting carryover.
Good to hear they really fixed this issue with the last patch! (haven't checked it myself yet)
About the overflow cap, there was something similar before, but it was way higher (about 2-3 times the city's base production), and thus allowed for limited wonder prebuilts.
Lowering the cap is definitely a good thing, although it might have made more sense to have a cap relative to the city's production rather than to the current product. As it is now, the same city can get you more overflow from e.g. a tank than from a much cheaper explorer.
About the overflow cap, there was something similar before, but it was way higher (about 2-3 times the city's base production), and thus allowed for limited wonder prebuilts.
Lowering the cap is definitely a good thing, although it might have made more sense to have a cap relative to the city's production rather than to the current product. As it is now, the same city can get you more overflow from e.g. a tank than from a much cheaper explorer.
ClavisRa
Chieftain
Two cents: Overflow from one turn to the next should not even exist; it completely violates the spirit of the game model. Civ4 should force you to queue up enough projects to use up all the production on the current turn.
Correspondingly, there's no reason you shouldn't produce more than one thing a turn if you have lots of hammers and relatively cheap projects.
Project to project overflow is very simple to manage. All modifiers to production can be combined into one combined multiplier. If you have overflow on a project, just divide the overflow by the combined multiplier to get the number of raw hammers overflow to the next project. Repeat the same process until all the hammers are expended.
Correspondingly, there's no reason you shouldn't produce more than one thing a turn if you have lots of hammers and relatively cheap projects.
Project to project overflow is very simple to manage. All modifiers to production can be combined into one combined multiplier. If you have overflow on a project, just divide the overflow by the combined multiplier to get the number of raw hammers overflow to the next project. Repeat the same process until all the hammers are expended.
Similar threads
