Merging BUG with other Mods

[EmperorFool]

Just to be clear, the master ACO Enabled option is going to be broken for you regardless. I just fixed that single option today.

Given that, are the other ACO options still unresponsive for you? You can change them in BUG and see that they are saved between sessions, but BULL completely ignores them and uses the values in GDA.xml. Right?

 

[phungus420]

More testing, with some useful results:

1) Changing the entry in CvModName for Better BUG AI to reflect the mod's folder name causes BULL options to respond again. (Fuyu currently has "BUG Mod" set as the name in CvModName)

2) Moving the UserSettings folder to the $Documents path ($Documents/My Games/$BtS/$ModName) worked fine for the regular BUG mod (I thought this might have been the cause of the BULL options not working in RevDCM, guess not).

 

[Fimbulvetr]

Well we all know by now that it is the simple isBug() call that makes everything fail here.
And since it's working with BUG from installer and BULL from zip, the problem, whatever it may be, must have been introduced somewhere between the 4.3/1.1 release and the current SVN (or whatever BUG/BULL revision RevDCM is/was using when it started failing).

edit: did you move your UserSettings out of Better BUG AI mod folder before?
edit2: does CvModName changing fix RevDCM too?

 

[phungus420]

RevDCM has always used it's own name in CvModName. The moving the UserSettings folder worked for BUG, so I don't see how that's relevant, but no, I lift it how it installed. Just wanted to try moving it to the $Documents path because this is the only thing I can see that is different between it and BUG. This is especially true now that I can get Better BUG AI to work if I change the name in CvModName; I can't see where Better BUG AI and RevDCM are different, except for the Revolutions stuff.

 

[Fimbulvetr]

If there is a "BUG Mod" folder in the $Documents path, Better BUG AI will ignore its own UserSettings folder (I think) and use the files it finds there - unless you change the ModName fo course. Still doesn't really explain why it doesn't respond, even if it was writing to different files than it reads from, which I doubt.

edit: if you delete/rename all "BUG Mod" folders you might have in documents or Bts\Mods\ before starting Better BUG AI, that mod should behave like it does when you change ModName - if some BugPath'ing really is the issue here.
Though it seems unlikely that this could cause isBug() to fail..

 

[EmperorFool]

It's odd because reading/writing to the INI files is totally detached from how BULL gets options from BUG. Even if BUG cannot read or write its settings, it still keeps a copy in memory. If it cannot read them, it uses the default value upon starting up; you can still change it during gameplay. If it cannot wrote them, you can still change them during gameplay.

Totally orthogonal to the above, BULL asks BUG for the option values kept in memory. It goes through CvAppInterface.getOptionXXX(), but from there it goes through the same mechanism used by all the Python features.

I'm confused how modifying CvModName could affect BULL at all. Having the wrong value in CvModName will make it so BUG cannot find the INI files, and possible create new ones if it can, but from there it should still export the getOptionXXX() functions.

Phungus, can you please post again the logs after a failed startup--one where BULL cannot find the option values from BUG? Maybe there's something else in the logs I missed, but there were definitely no errors in PythonErr.log.

 

[phungus420]

Here are the logs from Better Bug AI. The only difference between BULL options being responsive, and not being responsive are these lines in CvMainInterface:

Working

#CvModName.py

modName = "Better BUG AI"
displayName = "Better BUG AI"
modVersion = "4.3"

Not Working

#CvModName.py

modName = "BUG Mod"
displayName = "BUG Mod"
modVersion = "4.3"

I also hovered over a barb warrior so the ACO pane would occur. And I pulled up the console and typed in the commands you posted a couple pages back. Not sure if you wanted that done, but figured it wouldn't hurt.

 

[Fimbulvetr]

data dir outside the main mod folder obviously causes some disturbance in the Force which causes the call to isBug() not to reach python

 

[phungus420]

When it is working, these lines are in the Python Debug logs, but are absent when not:

17:22:39 DEBUG: BugInit - initializing...
17:22:39 DEBUG: BugPath - initializing...
17:22:39 DEBUG: BugPath - initializing application folder
17:22:39 INFO : BugPath - app dir is 'C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword'
17:22:39 DEBUG: BugPath - app folder is 'Beyond the Sword'
17:22:39 INFO : BugPath - mod name is 'Better BUG AI'
17:22:39 DEBUG: BugPath - initializing mod folder

Edit, nevermind, it's just further down (probably because in one test I generated the map, and in the other I loaded it). It is slightly different though:

17:16:39 DEBUG: BugInit - initializing...
17:16:39 DEBUG: BugPath - initializing...
17:16:39 DEBUG: BugPath - initializing application folder
17:16:39 INFO : BugPath - app dir is 'C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword'
17:16:39 DEBUG: BugPath - app folder is 'Beyond the Sword'
17:16:39 INFO : BugPath - mod name is 'BUG Mod'
17:16:39 DEBUG: BugPath - initializing mod folder

 

[Fimbulvetr]

Looks the same to me, except for mod name

 

[EmperorFool]

I wish I could say that isBug() was a complex function with various possibilities for error, however it couldn't be any simpler (even "pass" would return the value None).

def isBug():
	return True

Here's the same area of the logs when it doesn't work. Note there is one tiny difference (Edit: as Fuyu pointed out):

17:16:39 DEBUG: BugInit - initializing...
17:16:39 DEBUG: BugPath - initializing...
17:16:39 DEBUG: BugPath - initializing application folder
17:16:39 INFO : BugPath - app dir is 'C:\Program Files\Firaxis Games\Sid Meier's Civilization 4\Beyond the Sword'
17:16:39 DEBUG: BugPath - app folder is 'Beyond the Sword'
17:16:39 INFO : BugPath - mod name is '[B][COLOR="Red"]BUG Mod[/COLOR][/B]'
17:16:39 DEBUG: BugPath - initializing mod folder

You can see further down that isBug() is exported and in fact when you typed in those lines into the console it reported that it exists:

Python
 
2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)]

<function isBug at 0x1896E8F0>

How a different location for INI files could cause BTS to block DLL calls to CvAppInterface (only BUG's of course) I have no freakin' idea. Can you please try in the non-working version to enable AutoSave on Exit and then exit to menu using the ESC menu. Does it create a save? That is called by BULL via CvAppInterface as well.

I am going to take a short break to let my subconscious chew on the problem. I'll check back in a couple hours.

 

[Fimbulvetr]

phungus, you can try the 0.90p version, dl from mediafire.
For that version I changed isBug():

def isBug():
	[B]BugUtil.debug("BUG Mod is present")[/B]
	return True

and I uncommented the logmsg line from bugInit() in CvBugOptions.cpp.
Post the logs of the failing BULL options (mod name is 'BUG Mod') again then. (bull.log and PythonDgb.log at least, the rest should be the same)

 

[phungus420]

Can you please try in the non-working version to enable AutoSave on Exit and then exit to menu using the ESC menu. Does it create a save? That is called by BULL via CvAppInterface as well.

Autosave on exit is completely responsive. Creates a save when checked, does not when not.

 

[Fimbulvetr]

Is it even remotely possible that bugInit() is executed before BugDll.py is loaded?
Seems so far-fetched .. well I'm fresh out of ideas so I'll go to sleep now.

 

[EmperorFool]

BugDll is loaded by BugUtil.export() when it looks up the function. This has been working for events and gameutils since 3.0 when I added the config XML.

@phungus - Okay, so BULL can see the exported functions in CvAppInterface, so isBug() must be failing for some other reason. I'd be very curious to see what you get after putting in place the changes Fuyu just posted before you.

 

[phungus420]

Here is the logs from starting up a game with the new Better BUG AI download (tested and ACO still doesn't respond).

 

[EmperorFool]

Okay, you'll be glad to know, phungus, that I can reproduce this issue using the latest SVN and Better BUG AI. The only cause I can think of now is that I changed where the initialization gets kicked off. I'll look into it tomorrow.

 

[EmperorFool]

I cannot get it to work by changing CvModName, but I have found something that does work: an older DLL. BUG seems not to be at fault here which makes sense since I can see that it is exporting isBug() and that Python can see the function just fine. Something is different with how BULL is accessing it, but only when running as a mod it seems. That of course doesn't make any sense, but it is what it is.

 

[Fimbulvetr]

the line
logMsg("BULL - got value %ld", lResult);
is no longer commented out in that last Better BUG AI 0.90p version yet in phungus' bull.log there are still only 2 lines, the BULL - got value one is missing. Now how does that work?

 

[EmperorFool]

callFunction() is returning false, meaning that it cannot find CvAppInterface.isBug() or it raises an exception, so it skips the if() block and goes into the else block and says that BUG isn't present.