Koshling: I have here 3 saves for your perusal for the food issues. the first is from the old DLL as of SVN r525. the second is a resave, only change being the new DLL. The third is one turn later, during which food processes were performed. I hope this will help isolate whatever is causing gradual food skewing.
View attachment 301262
Ok, taken a look. There is something screwy going on here but I still can't pin it down as it's still in the saved states, but the inter-turn processing!
Your old save works fine. It recalculates from scratch on load (as part of the format conversion) and comes up with the right numbers. However, your second save, which is the same turn but from the new DLL has the growth numbers doubles (needs twice as much food to grow). If I load your old save and then save it myself in the latest DLL, and reload THAT it's all fine. So the question is what did you do differently (from loading in the latest DLL and immediately resaving) to generate the second file?
The third save is consistent with the second (no extra distortion), so whatever is causing the problem happened somehow in the differnce between save 1 and its resave, though directly doing that here is not yielding a problem.
Edit - BTW in my earlier post showing the base calculations I forgot the era modifier - that doubles things in prehistoric
Update - I have hacked a version that allows me to revolution as often as I want (i.e. - mutilple times in one turn), and used that to test the effect of switching in and our of civics. I can't find any issues with food in the latest DLL. However, there was a small maintenance calculation bug which I have fixed.
Because I can't seem to find the underlying cause of the food issues I have just modified things so that it gets recalculated from scratch each turn. The only downsides are:
1) Small performance penalty (but I've profiled it to check, and its negligible (13 milliseconds in my current game))
2) If any Python is added that tries to directly change the food threshold/growth rate modifiers then it's changes won't stick. However we have no such Python and it's actually quite hard to imagine a case where you'd want to do that. If we ever do, I can add a separate Python-contribution variable to keep track of it
Will push this to SVN later today after more testing and some other changes I also want to get done today.