RBP3 IT Office - Email and technical issues

[WarriorKnight]

Reload is fine with us too.

[Maniac Marshall]

If there are no objections voiced while I'm at work, then please reload to Ilios' login from last turn, should be ~2-3 minutes on the clock and pause? I did change a tile at a DIFFERENT city in the last couple of minutes, not sure if it was before or after that login.

Then I can log in, make that swap, look at the problem city, make 500% sure everything is as it should be (though I know it HAS to be), then I'll log out and let the turn roll with no one in game and see what happens.

If the bug reoccurs, we'll live with it. I can also make the relevant portion of our spreadsheet available to look at later if anyone wants to see it, but I have to go to work now.

[Shoot the Moon]

Carthage too is fine with the reload.

[T-hawk]

I looked at the code to process growth and the granary effect, and figured out why the 16/36 food situation happened. Short version:

City was whipped to size 6. The granary's hidden food storage (called FoodKept in the game code) is clamped at 16 (half of the 32 food box.) City grows to size 7. The city produced so much surplus food this turn that it ends up with 34/34 in the food box. FoodKept remains at 16.

City is now size 7 with 34/34 food in the box. It is set to build a settler so it runs 0 food surplus this turn. City grows to size 8. FoodKept is still 16 because the city did not run any food surplus this turn. If it had, then FoodKept would have increased then clamped to the normally expected 17. Hence the 16/36 outcome.

So the granary's hidden store only had the size-6 value. It never increased to the size-7 value because the city never ran any surplus food while at size 7.

That explains the missing food, but I still can't explain the missing hammers on the settler (which is the more important part.) If we can reload and have Marshall post a screenshot of all the city's hammer sources, I'll see if I can figure out where any hammers might have leaked or disappeared.

[Swiss Pauli]

Maybe the extra citizen ate two food before production was calculcated, explaining the difference between expected 101/100 and end result of 99/100 Settler?

[SevenSpirits]

Maybe the extra citizen ate two food before production was calculcated, explaining the difference between expected 101/100 and end result of 99/100 Settler?

That makes total sense if the code works like:

1) Calculate food. Zero because we're building a settler, and food surplus is at least consumption.
2) City growth? Yes, we have 34/34.
3) Calculate production. (food - citizen food costs) (capped at >=0) + hammers * multipliers.

[Maniac Marshall]

Thanks for the info T-Hawk.

Well, that sounds like bad news as far as it resolving the way we would have expected it to on reload. Guess this is what we get for getting rid of the sandbox for spreadsheets 20 turns ago

Unfortunately, with zero hammer tiles we're going to probably be stuck with this situation. I'm still like to reload and see if we can solve the problem, or not if majority feel we should not based on the new info.

I will be home and able to dig into the situation in approximately 5 hours from this post, just after 1AM GMT.

[T-hawk]

Great catch Swiss. A look at the code backs that up. doGrowth() is called before doProduction(). doGrowth() can increase the city's population, but does not assign the new population point to any tile or specialist slot so he will not produce anything this turn.

doProduction() calls
getCurrentProductionDifference() which calls
getProductionDifference() which does
int iFoodProduction = getYieldRate(YIELD_FOOD) - foodConsumption()

foodConsumption() immediately sees the extra population that was created by doGrowth() so it subtracts out the 2 food so you get 2 less food-to-hammers on the settler.

So what to do about a reload? I'd say that these behaviors aren't quite a bug. Both the food and hammers are behaving as designed. But they are some pretty obscure corner cases that nobody knew, which are themselves dependent on the unusual case of growing while building a food-consuming unit. Should Marshall get a reload to optimize the city with this knowledge?

[Krill]

Yeah, I wouldn;t call either behaviour a bug, but then again, they are really weird...

[T-hawk]

OTOH, the city screen display of the situation could definitely be considered a bug. It lies: it showed 101 hammers when the game then did not apply 101 hammers. Based on that, IMO Marshall should be allowed to reload.