Bug Reports

[jdog5000]

I think zappara meant iNativeAmerica vs iNativeAmerican, which I have just fixed ... good find zappara.

 

[Duneflower]

Grrrf...I think I've managed to make everything not-work in RevMP (primarily Rev and BCiv - no revwatch/revindex bar and not much barb activity), and I know there's something obvious (besides the gameoptions ) I should check but I can't remember what it is. >.< Little help here?

 

[jdog5000]

Huh? If you're not getting the rev index bar in cities or the revwatch che icon, then the Python portion of the mod is not loading. So maybe the answer to your question is to turn off hide Python errors and enable the logging system in CivilizationIV.ini?

 

[Duneflower]

I already have Python exceptions unhidden, but all I'm getting there is a silly error from BarbCiv complaining that the always-minor list has no attribute "set_key" which I'm sure I've fixed before but can't remember how...the logging, though, thanks for reminding me - I keep forgetting how to do that.

 

[zappara]

I got the following bug report to RoM forum and I'm thinking there might be small bug in BarbarianCiv python:

Hi,

i tried to setup a game, where all civs would be in war with each other for duration of the game. I have set up the following options:
- start as minor civs
- permanent war or peace
- permanent alliances

This worked at the beginning of the game (i'm at war with every civ i met early on).
But for later civs i get a dialog with only one option: there will be peace in our times. And that's it. After that, I can't even declare war on them.
So the above settings aren't working as i thought they would.

What would be corrent settings for my "problem"?
Is it even possible to setup such a game?

I'm playing RoM 2.8, BtS 3.19.

I glanced through BarbarianCiv (I'm assuming he had this option on since he was telling about later civs) but didn't notice anything that could cause the above situation. Am I even looking at the right file or is the bug somewhere else?

 

[Fierabras]

Just downloaded and installed RevDCM 2.71, but it's unplayable due to a bug in the contact screen with other civs:

 

[phungus420]

The above bug is caused by leaving any old version of RevDCM around when updating, old version files break the 2.7 file format, and is most noticeable in diplomacy, but there are other things that break.

For the most part you could simply install twice, as the RevDCM installer should run the uninstaller to remove old version automatically when run the second time. Unfortunately Windows 7 can stop this from working, as it arbitrarily blocks the operation of the uninstaller when it's executed by the installer. For windows 7 users, it seems you need to manually run the RevDCM uninstaller (or manually delete the RevDCM folder) before installing. Also I'm sure Windows 7 being arbitrarily overzealous with this security protocol is going to break other software when you update it, so you may consider setting your security settings on windows 7 to something more sane.

 

[Fierabras]

Thanks, phungus. I suspected as much and used the uninstaller and installed again and now it's working fine.

 

[phungus420]

I have found a bug where when you ally with an AI (requires the gameoption Permanent Alliances to be on), and you direct them to research techs any tech you tell them to research is then completed in a single turn. Doesn't matter what you direct them to research, you get the tech next turn. The only culprit I can think of tech diffusion, but who knows. I am also sure that the techs I'm directing the AI to research that then are teched in a single turn are not filled up with diffusion research, or at least they should not be; this is the cleanup stage of the game and I am far ahead in tech, which is the reason I allied in the first place, I was trying to finish the game a little faster.

I am uploading a save with the bug; to see the bug in action just direct Willem to switch research. The save is for LoR, but I'm sure this is in RevDCM, as the only code changes in the current version of LoR and RevDCM is that the Inquisitions code wasn't ported to the SDK (needed to maintain save game compatibility with previous LoR version, wasn't worth it in my mind to break save game to implement that RevDCM under the hood coding change), and some civilopedia display stuff; also there are new units and what not, but that's all XML and art, couldn't cause this type of bug. I'm positive I ran across this before, but just forgot about it, I believe it has been around for some time, since RevDCM 2.5 or earlier, and may in fact be a bug intrinsic to BtS. It's also a hard bug to reproduce, because it only seems to occur if you play out the game naturally and then ally with the AI in the modern era (must have the Permanent alliance option on).

Reporting the bug here because I think only really jdog could find the cause and fix it. Jdog if you have any ideas of what I should do to help debug it, please let me know, but I have no idea where to start in terms of looking for the cause, let alone figure out how to fix it.

 

[jdog5000]

Hmmm ... that is a strange one.

If you have a chance, the first step to try debugging this is to figure out which call to CvTeam::setHasTech is being called. Put a break point at the top of that function and check out the call stack when it triggers for your team (0 in single player usually). There are a whole bunch of ways techs can be acquired, figuring out which one is causing it should be a useful clue.

 

[phungus420]

Compiling a debug dll and playing results in numerous C++ runtime exception errors a few turns into the game; you get a pop up in windows with the bad thing just happened windows sound. It's unplayable, and if you tell it to debug the error you get taken to some random Xhash code that I've never seen before.

It looks like there is a serious error in RevDCM source right now.... I guess none of us bothered to check a debug dll for a while.

 

[glider1]

I've attached a list of the asserts I've been seeing in a debug build of RevDCM271. I'd say the barbworld/IDW assert could be serious but then again . It occurs a few turns through with either the combination of Revolutions/IDW and/or barbworld/IDW.

The turn01 asserts I'd say at a guess are fairly routine to fix . The modload assert has been around for a long time I think . The gameinit assert only happened once and I cannot track it at this stage.

I'll take a look, but please do not assume that I will fix them all. It is a free world for anyone to fix.

Enjoy
Cheers.

 

[phungus420]

That first one, the C++ runtime library one, I'm getting every couple turns, at least after a few dozen turns are played in AI Autoplay. It makes the debug dll unusable, and is thus a serious problem.

 

[Afforess]

The first one is a serious error, and should definitely be fixed. IDK what you guys did to break that, since debug builds are working for AND source code, which is based off of 2.7

The two asserts that say "We should not call these on ourselves" are from AI Autoplay, and are harmless. Just comment them out. The NO_IMPROVEMENT one indicates a python or XML issue. Not critical, but it should be fixed. The bSuccess in CvXMLLoadUtility is also harmless, and due to WoC. You can comment it out too. The last one is probably caused by Revolutions, checking on a dead rebel or something. Just change it to return false for invalid indices and be on your way.

I'm glad you guys are finally paying attention to these asserts though, most modders, even good ones, seem to be ignoring them and they give fairly valuable information, as long as you know how to weed out the broken garbage and the real problems.

 

[glider1]

Yeah the second one the "NO_IMPROVEMENT" espionagemission that hasn't shown up again. The other autoplay and XML one's I agree are small issues and have been there along time.

The first error I must stress is in the combination of barbworld/revolutions + IDW (took me some time to track down). I'd say it is due to the changes that were made to IDW and city capturing (from memory) that happened after 2.7.
Cheers

 

[phungus420]

There wasn't a change made to city capturing that I know of, there is some code set up to handle the cultural shift on a tile with a city on it though. This is in RevDCM 2.7, you can search for it's implementation by tracking the GDA value IDW_CITY_TILE_MULTIPLIER the function references. I can't think of anyway this could be causing the problem, the code is pretty simple but who knows. I'm unable to check it now, and probably wol't be able to for a couple of days either, otherwise I'd be looking at it now with more to comment on.

 

[Afforess]

The first error I must stress is in the combination of barbworld/revolutions + IDW (took me some time to track down). I'd say it is due to the changes that were made to IDW and city capturing (from memory) that happened after 2.7.
Cheers

I disagree. Why on earth would that be related to isHasMet calls in CvTeam? Barbarian influence is team # 50, and only teams that are alive will have culture, so if anything, it rules IDW out as a cause.

 

[phungus420]

glider1 was correct, the assert is being caused by my IDW code that modifies the culture change on a city tile. Specifically the issue is popping up in CvUnit::influencePlots. Lame mistake on my part, was using GC.getDefineFLOAT("IDW_EMERGENCY_DRAFT_ENABLED") when it should have been GC.getDefineINT("IDW_EMERGENCY_DRAFT_ENABLED")). Have fixed in the SVN now.


Thanks glider for zeroing in on the cause. Now that this has been dealt with, and all other asserts are harmless (should probably implement a flag for AIAutoPlay that will silence those asserts if and only if AIAutoPlay is on, and wouldn't hurt to fix whatever in BarbarianWorld causes that NO_IMPROVEMENT assert, but these are benign so I'm not sure how important these "fixes" are) I'm not so concerned. However I must again point out the tech bug for alliances causing 1 turn tech research is a big problem. This is a major bug, as it effectively destroys the Permanent Alliance game option, and really needs to be fixed so that this default BtS game option is playable again. I feel this bug should take priority over other things in RevDCM, as it would be nice to get all the default BtS features working in single player.

 

[glider1]

Such a simple fix I'll leave the permanent alliance bug for a short while (agree that fixing permanent alliance is important) and hope that Jdog might get onto it. Meanwhile I'll go back and work on Lemmy's MP changes. I think Lemmy is actually testing his MP code utilising his own mod, and hopefully will pass on any findings to RevDCM.
Cheers

 

[phungus420]

Hmmm ... that is a strange one.

If you have a chance, the first step to try debugging this is to figure out which call to CvTeam::setHasTech is being called. Put a break point at the top of that function and check out the call stack when it triggers for your team (0 in single player usually). There are a whole bunch of ways techs can be acquired, figuring out which one is causing it should be a useful clue.

Tried this, and it leads nowhere, you just end up watching the function go around through CvString.h and CvGlobals and CvTeam as the function adds the tech to the team. Nothing interesting going on here, at least nothing that appears to stand out.

This is expected though, because the bug isn't happening when the tech is set to the player. The bug occurs when you direct the AI to research a tech, it takes 1 turn to research. Basically it's behaving as though the AI has alot of beakers stored up, so that no matter what it picks, it has the necessary ammount of tech to research in a single turn.

Further testing shows that in the save above, that when I switch to willem I can research about 2 techs for a single turn, then things go back to normal. If I keep playing myself without switching teams, the same thing occurs. I get about 2 other free techs, and then research returns to normal. This makes about 5 free techs that I got from the alliance.

I think the problem occurs when the alliance is made. There is some error being caused by Tech Diffusion, which is causing the normal free tech grant from tech diffusion that my ally gets to flow over into new techs which he shouldn't get any bonus beakers for. I believe this is because the ally was backwards before becoming an ally, but when the alliance happens the tech diffusion beaker grant doesn't take into account the new tech level, and instead causes a spillage over of free beakers for the ally. Also, as I said before I think this bug is also in base BtS, it's just far more noticeable and sever in RevDCM. I believe it's also necessary to check the espionage grant when an alliance forms, as the same bug could be cropping up there as well.