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

[Snofru1]

Small typos in BUG - Caveman2Cosmos screen:
Mouseover of "Hide replaced buildings" says "contruct" instead of "construct".
Mouseover of "Hide unavailable worker actions" says "preformed" instead of "performed".
Mouseover of "Ignore alerts from disabled buildings" says "recieve" instead of "receive".
Mouseover of "Battelefield promotions" says "preformed" instead of "performed".

No guarantee that these are all of them ...

 

[JosEPh_II]

I have a strange unit action going on in my game. I have Right of Passage and Embassy agreements with the Iroquois. But I have an Iroquois Pike unit that traverses my land like a scout. No Declaration of War was ever given for it entering my land. And it only seems to be this one unit too.

I would eliminate it thru WB but I don't want to see the world yet. Would greatly diminish the value of the Unknown if I did so.

 

[raxo2222]

I have a strange unit action going on in my game. I have Right of Passage and Embassy agreements with the Iroquois. But I have an Iroquois Pike unit that traverses my land like a scout. No Declaration of War was ever given for it entering my land. And it only seems to be this one unit too.

I would eliminate it thru WB but I don't want to see the world yet. Would greatly diminish the value of the Unknown if I did so.

I guess they have Right of Passage with you too.
It allows all units to go on other civ territory.

 

[Yudishtira]

I have a strange unit action going on in my game. I have Right of Passage and Embassy agreements with the Iroquois. But I have an Iroquois Pike unit that traverses my land like a scout. No Declaration of War was ever given for it entering my land. And it only seems to be this one unit too.

I would eliminate it thru WB but I don't want to see the world yet. Would greatly diminish the value of the Unknown if I did so.

Under Hide and Seek, I think using Stay the Hand, combatants can have themselves treated as non-combatants, this is so they can escort merchants etc.

 

[Thunderbrd]

I have a strange unit action going on in my game. I have Right of Passage and Embassy agreements with the Iroquois. But I have an Iroquois Pike unit that traverses my land like a scout. No Declaration of War was ever given for it entering my land. And it only seems to be this one unit too.

I would eliminate it thru WB but I don't want to see the world yet. Would greatly diminish the value of the Unknown if I did so.

Yudishtira brings up one possible answer but I doubt you'd be working with H&S so the other more likely answer is that they've taken the Guardian promotion that makes them very strong defenders, particularly against criminals, ruffians and strike teams, but renders them unable to attack. Units that cannot attack are enabled to utilize Rites of Passage.

 

[JosEPh_II]

Yudishtira brings up one possible answer but I doubt you'd be working with H&S so the other more likely answer is that they've taken the Guardian promotion that makes them very strong defenders, particularly against criminals, ruffians and strike teams, but renders them unable to attack. Units that cannot attack are enabled to utilize Rites of Passage.

The Guardian promo would explain the strange behavior. Could not figure out the Promotions it had when holding the mouse over it.

And this game is using the Vanilla BtS Combat Option only for Combat Options of any kind.

 

[JosEPh_II]

CTD at EoT. Latest SVN. Autosave set to 1. Will see if I can get past it. If not will post save game.

 

[KaTiON_PT]

Got this, might help in troubleshooting.

CvUnit* pLoopUnit = ::getUnit(pUnitNode->m_data);

Call Stack:

CvGameCoreDLL.dll!CvSelectionGroup::mergeIntoGroup(CvSelectionGroup * pSelectionGroup) Line 7571

 

[Thunderbrd]

Got this, might help in troubleshooting.

CvUnit* pLoopUnit = ::getUnit(pUnitNode->m_data);

Call Stack:

CvGameCoreDLL.dll!CvSelectionGroup::mergeIntoGroup(CvSelectionGroup * pSelectionGroup) Line 7571

This may be the gamestate issue that we still haven't been able to uproot where at times a ghost unit can exist on a plot that refers to no unit. It's a real pain and it comes up as a problem now and then. Usually, it can be solved by running the debug dll for a round, which will find and correct these errors. Then save and continue with a normal dll in play.

WHEN and HOW this bad game state becomes a factor is still a major outstanding mystery that has eluded being traced down so far.

Minis like these have a hard time really pointing exactly to the problem at times so I'm taking a bit of a guess here.

 

[JosEPh_II]

Got past the CTD. The autosave put me back at the start of the turn. While doing the turn about the 3rd item in line was the Vienna vote results pop up screen. When I clicked OK the next item/unit in line that you get in the bottom left corner was blank. Nothing selected. So I picked a unit that would be moving and selected it. After doing so the next in line came back. Have progressed 2 turns since then with saving right before I click the red button for EoT.

 

[Thunderbrd]

Got past the CTD. The autosave put me back at the start of the turn. While doing the turn about the 3rd item in line was the Vienna vote results pop up screen. When I clicked OK the next item/unit in line that you get in the bottom left corner was blank. Nothing selected. So I picked a unit that would be moving and selected it. After doing so the next in line came back. Have progressed 2 turns since then with saving right before I click the red button for EoT.

The mini suggests a crash that doesn't tend to repeat but also suggests a gamestate that is setup for a crash that can come back at any time. I still suggest running the debug dll for a round just to clean the game up a bit.

 

[JosEPh_II]

Just run the Debug dll for 1 turn right?

Or just let it finish the loading to where you can click the Red Button for EoT?

EDIT: after clicking EoT button and waiting 45 minutes for the EoT to process I used Alt- tab to see if anything was behind the game screen. There was.

Assert Failed CivCityAI.cpp line 17780 and then an expression about something in the city building.

Since I was in Alt Tab I could not bring the assert screen to the fore ground to try to click on the Ignore always, Ignore Once, Abort or Debug buttons.

By clicking ctrl/alt/del I could not go into Task manager either to shut the civ4 process down. I had to restart my comp instead.

Soooo...….I have no idea if the debug process was stalled at that failed assert or if it would've went on eventually. So much for my 1st debug effort.

 

[Thunderbrd]

Just run the Debug dll for 1 turn right?

Or just let it finish the loading to where you can click the Red Button for EoT?

EDIT: after clicking EoT button and waiting 45 minutes for the EoT to process I used Alt- tab to see if anything was behind the game screen. There was.

Assert Failed CivCityAI.cpp line 17780 and then an expression about something in the city building.

Since I was in Alt Tab I could not bring the assert screen to the fore ground to try to click on the Ignore always, Ignore Once, Abort or Debug buttons.

By clicking ctrl/alt/del I could not go into Task manager either to shut the civ4 process down. I had to restart my comp instead.

Soooo...….I have no idea if the debug process was stalled at that failed assert or if it would've went on eventually. So much for my 1st debug effort.

If you experience any delay on the debugger there's probably an assert up. The goal is to ignore them all in this case.

It helps to take the game off full screen for a debug run - sounds like you'll need to with the way you've got your computer arranged. That way you can get out and back into the game at will. It will probably take 15-30 minutes to run a turn on the debug dll but it depends on how fast you can ignore those asserts and it's also easier to see them come up when you are not on fullscreen. I use the windows button to get out of the game to see the asserts if I happen to be using fullscreen when I run the debug dll and it feels like I hit a pause.

 

[JosEPh_II]

If you experience any delay on the debugger there's probably an assert up. The goal is to ignore them all in this case.

It helps to take the game off full screen for a debug run - sounds like you'll need to with the way you've got your computer arranged. That way you can get out and back into the game at will. It will probably take 15-30 minutes to run a turn on the debug dll but it depends on how fast you can ignore those asserts and it's also easier to see them come up when you are not on fullscreen. I use the windows button to get out of the game to see the asserts if I happen to be using fullscreen when I run the debug dll and it feels like I hit a pause.

More needed info it would seem. And clears up something I was unsure of, being in Full screen.

Back to the game, I switched the dll back to normal and ran a turn, after 3min 40 secs the turn processed. I then did all the things I wanted to do and then saved the turn. After saving hit the EoT button and after another 3 mi 30+secs the cursor change from running man to regular BtS cursor and then Froze up the comp. Ugh. Nothing would respond so I hit the reset button. And that is were I'm at tonight. Don't think I will mess with it anymore until tomorrow.

 

[KaTiON_PT]

Yep, a freezing like that means an assert requires your attention outside the game.

 

[Thunderbrd]

Yep, a freezing like that means an assert requires your attention outside the game.

True if the debug dll is still in use, which although he thought it wasn't I've made the mistake before of doing the renaming wrong. The way to be sure is to look at the size of the dlls - the much larger one is the debug dll.

 

[Toffer90]

Getting at those asserts when the game is fullscreen shouldn't be that hard, either you alt+tab to the assert and use keyboard arrows and enter key to interact with the assert, don't use the mouse as the game window will snap up any mouse clicks on the screen and the game will come in focus again.

What I often do, when in debug mode, is alt+tab to my web browser right after clicking end turn, I then browse the web while the turn process and the asserts pops up in front of my web browser and they can be interacted with by the mouse.
I know when the end turn is over when I hear the sound effect the game plays at the start of a new turn. and can alt+tab into the game again at that point.

P.S. I have MemSaver = 0 (default value) in the CivIV.ini file, the comment for it claims that alt+tab won't work if it is set to 1.

 

[raxo2222]

More needed info it would seem. And clears up something I was unsure of, being in Full screen.

Back to the game, I switched the dll back to normal and ran a turn, after 3min 40 secs the turn processed. I then did all the things I wanted to do and then saved the turn. After saving hit the EoT button and after another 3 mi 30+secs the cursor change from running man to regular BtS cursor and then Froze up the comp. Ugh. Nothing would respond so I hit the reset button. And that is were I'm at tonight. Don't think I will mess with it anymore until tomorrow.

I had to reset computer when game froze in one case: when I ran out of RAM and it starts eating virtual memory (treating hard drive like RAM).
Also I always run Civ4 in windowed mode, as I have memsaver enabled (MemSaver = 1) in civ4 INI.

Ctrl+alt+del to get task manager also works in most cases.
Game can be tabbed out way faster with alt+tab when in windowed mode even when its idle.

 

[JosEPh_II]

Well here goes a New debug effort. The game is now in windowed mode and at the lowest resolution to make the window it is in the smallest.

Clicking the Red button now!

EDIT: 1st Assert was a Path Generator. Before the Assert came up the game entered a Not responding state. Which I ignored.

Question: Out of curiousity if I was to click the debug button on the assert what would happen?

So far I have been clicking Ignore always like T-brd said. 2nd assert up and ignored. This was the one I reported last night from the CvCityAI.cpp line 17780.

EDIT2: Well 7 asserts later we can advance a turn. So I run the turn with the debug still in place and get 2 more (which I click the Ignore always button). Save the game when the Green button turns red. Exit out and switch the Dlls back to normal operations.

During the turn these are the 2 asserts that came up.
1st. CvSelectionGroupAI.cpp, Line 273, expression: false
2nd. File d\c2c\caveman2cosmos\sources\CvGameCoreUtils.cpp, line 48, Expression: iHigh>=iLow, message:High should be higher than low.

 

[Thunderbrd]

Question: Out of curiousity if I was to click the debug button on the assert what would happen?

If you have Visual Studio open and 'attached' to the C2C process, it would take you directly to the line in the code where the assert is told to be thrown if the condition that triggered the assert comes up. Otherwise, it will crash to desktop.

Asserts take place because you said they should in the code for whatever reason you wanted them to. Some of them really are an indicator of a big problem and they can be hints at causes of things that happen thereafter. The ones you encountered are common ones that point towards some oddities and mysteries that have yet to be fully solved.

As for the CvCityAI assert you saw, there are some known problems somewhere in the coding that evaluates building values for the AI where some buildings are able to reach a negative value that for some reason was never anticipated as being possible - which isn't the sort of thing that's too surprising since we do a lot of unexpected stuff in the xml on buildings at times. I've never researched the issue much further except that I have directly seen some deeper problems with the building evaluation AI that begs for a bit of an audit and review for a couple of reasons that this assert MIGHT relate to but are a lot deeper than anything it is indicating itself. I THINK Koshling had added that assert and I'm not quite sure why but it's never been an indicator of a crash situation so hasn't taken priority to resolve.

The selectiongroup ones could be a few things - I'd have to look specifically but the game didn't crash so they represent more of a yellow warning than a red alert. There are a few common ones that are simply thrown by a boolean being false that probably should've been true for whatever reason. And the high/low message comes up when the combat odds of a battle are ridiculous enough to cause a more than 100% chance to win odds for a unit - at least that's what I gathered from a brief glance at it. Again, more of a yellow alert than a red.

What I'm surprised you didn't see is one that said something about correcting the position of some units that were where they shouldn't be. That would've been an indication that it really did need this. Not running across it, I'm a bit surprised. Anyhow, carry on with a normal DLL at this point.