[We the People] Bug reporting

My game always crashes at the exact same turn and I cannot seem to change this. Is there a way to fix this?
Up until this point it was a great game. Thanks for your great work!
I did some debugging on your save file and could localise the bug to probably be in the AI code. But then I'm completely stuck, so I will have to leave that to the experts ... :(
Only suggestion would be to go back to older save games to try and find a save where the bug does not occur. If you still have older saves from the same game, you could send them to me and I could check if the problem (a negative number of units in an AI area) is already present there
 
a negative number of units in an AI area
That bug is known. We already got 2 other reports about it. :(
It is related to the area calculation - and indirectly caused by "Large Rivers".

@Nightinggale has an idea how we could fix this, but it is lots of effort.
Thus it has not happened yet but we will most likely get it fixed before release. :thumbsup:

@jooe If you want to know more about it, maybe ask @Nightinggale.
(He had analyzed the bug and knows best about it.)
 
That bug is known. We already got 2 other reports about it. :(
It is related to the area calculation - and indirectly caused by "Large Rivers".

@Nightinggale has an idea how we could fix this, but it is lots of effort.
Thus it has not happened yet but we will most likely get it fixed before release. :thumbsup:

@jooe If you want to know more about it, maybe ask @Nightinggale.
(He had analyzed the bug and knows best about it.)

Is playing the game again from a few turnes before the crash going to change anything? Don't want to try it, if it is a general problem which will occur nevertheless.
 
Is playing the game again from a few turnes before the crash going to change anything?
It might, it is probably just a single Unit that is somewhere confusing the area logic (i.e. if it belongs to a Water Area or Land Area).
  • So if that Unit may move another way, the CTD might not occur.
  • If you open Worldbuilder and successfully delete the Unit the CTD might not occur.
You might be lucky and prevent that CTD that way this time and be able to continue playing. :dunno:
However, until this bug is really fixed in the logic, it is still possible that you may run into a similar CTD later in the game again. :(

Edit:
You might also try to replace all "Large River"-Plots in the Map by "Coast"-Plots.
(That should completely prevent the CTD if I am correct about its cause.)
 
It might, it is probably just a single Unit that is somewhere confusing the area logic (i.e. if it belongs to a Water Area or Land Area).
  • So if that Unit may move another way, the CTD might not occur.
  • If you open Worldbuilder and successfully delete the Unit the CTD might not occur.
You might be lucky and prevent that CTD that way this time and be able to continue playing. :dunno:
However, until this bug is really fixed in the logic, it is still possible that you may run into a similar CTD later in the game again. :(

Edit:
You might also try to replace all "Large River"-Plots in the Map by "Coast"-Plots.
(That should completely prevent the CTD if I am correct about its cause.)

I was having the same problem. I tried turning all large rivers into coast, and that didn't help.
I then tried using the "erase" tool to sanitize anything even vaguely near where a large river used to be, and that didn't help either
what can I do to further help troubleshoot the problem?
 
I was having the same problem. I tried turning all large rivers into coast, and that didn't help.
I then tried using the "erase" tool to sanitize anything even vaguely near where a large river used to be, and that didn't help either
what can I do to further help troubleshoot the problem?

I also tried to fix this by erasing and changing the river tiles to coast tiles.It didn't solve the problem.
I started an older save game (1695 instead of 1700). The game crashed two turns later (1701 instead of 1700).
 
@rpgarcher @Latitudero
Thanks for the info. :thumbsup:

Then we simply need to wait for the proper analysis and actual bugfix.
(Then you guys as a player probably can not do anything about it at all.)
 
update:
I erased everything in south America, and that let the turn pass without crashing.
Then I erased smaller chunks at a time, and erasing the area around the Amazon River fixed the issue.
Erasing just the area around the Amazon river didn't fix the issue.
Started erasing even smaller chunks. I have 2 saves, the first crashes, the second I erased a single city and it doesn't crash
Erasing just that city on my play save still crashes.

I don't know that any of that is at all helpful (I can provide the saves if it would help someone), but I'm officially in over my head and completely perplexed. Gonna leave it alone for a while
 
Then I erased smaller chunks at a time, and erasing the area around the Amazon River fixed the issue.
I expected something like that. As we already found out it is an issue in area calculation.
(And most likely it only affects areas that have "Large Rivers".)

However:
Please give us some time to properly anaylze it and fix it. :thumbsup:
(It is currently "family and friends season" for all of us.)
 
@jooe
The bug-fixes for the Null-Pointers (of pPlot) you had reported have been commited.
(Just in case you did not see the commit and had this still on your list.)
 
So I was asking myself if checking for NULL might just be a "symptom fix", that is why I posted the additional information ...
No, that is normal C++ programming. :)

It is not a "symptom fix", you need to check them everywhere they might occur. Basically almost everywhere you access objects.
The code literally has thousands of NULL-Pointer checks. (NULL-Pointers is pretty normal in C++. But again also easy to notice and fix normally.)
Pointers* and references& will essentially do the same thing once compiled. The difference being that references can't be NULL. This means if you have code where you know a pointer can't be NULL, then use a reference instead to clearly state that it won't be NULL. If this is used consistently then you should assume all functions returning pointers to possibly return NULL. This naturally assumes programmers have picked pointer vs reference properly, which sadly might not always be the case.

In this specific case NULL is indeed a valid return value as that is what will be returned whenever an invalid plot is requested. This way caller doesn't have to check if the plot is valid (checking coordinates and stuff), but rather just check for NULL, which is way less prone to bugs.
 
I have a save game where going to the next turn consistently crashes the game. Up until this turn in this game, I had no problems. I'm wondering if someone can take a look? I'm playing WTP 3.0.1

Thank you!

I also am getting an error when first opening the game, saying:
--------
Traceback (most recent call last):
File "FaireWeatherTweakEx", line 3134, in getCustomMapOptionDefault
AttributeError: 'CyGlobalContext' object has no attribute 'getDefaultCityCatchmentRadius'
--------

Not sure if it's related to the game crashing (I've seen errors like that in the past and I tended to just ignore them and the game and mod still seemed to work fine).

Edit:
I went into worldbuilder and saved the game as a scenario. When I start up that scenario, I get this error:
-----
??? Tag: ??? Read: 630440552 Excepted non-negative n...
Colony is storing negative amount of cargo.
Please make a bug report and provide a savegame from just before this happened.
Be aware that the autosave from this turn might be from after this happened if it happened just as the turn started
-----
followed by maybe fifty of the same errors as above but with different numbers after the "Read".
All the cargo slots in my colonies have turned to 0, but everything else looks normal. If I go to the next turn, again I get fifty of those "Colony is storing negative amount of cargo" messages.

If I save this game as a regular game (not as a scenario in worldbuilder), and then reload this game (starting from a point after all my colony cargo slots have become 0), I am able to go to the next turn without any error messages.

Edit 2: I loaded the game from a point before where it crashes and saved that in worldbuilder as a scenario, and when I load up that scenario, it also gives me the "Colony is storing negative amount of cargo." error messages, so perhaps this issue has nothing to do with the game crashing in my save.
 

Attachments

Last edited:
FAULTING_SOURCE_CODE:
11480: YieldTypes eYieldProducedType = (YieldTypes)kProfession.getYieldsProduced(0);
11481: // R&R, ray , MYCP partially based on code of Aymerick - END
11482: FAssert(eYieldProducedType != NO_YIELD);
11483:
>11484: if (kProfession.isWorkPlot())
11485: {
11486: if (pPlot->getWorkingCity() == pCity)
11487: {
11488: if (kProfession.isWater() == pPlot->isWater())
11489: {


....

bool CvPlot::isWater() const
{
return (getPlotType() == PLOT_OCEAN);
}

Should it not be isOcean() if only oceanwater is considered worthy to be wet?

What would be the best way to fix this?
 
bool CvPlot::isWater() const
{
return (getPlotType() == PLOT_OCEAN);
}
Should it not be isOcean() if only oceanwater is considered worthy to be wet?

You are confusing "PlotTypes" with "TerrainTypes". :nono:

-------

Every single Water Terrain is STILL PLOT_OCEAN.
  • TERRAIN_LARGE_RIVERS --> PLOT_OCEAN
  • TERRAIN_LAKES --> PLOT_OCEAN
  • TERRAIN_ICE_LAKE --> PLOT_OCEAN
  • TERRAIN_COAST --> PLOT_OCEAN
  • TERRAIN_SHALLOW_COAST --> PLOT_OCEAN
  • TERRAIN_OCEAN --> PLOT_OCEAN
-------

There are only 4 PLOT_TYPES in the game.
  • PLOT_OCEAN
  • PLOT_LAND
  • PLOT_HILLS
  • PLOT_PEAK
-------

What would be the best way to fix this?

There is no need to fix. In fact you would only break it.
You just misunderstood the concept of "PlotTypes" vs. "TerrainTypes".

-------

Summary:

There is no bug in the code above. But still thanks for reporting. :thumbsup:
(It is better to report one time too much, than one time too less.)
 
Last edited:
You are confusing "PlotTypes" with "TerrainTypes". :nono:

-------

Every single Water Terrain is STILL PLOT_OCEAN.
  • TERRAIN_LARGE_RIVERS --> PLOT_OCEAN
  • TERRAIN_LAKES --> PLOT_OCEAN
  • TERRAIN_ICE_LAKE --> PLOT_OCEAN
  • TERRAIN_COAST --> PLOT_OCEAN
  • TERRAIN_SHALLOW_COAST --> PLOT_OCEAN
  • TERRAIN_OCEAN --> PLOT_OCEAN
-------

There are only 4 PLOT_TYPES in the game.
  • PLOT_OCEAN
  • PLOT_LAND
  • PLOT_HILLS
  • PLOT_PEAK
-------



There is no need to fix. In fact you would only break it.
You just misunderstood the concept of "PlotTypes" vs. "TerrainTypes".

-------

Summary:

There is no bug in the code above. But still thanks for reporting. :thumbsup:
(It is better to report one time to much, than one time too less.)
Alright, but why in all the world did the crash dump report state that snippet of code was faulting? Something caused it to crash
 
Alright, but why in all the world did the crash dump report state that snippet of code was faulting?
You are saying that this piece of code caused an issue in WTP 3.0.1 or in Plains or in your own modmod? :think:

----

I currently have no explanation why there should be any issue. :dunno:

It is this method here if I read your code sniplet right:
(You did not tell it in the file or the method in the post above.)
Code:
int CvPlayerAI::AI_professionSuitability(const CvUnit* pUnit, ProfessionTypes eProfession, const CvPlot* pPlot, UnitAITypes eUnitAI) const

----

Update:

@Ramstormp:
I checked that method but it seems to be perfectly fine.
(I can find absoltuely no error in it.)

@Nightinggale:
Could you maybe check as well?
(Maybe I was just blind and could not see something.)
 
Last edited:
You are saying that this piece of code caused an issue in WTP 3.0.1 or in Plains or in your own modmod? :think:

----

I currently have no explanation why there should be any issue. :dunno:

It is this method here if I read your code sniplet right:
(You did not tell it in the file or the method in the post above.)
Code:
int CvPlayerAI::AI_professionSuitability(const CvUnit* pUnit, ProfessionTypes eProfession, const CvPlot* pPlot, UnitAITypes eUnitAI) const

----

Update:

@Ramstormp:
I checked that method but it seems to be perfectly fine.
(I can find absoltuely no error in it.)

@Nightinggale:
Could you maybe check as well?
(Maybe I was just blind and could not see something.)
It is my modmod of course, but I thought it was a self-evident bug in the core mod. The '>' is from the crash dump that I just copied and pasted. I do think there might be some redundancy in the setPlotType logic, or at least it is extremely confusing. Take this for example:

Code:
        if (GC.getTerrainInfo(getTerrainType()).isWater() != isWater())
        {
            setPlotType(((GC.getTerrainInfo(getTerrainType()).isWater()) ? PLOT_OCEAN : PLOT_LAND), bRecalculate, bRebuildGraphics);
        }

But don't spend too much worrying about it. Maybe if it shows up again for normal people something ought to be done.

EDIT:
Nevermind explaining the last code snippet. I understand why there has to be so much water; except it is not enough water, because PLOT_OCEAN should also be water. PLOT_WATER would make things a little less confusing to someone like me
 
Last edited:
I understand why there has to be so much water; except it is not enough water, because PLOT_OCEAN should also be water. PLOT_WATER would make things a little less confusing to someone like me
I agree PLOT_WATER would be better. It's named in vanilla where water and ocean is pretty much the same thing. My only concern is if we rename and miss renaming somewhere, like something hidden in vanilla.

As for the bug itself (if it is a bug), I can only see that line crashing if eProfession is NO_PROFESSION. If that's the case, then the bug is in the caller and the debugger is needed to figure out what is going on.
 
Problem : I can't breed sheep the same way, that I could horses.
Answer : Sheep can only be breed on hills



Edit : made it simple QA format. No need to even look into discussion. Anyone looking for keyword sheep will just have Q and A.
 
Last edited:
Back
Top Bottom