Wierd graphic glitch every other turn

[Charky]

I am getting a graphical glitch every other turn.

It affects all the information at the top of the screen. From Income across to the month and turn number, everything is blank along that top line.

Also, when you zoom into a city everything is also blank (although you can still change which squares are being worked).

The next turn everything returns to normal. Then the following turn everything is blank again

Is there any way to correct for this? Seems very odd to me.

I put this under creation as I did a custom jiggery pokery to marathon mode on game speed, so I assume this is what is causing this.

I wanted to make a much longer game so I increased the number of turns by 2 in each "bit", but halved the advancement of months (this should in theory keep the advancement of years similar to the original setting). Im guessing the imonthincrements may have something to do with this, as I have fiddled with the other settings before with no problems., and there is some logic to it then happening every other turn. Not sure as to why it would do this as its just affecting the change in calander? Its not like its sitting in the middle of half a month (if I understand it correctly). Also, the "off turns" still produce and research, so it seems to be purely graphical

I will also mention I am playing a lan game with my son, and its happeneing to both of us. This is on Beyond the Sword on steam.

This is what I changed the values to:

<GameTurnInfo>
<iMonthIncrement>90</iMonthIncrement>
<iTurnsPerIncrement>200</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>60</iMonthIncrement>
<iTurnsPerIncrement>600</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>30</iMonthIncrement>
<iTurnsPerIncrement>340</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>12</iMonthIncrement>
<iTurnsPerIncrement>402</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>6</iMonthIncrement>
<iTurnsPerIncrement>260</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>3</iMonthIncrement>
<iTurnsPerIncrement>360</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>2</iMonthIncrement>
<iTurnsPerIncrement>400</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>1</iMonthIncrement>
<iTurnsPerIncrement>500</iTurnsPerIncrement>
</GameTurnInfo>




Not expecting a fix, but I was wondering why its doing this, ie what I may have done wrong.

Cheers guys!

 

[f1rpo]

Parts of the HUD not getting drawn usually means that a Python exception has cut the graphical update of CvMainInterface.py short. Either disabling HidePythonExceptions or enabling LoggingEnabled in My Games\Beyond the Sword\CivilizationIV.ini (or both) should show (through a popup or in Logs\PythonErr.log) where exactly the exception occurs in Python. The game date gets computed by the DLL, so it's possible that the exception will only indicate that something in the DLL (CvGameTextMgr specifically) crashes.

Wondering if the 7.5-year and 2.5-year increments (90 months, 30 months) are somehow a problem, i.e. fractional but greater than one year. On a quick glance at the DLL code, it looks like any number of months should work. Well, let's perhaps first see if the game date really is the problem.

My Excel sheet for helping me tweak the game speed settings says that your changes sum up to 3062 turns covering 6080 years and 4 months. That's pretty close to the standard 6050 years (4000 BC until AD 2050), and, at 3000 turns, it would be 2 times slower than Marathon. Would arguably be a little nicer wrt. to Time victory if it were exactly 3000 turns and 6050 years, but that's a headache to puzzle out, – and I don't think there should be a problem with the totals you have. I do think that the various other speed modifiers should be adjusted, e.g. iResearchPercent raised to 500. You've probably already done so or considered it. Perhaps worth pointing out that iCulturePercent is unused; that's instead handled by Civ4CultureLevelInfo.xml. (Again, not related to graphical issues; unsolicited suggestions.)

 

[<Nexus>]

Wondering if the 7.5-year and 2.5-year increments (90 months, 30 months) are somehow a problem, i.e. fractional but greater than one year.

That would be surprising, as the game can show dates as 2000 summer and 2007 winter.

 

[f1rpo]

But that's normally the result of 6-month increments, not something greater than 12 months. Though, I agree, the game should be able to figure out that turn 1 corresponds to the year -4000 + 7.5 = -3992.5 and that this means the summer of 3992 BC. Well, it's an oddly specific-sounding date – but should not be a technical challenge.

 

[<Nexus>]

I'd also doublecheck indentation. I remember I had a bug years ago when the game refused to start because I had an extra enter in audiodefines.xml. Rarely, but sometimes even the xml files are being oversensitive

 

[Charky]

Parts of the HUD not getting drawn usually means that a Python exception has cut the graphical update of CvMainInterface.py short. Either disabling HidePythonExceptions or enabling LoggingEnabled in My Games\Beyond the Sword\CivilizationIV.ini (or both) should show (through a popup or in Logs\PythonErr.log) where exactly the exception occurs in Python. The game date gets computed by the DLL, so it's possible that the exception will only indicate that something in the DLL (CvGameTextMgr specifically) crashes.

Wondering if the 7.5-year and 2.5-year increments (90 months, 30 months) are somehow a problem, i.e. fractional but greater than one year. On a quick glance at the DLL code, it looks like any number of months should work. Well, let's perhaps first see if the game date really is the problem.

My Excel sheet for helping me tweak the game speed settings says that your changes sum up to 3062 turns covering 6080 years and 4 months. That's pretty close to the standard 6050 years (4000 BC until AD 2050), and, at 3000 turns, it would be 2 times slower than Marathon. Would arguably be a little nicer wrt. to Time victory if it were exactly 3000 turns and 6050 years, but that's a headache to puzzle out, – and I don't think there should be a problem with the totals you have. I do think that the various other speed modifiers should be adjusted, e.g. iResearchPercent raised to 500. You've probably already done so or considered it. Perhaps worth pointing out that iCulturePercent is unused; that's instead handled by Civ4CultureLevelInfo.xml. (Again, not related to graphical issues; unsolicited suggestions.)

Thankyou so much for your response.

I activated the log, and this repeats itself:

RuntimeError: unidentifiable C++ exception
ERR: Python function forceScreenRedraw failed, module CvScreensInterface
Traceback (most recent call last):

File "CvScreensInterface", line 705, in forceScreenRedraw

File "CvMainInterface", line 729, in redraw

File "CvMainInterface", line 1736, in updateGameDataStrings

File "CvMainInterface", line 1785, in updateTimeText


Im not sure why part years would be a problem when the late game you get increments of a single month? But I dont really understand it too well.

The other thing I remember changing (and forgot about) was the map size. I whacked it up to 60x45. Im sure I have played bigger than this in the past, but Im going back 20 years. Iresearch is indeed set to 500. I dropped the irecruit to 100... because civ is a wargame.... and besides my economy totally tanks when I get to 30 odd cities. In fact I redeuced a lot of the marathon settings from 300 to 100, as I want a longer game, but without having to wait 3 times as long to build anything. You could mod the game to make everything move 3 times quicker and effectively have a fast marathon game. Oh yeah... I did make the air and seas units move twice the distance to make up for the bigger map. I did love this game for allowign me to play the way I wanted to. First time I think I modded anything. This Civ does Stand the Test of Time. Just can get into the newer games.

My son just shamed me by showing me how to chose a state religion. I dont ever remember doing that before

UPDATE - I just tested it by starting new games on EPIC and MARATHON. Epic is fine. Marathon does the same thing (odd turns being the problem). Not sure if anything else in there could be the cause?


<GameSpeedInfos>
<GameSpeedInfo>
<Type>GAMESPEED_MARATHON</Type>
<Description>TXT_KEY_GAMESPEED_MARATHON</Description>
<Help>TXT_KEY_GAMESPEED_MARATHON_HELP</Help>
<iGrowthPercent>100</iGrowthPercent>
<iTrainPercent>100</iTrainPercent>
<iConstructPercent>100</iConstructPercent>
<iCreatePercent>100</iCreatePercent>
<iResearchPercent>500</iResearchPercent>
<iBuildPercent>100</iBuildPercent>
<iImprovementPercent>100</iImprovementPercent>
<iGreatPeoplePercent>100</iGreatPeoplePercent>
<iCulturePercent>100</iCulturePercent>
<iAnarchyPercent>100</iAnarchyPercent>
<iBarbPercent>280</iBarbPercent>
<iFeatureProductionPercent>300</iFeatureProductionPercent>
<iUnitDiscoverPercent>300</iUnitDiscoverPercent>
<iUnitHurryPercent>300</iUnitHurryPercent>
<iUnitTradePercent>300</iUnitTradePercent>
<iUnitGreatWorkPercent>300</iUnitGreatWorkPercent>
<iGoldenAgePercent>300</iGoldenAgePercent>
<iHurryPercent>300</iHurryPercent>
<iHurryConscriptAngerPercent>300</iHurryConscriptAngerPercent>
<iInflationPercent>10</iInflationPercent>
<iInflationOffset>-270</iInflationOffset>
<iVictoryDelayPercent>300</iVictoryDelayPercent>
<GameTurnInfos>
<GameTurnInfo>
<iMonthIncrement>90</iMonthIncrement>
<iTurnsPerIncrement>200</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>60</iMonthIncrement>
<iTurnsPerIncrement>600</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>30</iMonthIncrement>
<iTurnsPerIncrement>340</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>12</iMonthIncrement>
<iTurnsPerIncrement>402</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>6</iMonthIncrement>
<iTurnsPerIncrement>260</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>3</iMonthIncrement>
<iTurnsPerIncrement>360</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>2</iMonthIncrement>
<iTurnsPerIncrement>400</iTurnsPerIncrement>
</GameTurnInfo>
<GameTurnInfo>
<iMonthIncrement>1</iMonthIncrement>
<iTurnsPerIncrement>500</iTurnsPerIncrement>
</GameTurnInfo>
</GameTurnInfos>
</GameSpeedInfo>

 

[f1rpo]

So the Python crash is in

g_szTimeText = localText.getText("TXT_KEY_TIME_TURN", (CyGame().getGameTurn(), )) + u" - " + unicode(CyGameTextMgr().getInterfaceTimeStr(ePlayer))

and the C++ crash most likely in CvGameTextMgr::setInterfaceTime – that being the only complex function involved. (CyGameTextMgr::getInterfaceTimeStr is a wrapper for that function.) So much for standing the test of time. Actually, setInterfaceTime doesn't do much on its own either, so it's probably CvGameTextMgr::setDateStr or a subroutine thereof. To experiment with that systematically, one would need to recompile the GameCore DLL.

The XML you've posted looks like you've edited the BtS Marathon speed setting to make it slower. But when you write "Marathon does the same thing," that sounds like you've created a fourth game speed setting and left BtS Marathon as it was. Just wondering whether this rules out the Increment values as the cause of the problem – because Marathon with the original increments fails too – or whether it's worth a try to revert to the original increments as a test.

Ah, I can just copy your increments into my own mod and quickly test it with a debugger. So .... it seems that fractional years prior to AD 1 don't work correctly. Not quite what I had suspected, but close. setDateStr takes the result of getTurnMonthForGame modulo the number of months (12) and uses the result as a month index with valid indices running from 0 to 11. In the BC years, the turn month is a negative number, and the modulo operator in C++ will then have either a negative result or zero. Zero works (no month to be displayed or the 0'th, which is January), but a negative month index causes a crash.

In my book, this is a bug in the DLL. Pretty easy to fix there by replacing the modulo operator with a helper function that ensures a nonnegative result (Git commit). When modding just XML and Python, I think the only workaround is to ensure that the early-game month increments are divisible by 12.

 

[Charky]

Wow... sorry I didnt check back earlier. An amazing piece of work you did working that out.


Thats seem really silly to me. Why would it treat AD years differently to BC? Is there any other change in how the game operates at this crossover point, I wonder? Of course, I am criticising programmers who are way smarter than me from the comfort of my own armchair

Sounds like I am going to have to do some spreadsheet calculations...

So, if I understand this correctly from my table below on the standard marathon settings... If I leave the first two "eras" as is, we should end up in 500ad, and anything after that point I can adjust and hopefully not have this particular glitch? Alternatively we can play my current game until turn 700 and it should it sort itself out... ughhhh... I have far too much fun playing with spreadsheets to be normal.

<edit> actually may game might sort itself out when it hits the second era, as the game advancement proceeds by 60 months, which is divisible by 12. But would I be stuck on an "odd" or "even" year, ie be with no interface for 500 turns?

<iMonthIncrement>180</iMonthIncrement>
<iTurnsPerIncrement>100</iTurnsPerIncrement>	2500bc
<iMonthIncrement>120</iMonthIncrement>
<iTurnsPerIncrement>300</iTurnsPerIncrement>	500ad
<iMonthIncrement>60</iMonthIncrement>
<iTurnsPerIncrement>170</iTurnsPerIncrement>	1350
<iMonthIncrement>24</iMonthIncrement>
<iTurnsPerIncrement>201</iTurnsPerIncrement>	1752
<iMonthIncrement>12</iMonthIncrement>
<iTurnsPerIncrement>129</iTurnsPerIncrement>	1881
<iMonthIncrement>6</iMonthIncrement>
<iTurnsPerIncrement>180</iTurnsPerIncrement>	1971
<iMonthIncrement>3</iMonthIncrement>
<iTurnsPerIncrement>264</iTurnsPerIncrement>	2037
<iMonthIncrement>1</iMonthIncrement>
<iTurnsPerIncrement>156</iTurnsPerIncrement>	2050

"But when you write "Marathon does the same thing,""... Sorry, maybe didnt phrase it correctly. I restarted another game on marathon, and it had the same problem. I didnt create a second instance in the xml, I was just trying to replicate the problem, and confirm it was related to the marathon settings.

Anyway... thanks ever so much for your response. A 20 year old game still such amazing fun. 20 years prior to that we had Gauntlet... a whole other kind of addiction. Oh... that makes me feel old now

 

[f1rpo]

Thats seem really silly to me. Why would it treat AD years differently to BC? Is there any other change in how the game operates at this crossover point, I wonder? [...]

Just an arithmetic problem with negative numbers and the C++ modulo operator. The one in Python, for example, would not have had this problem, so it's not too surprising that the programmer got it wrong if the case of fractional early-game increments never came up in testing. I think it's a somewhat common gotcha with modulo in C/C++. And treating BC dates as negative numbers, at least at some point of the calculation, doesn't seem too strange either. Basically, adding the years passed to the start date of -4000 gives you the current year. And the code does this calculation at the level of months at first. Come to think of it, changing the START_YEAR to 0 or greater in GlobalDefines should also avoid the problem; but then your game will start in the Common Era. I suppose, on that note, the skipping of the (nonexistent) year 0 isn't really performed by the code. Looks like it'll just replace 0 with 1 if the year 0 is its final result - meaning that, at a one year-per-turn pace, the year AD 1 will get shown for two turns in a row. Well, better than going 10 BC, AD 1, AD 11, AD 21 ... when the pace is 10 years per turn. That's the only other year-0 issue I can think of. For rules purposes, it's almost always the number of elapsed turns that matters. I've actually already searched the code for other modulo sign issues; didn't find any.

So, if I understand this correctly from my table below on the standard marathon settings... If I leave the first two "eras" as is, we should end up in 500ad, and anything after that point I can adjust and hopefully not have this particular glitch?

Yes, testing it just with those changes would seem prudent before getting out the spreadsheet. For rescuing the current game, a temporary change to START_YEAR could be worth a shot.

But would I be stuck on an "odd" or "even" year, ie be with no interface for 500 turns?

Your turns per increment seem to be even, so I reckon it should add up to a whole year.

I had never heard of Gauntlet. But I can see how that's freaky; the 20 years of BtS already are.

 

[Charky]

Thanks again for explaining things. Im no programmer, but I understood most of that.

You sure you can alter files halfway through a game. I thought the save locks some of them? If we did change the start date, would that stop the barbarian hordes?

Never heard of Gauntlet??? I suspect we are of different generations

The original co-op arcade game had a 4 player mode where you had to run around a dungeon eating food and shooting things. With 4 players you ended up shooting food before someone else who was moments away from dying could get to it. Caused many a fight in real life.

 

[f1rpo]

I figured that the START_YEAR would at least get reloaded for the purpose of the game date string – generally not much of a point in caching text-related data and saving it on disk because speed is rarely a concern when generating game texts. But you're right, the start year indeed gets stored in savegames. Perhaps because the start year can also get set via a scenario file – i.e. reading it from XML is not always correct. Lots of things do get updated from XML (if the XML files have been modified) when loading a savegame, e.g. stats of units and buildings, but, even then, it's easy to introduce subtle inconsistencies that way. Really no idea how changes to the turn increments would work out. If you really want to change the start year in an ongoing game, then it can probably be done through the Python console. With maybe some weirdness concerning the doubling of building culture rates – that occurs when a building reaches an age of 1000 years.

"Shoot the food" sure has a ring to it.

 

[Charky]

Just to update...

When we got past the first "block" of 90months x 200 turns, and into the 60x500, it seems to have corrected itself. For some reason I thought Id have to go to 0 ad, but it makes sense as 60 can divide by 12.

So the game is sorted now.

<edit> after finishing our game for the evening, I decided to start a new marathon on single player to test something (without exiting civ), but for some reason every other turn was not bugged as before. I tried this with two more new games, and they were both bug free. I restarted Civ4, and tried a new game, but the bug was back. Obviously this is not a problem, but I thought I would mention it. Could a previously loaded game affect a new game in some way?

Anyways... thanks again for all your help.

 

[f1rpo]

If you had already changed the turn increment values in XML at that point, then it would be fairly unsurprising that the old savegame was still broken and that new games worked correctly. But, then, the problem would not have occurred in a new game after relaunching Civ; i.e. apparently you had not yet changed the XML file. Hm. Those attempts to access the month array at a negative index are not guaranteed to crash the program. They could also just produce some garbled characters. It depends on how the main memory gets allocated, and it doesn't seem farfetched that returning to the opening menu could make a difference. Starting a new game allocates a lot of memory and returning frees much of that.

Coincidentally, another user has run into the same issue (it seems) a couple of days ago: link to post
He's also contacted me via a direct message and shared some more screenshots. One showed that the game date in the Turn Log had strange colors and special characters on every other turn, another showed an autosave-failed popup. However, if the game dates were shown correctly in your games – alternating between January and June (July?) –, then it would seem that there was, mysteriously, no problem accessing the month names.

 

[Charky]

Yeah.. .we restarted and changed the "top number" to be divisible by 12, and had no problems this time.

We hit gunpowder in our first game and everyone else was stuck in ancient times.

Incidentally, is there a setting in the xml that determines how many cities the ai will atempt to build early on?

All the other civs were stuck at below a dozen cities while we were pushing 40 each, which made the game a little unfair. I have seen AIs populate the continent late game, but its unlikely they would have lasted that long. I am guessing some of this is related to their economies and city maintenance, but I wasnt sure if there was a direct setting. I know we will probably need to fiddle with the settiings to find an equilibrium. My son is only with me for 2 more weeks until the summer holidays, so we porbably wont start another game after this. I did ramp up the barbaians a bit (which I am instantly regretting).

 

[f1rpo]

I don't think there's any setting causing the AI to hold back on cities. Sounds like the AI civs are doing badly all around, or at least in tech and expansion speed (maybe they do have a lot of Archers ...). Increasing the difficulty level would seem the most promising to me. The impact of difficulty can also be fine-tuned in XML\GameInfo\Civ4HandicapInfos.xml. The AI behavior can't be customized much through XML.

If those games take so long, then it could be worthwhile to run some automated tests beforehand. With CheatCode = chipotle in My Games\Beyond the Sword\CivilizationIV.ini, Ctrl+Z can be used to turn on Debug mode, which reveals the map, and these two settings

; Number of turns to autorun before exit (0 for no limit)
AutorunTurnLimit = 0

; Set App on Auto-Run
Autorun = 0

... will cause any newly started game to run fully automated. There's also the command game.aiplay x - where x is a number of turns to run - on the developer console (tilde key on QWERTY keyboards) for deleting the human civ at any point and letting the remaining civs play by themselves. Or the AI Auto Play mod. None of this will work in multiplayer modes, but I guess singleplayer should be fine for getting an impression of how fast the AI techs and expands – or what it is struggling with the most. Debug mode should allow AI city screens to be opened and the Financial Advisor to be viewed from the perspective of AI civs (through a drop-down menu on the Advisor screen). Being able to fund only 30% research might dissuade the AI from expanding (referred to as "financial trouble" in the AI code). Though, given enough time to develop existing cities, its economy should recover.

 

[Charky]

Thats good to know... thanks