Bug Reports and Discussion

I get negative production sometimes on cities with governor's manor when playing Calabim. Such cities are then stuck and can't produce anything.
 
I get negative production sometimes on cities with governor's manor when playing Calabim. Such cities are then stuck and can't produce anything.

I've seen the reports for this and have a bug entered but I dont know how to reproduce it. I've played numerous games with the Calabim and Governors Manors and havent had cities enter negative production. I've also tried with Pillar of Chains. If anyone can deduce what exactly causes it to happen, I'd be happy to fix it.
 
It doesn't happen with version 2.51 which I downgraded to. At least not yet.
If that holds true, then it's something new on later versions.
Here Phil Hall has some ideas on the issue: http://sourceforge.net/p/tholalsffhaimod/bugs/246/

In my experience with the bug, it's somewhat random but after a few dozen turns, it happens in at least one city if you have many with manors. I tried switching workers but it doesn't help, indeed the one time I did it just got worse the following turn, so maybe it's related to the game switching workers around for different hammerage and it has to recalculate things.

I hope that helps... if you need a report, I could reinstall the latest patch and play a game until it happens... and send you the autosaves both before and after the issue.
 
Here are my saves. The city of Itos is about to build governor's manor, and the turn right after that it already has negative production. It doesn't always behave like this, as there are other cities with that building but not showing the bug.
 

Attachments

I've seen the reports for this and have a bug entered but I dont know how to reproduce it. I've played numerous games with the Calabim and Governors Manors and havent had cities enter negative production. I've also tried with Pillar of Chains. If anyone can deduce what exactly causes it to happen, I'd be happy to fix it.

As you mention in your bug report, I also suspect that this bug is related to my unhappy production fix (for those who don't know, see http://sourceforge.net/p/tholalsffhaimod/code/1652/), although I have not been able to check what is happening. Jojo_Fr reported that the issue started happening after the Illians casted Stasis (see http://forums.civfanatics.com/showpost.php?p=13068866&postcount=601) so maybe my new code is interacting with Stasis in a way I did not foresee, triggering this issue.
 
Jojo_Fr reported that the issue started happening after the Illians casted Stasis (see http://forums.civfanatics.com/showpost.php?p=13068866&postcount=601) so maybe my new code is interacting with Stasis in a way I did not foresee, triggering this issue.

If you look at Krinn's save you can see it happening without Stasis. Just as soon as the Manor is built the production for that city goes into the negatives. Other cities with Manors have the expected production and I dont see anything peculiar about Ito in his game. Probably need to step through it with a debugger to figure out whats triggering the problem.
 
So, while I'm playing More Naval AI modmod some units are not showing correct (like arcane units, see screenshot below). It's not only showing the unit correctly but if I happen to build one the game crashes. I'm playing on some 2.5x patch (forgot which). I also tired the most recent 2.53 patch but it didn't seem to fix the problem.

Any idea how to fix this, rather annoying, issue?

 
So, while I'm playing More Naval AI modmod some units are not showing correct (like arcane units, see screenshot below). It's not only showing the unit correctly but if I happen to build one the game crashes. I'm playing on some 2.5x patch (forgot which). I also tired the most recent 2.53 patch but it didn't seem to fix the problem.

Any idea how to fix this, rather annoying, issue?

Sounds like you have a bad installation. Uninstall FFH, re-install the latest version, then patch More Naval AI on the top of it.
 
As you mention in your bug report, I also suspect that this bug is related to my unhappy production fix (for those who don't know, see http://sourceforge.net/p/tholalsffhaimod/code/1652/), although I have not been able to check what is happening.

I've tried to figure out what is going on and the problem eludes me. The error seems to occur during the AI_juggleCitizens function, but I think the issue actually occurs well before the assert is triggered.

So unless Terkhen (or someone else) can step in and solve this issue, I'm going to have to roll back Terkhen's fix to Unhappy Production.
 
I've tried to figure out what is going on and the problem eludes me. The error seems to occur during the AI_juggleCitizens function, but I think the issue actually occurs well before the assert is triggered.

So unless Terkhen (or someone else) can step in and solve this issue, I'm going to have to roll back Terkhen's fix to Unhappy Production.

I'll give it a look this weekend.
 
I managed to give it a look today, and after some hours of checking code I think I found the reason of the problem.

CvCityAI::AI_juggleCitizens uses CvCityAI::AI_plotValue to know which plot is the worst, and this method in turn calls CvCityAI::AI_yieldValue. From what I gather after looking around in the code, CvCityAI::AI_yieldValue expects to calculate the absolute changes in city yields after changing a specific plot. To do so it calculates the changes in yields, and this calculation requires using getBaseYieldRate.

Since AI_yieldValue is not taking into account any possible changes to unhappiness, and it is using the default call to getBaseYieldRate (which relies on current happiness), it is not returning a real estimation. As the AI evaluates the algorithm and it starts juggling citizens from one plot to another, the AI_yieldValue for plots it has already calculated will change without it knowing about this. Needless to say, this messes up the algorithm, resulting in the CvCityAI::AI_juggleCitizens assert being triggered and the city production ending up messed up.

From my point of view, the simplest solution to this problem would be not taking into account unhappy production while calculating the value of specific plots. This solution will imply that the AI will not take into account unhappy production while deciding which plots to work, but it will still be taking it into account when making decisions that affect the city as a whole such as deciding when to whip, what buildings to create and so on.
This would only require changing line 10982 from what it is now to:

Code:
// Bugfix: Unhappy production is now calculated in getBaseYieldRate. We ignore it in plot value calculations in order to avoid overcomplicating the algorithm.
//int iOldCityYield = getBaseYieldRate((YieldTypes)iI);
int iOldCityYield = getBaseYieldRate((YieldTypes)iI, false);
// Bugfix end

Taking into account unhappy production in this method would require making a new version of the CvCity::unhappyLevel method which should be able to calculate how would the unhappiness level change after we start or stop working a certain plot. Given the amount of data it would require to estimate, for the small benefit of just making citizen placement work a little better in certain situations, I'd rather not have unhappy production into account in this specific calculation. Let me know what you think of this solution :)

Back when I sent this patch, I reviewed all calls to getBaseYieldRate in order to prevent errors like this one, but in order to be sure I reviewed them all again. All other calls come from either evaluating building value or city value, and since they do not change the city production around while making calculations, they should be safe. AI_buildingValueThreshold will not take into account unhappy production when choosing a building and therefore the AI could be making choices such as creating buildings that negate unhappiness in cities with unhappy production, but that's more of an improvement than a bugfix and it is something it was already doing before anyways.

While making this review, I found a place in which the code should be slightly altered for the sake of performance. In CvCity::findBaseYieldRateRank, the source code is making two identical getBaseYieldRate calls in a loop. Since calling getBaseYieldRate is now more costly, it should be doing the following instead:

Code:
for (pLoopCity = GET_PLAYER(getOwnerINLINE()).firstCity(&iLoop); pLoopCity != NULL; pLoopCity = GET_PLAYER(getOwnerINLINE()).nextCity(&iLoop))
{
int iLoopCityBaseYieldRate = pLoopCity->getBaseYieldRate(eYield);
if ((iLoopCityBaseYieldRate > iRate) ||
((iLoopCityBaseYieldRatez == iRate) && (pLoopCity->getID() < getID())))
{

I have not tested the bugfix or the performance change yet, but I will do so this weekend. Is there a fast way to test if the bugfix work, such as a savegame from shortly before this issue happens? If not, I'll just fire up many Calabim automated games in maps with a lot of population and resources in order to see if I manage to trigger it again.
 
Check out Krinn's first save from this post - http://forums.civfanatics.com/showpost.php?p=13194932&postcount=507 - Ito finished building a Manor in two turns and goes into negative production.

Thanks for pointing me to it :)

After 5 attempts I did not manage to reproduce the issue. Do I need to do something besides pressing Shift + Enter until Itos builds the Governor Mannor? I also waited a few turns after building it just in case.

EDIT: I'm using the latest MNAI revision, r1696.
 
After 5 attempts I did not manage to reproduce the issue. Do I need to do something besides pressing Shift + Enter until Itos builds the Governor Mannor? I also waited a few turns after building it just in case.

Strange. I had no problems reproducing it. Things get out of whack the turn it finishes production. I was using the skip-turn feature by clicking the Armageddon Counter display, though I cant imagine why that would make any difference.
 
Strange. I had no problems reproducing it. Things get out of whack the turn it finishes production. I was using the skip-turn feature by clicking the Armageddon Counter display, though I cant imagine why that would make any difference.

I tried to reproduce it again, both with that savegame and by running additional games, and failed. I decided to go ahead, implement the suggested fix, and post it here along with a compiled dll to let others test if it worked or not. Sadly, I finally managed to reproduce the 0 production issue... when I was testing if my fix broke something else or not. This means that we are back at square 1 :)

I'm going to try to debug what is happening exactly in AI_juggleCitizens. I'll report back once I get to know what is wrong.
 
Back
Top Bottom