Getting the RevDCM core working

[phungus420]

Thanks to help from Fuyu and Afforess we are finally getting the big kinks worked out of the RevDCM core, and should have a good stable release out the door pretty soon. One issue still remains though, and is kind of blocking work on the other remaining bugs, as they all revolve around the change Player function.

For the behavior of this bug what happens is if a new civ is spawned (via barbarian civ, or a Revolution) and the player switches to this newly spawned civilization, we get a bunch of python exceptions, that seem to be coming from Civ4lerts. Also interestingly enough if the player saves the game, then reloads after the civ is spawned, then switches to that player after the reload, no python errors occur. Both Fuyu and I have looked at the python errors, but are not sure exactly what the problem is (though Fuyu has a general idea) or how to go about fixing it. So EF, we're hoping you could help us out

If you want to try to recreate the bug yourself, you'll need the latest RevDCM SVN which is found here:

RevDCM itself: https://revolutiondcm.svn.sourceforge.net/svnroot/revolutiondcm/Trunk/RevolutionDCM/
RevDCM source: https://revolutiondcm.svn.sourceforge.net/svnroot/revolutiondcm/Trunk/SourceCode/CvGameCoreDLL/

Run AI autoplay with Barbarian Civs on, and switch to one of the new spawned civs once one is spawned (without saving or reloading). Including a copy of the python error logs in case you just want to take a look at those in give advice without directly testing, as I know you're busy doing your own testing with BUG and BULL.


Edit:
Nevermind Fuyu figured it out

 

[phungus420]

I've got another question/issue. With RevDCM whenever you first start all the BULL values/stuff that are also in Global Defines start with the values set in the global defines. Clicking on the BUG menu options and unchecking/rechecking, or checking/unchecking corrects it, however I'd like it so that the BULL options are saved for the player so they don't have to manually reset everything when loading up a saved game or starting a new game. The simplest way to do this I think would be to have BULL reinitialize itself on game load and on game start. What would be the best way to go about this?

 

[EmperorFool]

Wow, really? The BUG values should take precedence over those in the XML. The global defines are used only if BUG isn't active. At least, that's how it worked before. I'll take a peek to see if I inadvertently changed something. What version of BULL does RevDCM use?

 

[phungus420]

I'm not entirely sure, it's whatever Fuyu is using for Better Bug AI, so I'd assume it's the most recent, or close to it. Bug options work normally, it's only BULL options that do this, and again it's easy to fix all you do is go to the BUG options menu and click the option and it goes off of what you pick.

 

[EmperorFool]

Yeah but you shouldn't have to do that. It's like it doesn't know BUG is there initially. Does clicking one option fix all of them? Is there a specific option that does this or all of them? Better BUG AI is typically off the SVN trunk, but I haven't added anything in months.

 

[Fimbulvetr]

I can't even tell at this moment if this is just a RevDCM or a Better BUG AI issue, since for my merge I never added anything from BULL to GlobalDefinesAlt that is handled by BUG, so no conflicts between xml and BUG settings were possible to begin with.
So xml settings are loaded after the BUG settings but they shouldn't be used if there is a BUG setting that already handles it, is that correct? Or are the BUG settings simply loaded later and therefore shoud overwrite any xml settings?
And if the xml settings are used, the BUG options screen should reflect that..

I bet the simplest way around this is to simply remove everything from GlobalDefinesAlt that is handled with BUG settings. Not sure I I have the time to look at this anytime soon, let alone fix it since it's not just sdk but python too and I currently have no clue how they interact there.

 

[phungus420]

Does clicking one option fix all of them? Is there a specific option that does this or all of them?

It's wierd. Sometimes it wol't correct the first time you try, sometimes you have to switch back a couple options before it "seems" to register and then once it does everything goes to how you have it set, rather then what's in the XML. Also it appears that that you need to fix the higher option on the list first, then the ones below it will correct, but if you fix the lower options, it wol't register. It seems this way from limited testing because when I checked it Naval bombard is checked first (which means it's higher up on the tab), fixing this corrected both the Naval Bombard and Ranged Bombard, but if I just tried to check and uncheck ranged bombard, it didn't fix. Also Prechopping instantly responded once I unchecked and rechecked it, and it didn't seem to mind what I did with the ranged bombard options on another tab.

 

[EmperorFool]

The logic that occurs every time a BULL option is needed is this:

if BUG is present:
    return setting from BUG
else if setting is in XML:
    return XML setting
else:
    return default passed to getOption()

Option values are never stored in BULL proper. They are retrieved from BUG when needed or from the XML if BUG is not running. It sounds like changing a value in BUG is telling BULL "hey, I'm running" when that should be known long before.

I'll need to look in the BUG and BULL code to refresh my memory of when specifically setIsBug() in that file is called. I believe it's handled by BUG (push) during initialization.

 

[EmperorFool]

Naval and Ranged Bombard are not BULL options. I assume these are options you added, yes? How are you acquiring their values in the SDK? Can you post the code? Maybe it's different from how I do it in BULL.

 

[Fimbulvetr]

Didn't Afforess change how some options get handled to make it work with MP?
Ok I'm just guessing around here, all I know is that I never touched any part of that BULL code.

 

[phungus420]

Naval and Ranged Bombard are not BULL options. I assume these are options you added, yes?

Yes, they are part of DCM (Dale's combat mod). But this bug happens for all BULL options, such as forest pre chopping.

How are you acquiring their values in the SDK? Can you post the code? Maybe it's different from how I do it in BULL.

The DCM values are loaded from UnitInfos, like any other value in UnitInfos. If you really want, I can post the CvInfos.h and CvInfos.cpp code, but it's nothing special. Also throughout the SDK, like in CvUnit where these values are actually used, there are all sorts of GlobalDefine checks, to allow shuting off this feature, again though, nothing special, just stuff like:

					if (GC.getDefineINT("DCM_NAVAL_BOMBARD"))
					{	//standard DCM damage calculation
						int iUnitDamage = GC.getGameINLINE().getSorenRandNum(bombardRate(), "Bombard damage");//(rand() % (bombardRate()));
						collateralCombat(pPlot, pLoopUnit);
						pLoopUnit->changeDamage(iUnitDamage, getOwner());
					} else
					{
						collateralCombat(pPlot, pLoopUnit);
					}

Didn't Afforess change how some options get handled to make it work with MP?
Ok I'm just guessing around here, all I know is that I never touched any part of that BULL code.

This bug predates Afforess's code changes to allow RevDCM and BULL tab options to work in multiplayer. I was hoping when he did that, that it would fix this bug, but it did not.

 

[phungus420]

So I really think that just having BULL call to BUG and have it reinitialize it's values on game loading and on game starting would fix this. I think this because BUG stuff works fine, and all the check mark boxes in the BUG tabs are saved, just for BULL they aren't being applied and BULL uses whatsever in Global Defines (but as stated unchecking and rechecking or vice versa fixes it). So how could I just get BULL to reinitialize itself when games are loaded or when new games are started?

 

[phungus420]

Afforess just checked in a fix to the SVN that says it corrects this. Was our bad, we were missing the <events module="RevDCM"/> line in our Config XML for the RevDCM stuff. Sorry about coming here with a false report

 

[EmperorFool]

Hmm, how would that cause BUG to skip telling BULL it is running and delaying that until later? Did that missing config trip some other bug in BUG?