Single Player bugs and crashes v38 plus (SVN) - After the 20th of February 2018

If you select those two game options on start, then you will end up with "minimum city border" active and "city start with 1 tile" being disabled, as if it wasn't selected at all.
Disagree it should be the Other way around raxxo! Dad gummit! We agree as a team when 1 City was added in that Minimum City Border was a sub optimal Option to start with. Especially so if RCS was in use as well. Grrrr…...gritting my teeth Willy nilly changes without checking. smh
 
Disagree it should be the Other way around raxxo! Dad gummit! We agree as a team when 1 City was added in that Minimum City Border was a sub optimal Option to start with. Especially so if RCS was in use as well. Grrrr…...gritting my teeth Willy nilly changes without checking. smh
I can change it, those players had no idea that certain options don't mix at all.

And inverted those now:
"City starts with one tile" now disables "Minimum city borders" if both are selected.
Tooltip descriptions also were changed accordingly.
 
Last edited:
Disagree it should be the Other way around raxxo! Dad gummit! We agree as a team when 1 City was added in that Minimum City Border was a sub optimal Option to start with. Especially so if RCS was in use as well. Grrrr…...gritting my teeth Willy nilly changes without checking. smh
I'll back you on this. One must override the other and since I don't personally care which, you can have it this way. The XML tag is in place to allow one to override the other and that's kinda nice.
 
I'll back you on this. One must override the other and since I don't personally care which, you can have it this way. The XML tag is in place to allow one to override the other and that's kinda nice.
I already switched those as he wanted.
 
I can change it, those players had no idea that certain options don't mix at all.

And inverted those now:
"City starts with one tile" now disables "Minimum city borders" if both are selected.
Tooltip descriptions also were changed accordingly.
Thank you. :)
 
Arguably this is more of a balance question than a bug, and might have been discussed already, but Tree Hollows and Animal Burrows are only replaced by Caves (and Neanderthal Caves), not by the housing from Shelter Building. Similarly, Lean-Tos aren't replaced by Caves. This creates an odd effect where if you lack the resources/tech for the better "Shelter Building" houses, you end up either a) somehow suffering more unhealthiness because your citizens are living in both trees and lean-tos (if you don't have caves) or b) some of your citizens inexplicably decide to leave their caves to live in lean-tos instead, increasing unhealthiness.

Would the following chain be more logical?

Homeless -> Animal Burrows -> Tree Hollows -> Lean-Tos -> Grass Huts
Lean-Tos -> Caves
 
Arguably this is more of a balance question than a bug, and might have been discussed already, but Tree Hollows and Animal Burrows are only replaced by Caves (and Neanderthal Caves), not by the housing from Shelter Building. Similarly, Lean-Tos aren't replaced by Caves. This creates an odd effect where if you lack the resources/tech for the better "Shelter Building" houses, you end up either a) somehow suffering more unhealthiness because your citizens are living in both trees and lean-tos (if you don't have caves) or b) some of your citizens inexplicably decide to leave their caves to live in lean-tos instead, increasing unhealthiness.

Would the following chain be more logical?

Homeless -> Animal Burrows -> Tree Hollows -> Lean-Tos -> Grass Huts
Lean-Tos -> Caves
I can agree with this. You wanna address it @raxo2222 ?
 
Here's the minidump.
Sorry it's taken me so long to look at this but we did, surprisingly, get some clear results out of the minidump.

@Toffer90 and @KaTiON_PT : A little while back someone posted a screenshot showing the hover help tooltip on a promotion wasn't displaying the linked text referring to a combat class. The crash here is related. Something is fishy with the new linking method in some cases. Obviously it's fickle as to who's going to experience a problem and who isn't and why is a little bit of a mystery to me. The crash with this one is taking place in finding a null reference - or bad allocation somehow - to a GetCString call here:
Code:
                        szHelpString.append(gDLL->getText("TXT_KEY_TRAIT_TECH_RESEARCH_MODIFIER_ADDITIONAL", CvWString(GC.getTechInfo(eTempTech).getType()).GetCString(), GC.getTechInfo(eTempTech).getTextKeyWide()));
when it goes to parse the text for one of the traits. I'm not a good enough programmer to follow the yellow brick road further than this but it seems to be connected somehow. I'm not saying this is a PPIO issue, though Fermongu did say:
Repeatable CTD (no error messages) after endturn. Latest SVN and PPIO.
and he's getting the crash while I am not.

Is there some way this could be caused by some difference in the way PPIO handles this? Like a font difference creating a bad allocation in the CString somehow? If this continues to be an issue, we'll probably have to go back to using the literal link method, which is problematic in its own ways. What do you think? That's really my only suggestion on how to resolve things, but I might also have a limited understanding on these string issues that's keeping me from seeing an easier answer.

EDIT: As suspected, Ultimara's mini shows the same crash point. He's been able to get the list to come up safely on numerous occasions as well, so somehow this is a truly unreliable crash issue and it seems to only be affecting PPIO players.
 
I can agree with this. You wanna address it @raxo2222 ?
Yes.

Homeless -> Animal Burrows -> Tree Hollows -> Lean-Tos -> Grass Huts OR Caves.
So each later entry will replace all earlier entries just like its done for bridges.

So looks like Lean-Tos is missing from current chain.
Animal Burrows and Tree Hollows requires Cave Dwelling (second ones any forest too), Lean Tos require Shelter Building, which is column later, and then it is required by Neanderthal Caves/Cave Dwelling, that is unlocked by Cave Dwelling tech, but need Caves in vicinity.
Grass Huts require Shelter Building just like Leantos, but it needs grass resource and very tall grass feature.
Next one - Bark Huts is good distance from here at Bark Working.

This means Lean Tos will never get autobuilt, if caves are in vicinity.
 
Last edited:
Sorry it's taken me so long to look at this but we did, surprisingly, get some clear results out of the minidump.

@Toffer90 and @KaTiON_PT : A little while back someone posted a screenshot showing the hover help tooltip on a promotion wasn't displaying the linked text referring to a combat class. The crash here is related. Something is fishy with the new linking method in some cases. Obviously it's fickle as to who's going to experience a problem and who isn't and why is a little bit of a mystery to me. The crash with this one is taking place in finding a null reference - or bad allocation somehow - to a GetCString call here:
Code:
                        szHelpString.append(gDLL->getText("TXT_KEY_TRAIT_TECH_RESEARCH_MODIFIER_ADDITIONAL", CvWString(GC.getTechInfo(eTempTech).getType()).GetCString(), GC.getTechInfo(eTempTech).getTextKeyWide()));
when it goes to parse the text for one of the traits. I'm not a good enough programmer to follow the yellow brick road further than this but it seems to be connected somehow. I'm not saying this is a PPIO issue, though Fermongu did say:
I'll look into it, see if I can't manage to reproduce the crash with PPIO and debug what's going on in python right before the crash. Would help if somenone figured out what exactly makes the game crash, I could always go through the pedia looking at every single page and mousing over everything that got a hover help pop up, but that would take time.

Are you saying that there are some few cases where GC.getTechInfo(eTempTech).getType() equals null, and that the crash happens when CvWString(null).GetCString() is porcessed...
... or perhaps GC.getTechInfo(eTempTech) equals null and that the game crash when CvWString(null.getType()).GetCString() is processed.
 
It seems like the AI doesn't understand how to properly deal with damage from terrain. I've discovered that one of my neighbours, who's cut off from the rest of the world by a large stretch of taiga, is sending wanderer after wanderer on suicide missions through the taiga, all pretty much following the same path and just walking forwards until they die. The "Explore" automation has the same problem. Obviously, the solution would be to use forced march (if the AI is actually able to do that; I haven't actually seen them use it and have been avoiding using it myself too), to grind up 2 levels to get the promotion that lets you ignore taiga terrain damage, or failing that to just stop trying to explore there. But the AI doesn't seem to understand that the area is effectively unexplorable without the right promotions.

I'm working on getting a save and log file, but it may take a bit since I've discovered the game wasn't properly recording the logs for the last time it happened, and all the wanderers are dead at the moment.
 
Are you saying that there are some few cases where GC.getTechInfo(eTempTech).getType() equals null, and that the crash happens when CvWString(null).GetCString() is porcessed...
... or perhaps GC.getTechInfo(eTempTech) equals null and that the game crash when CvWString(null.getType()).GetCString() is processed.
Neither. I'm saying that it's coming up with a bad memory allocation when it asks for GetCString(). The tech exists and is a valid reference but for some reason it's pulling up a bad or incompatible GetCString() reference. Maybe this has to do with the font not including a character it's calling for properly or something like that... I really don't understand it in full. Something is invalidating the GetCString() itself.
 
It seems like the AI doesn't understand how to properly deal with damage from terrain. I've discovered that one of my neighbours, who's cut off from the rest of the world by a large stretch of taiga, is sending wanderer after wanderer on suicide missions through the taiga, all pretty much following the same path and just walking forwards until they die. The "Explore" automation has the same problem. Obviously, the solution would be to use forced march (if the AI is actually able to do that; I haven't actually seen them use it and have been avoiding using it myself too), to grind up 2 levels to get the promotion that lets you ignore taiga terrain damage, or failing that to just stop trying to explore there. But the AI doesn't seem to understand that the area is effectively unexplorable without the right promotions.

I'm working on getting a save and log file, but it may take a bit since I've discovered the game wasn't properly recording the logs for the last time it happened, and all the wanderers are dead at the moment.
There would be really no fast way to let the AI know that the expanse it's trying to explore is too thick with damaging terrain to trigger such an adjustment of strategy without a HUGE and time-consuming evaluation process. Some AI foibles are better left in place. The better trick would be to have it count the number of hunters and/or explorers that have perished and after a point put a moratorium on training more, assuming it is having a problem with an ultra-lethal condition somewhere. Add a time decay to that so that after a while they can try it again later. This would help them with situations where a HUGE apex predator like a Sabretooth is right off their borders killing anything that emerges before it gets much of a chance to get anywhere too. NOT saying I'm going to do that soon - some AI's just get a raw deal. But it's the better long term response I think. Sometimes you just can't train the AI to think with the depth of a human and have to use shortcuts or the turn times will get far too prohibitive.
 
I bet I can make something to create a danger value for the path but id rather stay away from the second part (getting the ai to use that value correctly)
so if some1 ever wants to do the ai let me know and ill do step1
 
Ok. Another report of AI foolishness. 444 turns into the game, Isabella just switched over to native language from no language. Several other civilisations have yet to gain a language at all. Looking in Worldbuilder, Isabella (at least; I didn't check the others) has not just Language but technologies that treat it as a prerequisite, so she's obviously had it for a while. As far as I can tell, there's no reason not to switch over to native language as soon as you can, so the AI is behaving suboptimally.
 

Attachments

Ok. Another report of AI foolishness. 444 turns into the game, Isabella just switched over to native language from no language. Several other civilisations have yet to gain a language at all. Looking in Worldbuilder, Isabella (at least; I didn't check the others) has not just Language but technologies that treat it as a prerequisite, so she's obviously had it for a while. As far as I can tell, there's no reason not to switch over to native language as soon as you can, so the AI is behaving suboptimally.
Perhaps. To keep the AI from constantly being in anarchy from most optimal changes taking place with great regularity, including switches back and forth endlessly, it has to build up a number of desired civic adjustments before it will make them. Koshling did that a while ago and I have no interest in trying to learn where or how that all works. That said, if there's no anarchy in the change and its an improvement, then it should be resistant to adjusting things.

I bet I can make something to create a danger value for the path but id rather stay away from the second part (getting the ai to use that value correctly)
so if some1 ever wants to do the ai let me know and ill do step1
Koshling worked on the pathing side of the AI and it's something I try to avoid messing with as well.


Guys, I'm sorry if I sound unappreciative of the reports. They are valid and good to note and eventually address. I'm a little unengaged from the project for a bit and personally a little tired of working on things right now, so my feelings are probably coloring my responses. I'm prioritizing the things that REALLY need to be addressed and hoping we can get things balanced and enjoyable for a version release soon. So if I come across as having a bad attitude, it's just the exhaustion I'm currently feeling. I'll eventually recharge the batteries and throw myself back into the fray.

One of the things I really want to work on next is getting Great Aviators into play. Whether that will happen pre or post-release is looking more like it'll lean towards post-release. In the meantime I'll be on autopilot and playing and looking for the MUST fix issues that need to be resolved before we can have a nice clean release this time. I'm not going to let this devolve at the last minute like it has in the past. That's not to say we're on a freeze... but I personally am for a bit as I mostly observe feedback for now.
 
Last edited:
Perhaps. To keep the AI from constantly being in anarchy from most optimal changes taking place with great regularity, including switches back and forth endlessly, it has to build up a number of desired civic adjustments before it will make them. Koshling did that a while ago and I have no interest in trying to learn where or how that all works. That said, if there's no anarchy in the change and its an improvement, then it should be resistant to adjusting things.
Aren't some civic categories exempt from anarchy?

Civic categories and or civics, that never increase anarchy time should mean, that AI isn't reluctant to switch them at all.
 
@Thunderbrd did you test your changes?
I did AI autoplay test on Noble/Standard/Normal for 10 - 20 turns and game crashed.
Then I couldn't load any autosaves.

AI autoplay itself may be broken though.

Now I'm doing test without autoplay.
Got another crash very early.
This is repeatable crash.
 

Attachments

Last edited:
got a repeatable crash right away on current NEW SVN

mini and save in zip

EDIT: put back old dll and the next turn went right thru
 

Attachments

Last edited:
got a crash right away on current NEW SVN

mini and save in zip
While save could be loaded I found, that food tooltips are bit wonky.
And yes, this game crashed on turn processing too.
Spoiler :

Civ4BeyondSword 2019-04-08 09-06-57-50.jpg
Civ4BeyondSword 2019-04-08 09-09-11-52.jpg

 
Back
Top Bottom