Fimbulvetr
Emperor
Oh right, that was inside an if block too, overlooked that. Then the value would still be 0 anyway I guess..
Merging BUG with other Mods
- Thread starter EmperorFool
- Start date
EmperorFool
Deity
I'm doing a full recompile in a vain attempt to fix this. I seriously doubt both you and I and RevDCM got hit by a recompile bug at the same moment, but I'm hoping nonetheless. Can you please confirm that the old DLL posted on civ4bull's SVN works (ACO) for you with BUG or Better BUG AI or whatever?
The only related difference I can see is that I increased the API version from 2 to 3, but that should only affect BUG and not BULL. You can add a dll attribute to elements in the config XMLs that will make them trigger only if the BULL API version is at least that in the attribute. But that should not be able to affect isBug() since that is being exported.
The only related difference I can see is that I increased the API version from 2 to 3, but that should only affect BUG and not BULL. You can add a dll attribute to elements in the config XMLs that will make them trigger only if the BULL API version is at least that in the attribute. But that should not be able to affect isBug() since that is being exported.
EmperorFool
Deity
So recompiling had no effect, as expected. I'm checking out r100 and diffing it against the latest code now. Somewhere in there is a change that causes this behavior.
Fimbulvetr
Emperor
That 04-11 Better BUG AI is a full recompile btw 
API cannot affect callfunction() if all that funciton does is return true.
I'm assuming old BULL will work if it even does for phungus.
You said you could reproduce the behaviour - but if changing modname doesn't fix it for you then I'm guessing it is not limited to when data dir is outside the mod folder?
API cannot affect callfunction() if all that funciton does is return true.
I'm assuming old BULL will work if it even does for phungus.
You said you could reproduce the behaviour - but if changing modname doesn't fix it for you then I'm guessing it is not limited to when data dir is outside the mod folder?
EmperorFool
Deity
Have you been able to reproduce the broken state? If so, does changing CvModName.modName have any effect for you? I can only fix it by swapping to the r100 DLL. I have removed the UserSettings folder, renamed the My Games/BTS/BUG Mod folder to match the mod folder, changed CvModName, but I cannot get it to work using the latest DLL.
I have a new theory . . . please be correct!
I have a new theory . . . please be correct!
EmperorFool
Deity
Sigh. 
Fimbulvetr
Emperor
All I know it works here, and I'd expect it to fail if I install the BUG Mod to documents.
Logs are here, and the "BULL - got value 1" confirms that these are logs from my 2010-04-11 version.
The only interesting part for me was where "DEBUG: BUG Mod is present" pops up in PythonDbg.log (the debug msg I added) - it's almost at the very end.
Logs are here, and the "BULL - got value 1" confirms that these are logs from my 2010-04-11 version.
The only interesting part for me was where "DEBUG: BUG Mod is present" pops up in PythonDbg.log (the debug msg I added) - it's almost at the very end.
Fimbulvetr
Emperor
I can't even recreate the broken state here if I copy UserSettings to a BUG Mod folder in documents. Naturally modname changing won't have much effect there.
EmperorFool
Deity
BULL only checks for BUG when it needs its first option value, so it should appear very near the end of the log after BUG has initialized.
So I added CvAppInterface back into BUG along with isBug() in it manually, and it works using the new DLL. So something in the new DLL is making it not find isBug() if it is added via export and running as a mod.
I wasn't quite sure from your message. You cannot reproduce this issue at all?
So I added CvAppInterface back into BUG along with isBug() in it manually, and it works using the new DLL. So something in the new DLL is making it not find isBug() if it is added via export and running as a mod.
- Old DLL (r100) -> works
- CustomAssets -> works
- CvAppInterface with isBug() -> works
I wasn't quite sure from your message. You cannot reproduce this issue at all?
Fimbulvetr
Emperor
So far, no.
EmperorFool
Deity
Okay, I found the problem but not the cause. BULL is initializing itself long before BUG has a chance to initialize:
I'm looking now for why BULL is being so greedy.
Code:
13:38:57 DEBUG: BugInit - game not fully initialized
...
PY:Player 0's alive status set to: 1
13:39:10 DEBUG: About to call isBug
PY:Player 1's alive status set to: 1
...I'm looking now for why BULL is being so greedy.
EmperorFool
Deity
Did you remove CvAppInterface and the three other EntryPoints modules that BUG removed from BULLAI?
How are you testing? I am creating a new game. I wouldn't be surprised if loading a test game would not trigger this since the initialization path will be different and that event won't be triggered.
Fimbulvetr
Emperor
Heh, it is exactly as you say - I was loading a saved game but remembered phungus talking about starting new games - and finally was able to recreate it.
(yes I'm pretty sure I removed the old python files long long ago)
edit: Changing modname has no effect.
(yes I'm pretty sure I removed the old python files long long ago)
edit: Changing modname has no effect.
phungus420
Deity
- Joined
- Mar 1, 2003
- Messages
- 6,296
I'm not surprised changing modname has no effect, since I can't get RevDCM to work at all. That's interesting about loading save games causing it to work. I suppose I should check and insure that the cause of it working wasn't changing modname, but loading instead of starting a new game. I can't see how loading a new game or starting a new game would look different to BULL though. And sorry I don't have a more accurate picture on when this happened, all I know is that BULL values used to work fine in RevDCM, and now they don't; and we are constantly pulling from your SVN, so it's impossible to say when exactly this occured, especially since we only became aware of it from user reports.
EmperorFool
Deity
Cue the drum roll . . .
And the culprit is . . .
I haven't dug into it yet, but when the first player (0) is set alive this triggers a check to see if the player should be warned about a unit with that little red circle around it. It should be easy to fix.
The reason loading a saved game works is that BTS performs a slightly different order of initialization. BUG initializes in OnLoad or GameStart, and different things happen in BTS depending on which is called. In this case, the players are not set alive with CvPlayer::setAlive() when loading a game--they are loaded from the saved game file in that state.
And the culprit is . . .
Ignore Harmless Barbarians
I haven't dug into it yet, but when the first player (0) is set alive this triggers a check to see if the player should be warned about a unit with that little red circle around it. It should be easy to fix.
The reason loading a saved game works is that BTS performs a slightly different order of initialization. BUG initializes in OnLoad or GameStart, and different things happen in BTS depending on which is called. In this case, the players are not set alive with CvPlayer::setAlive() when loading a game--they are loaded from the saved game file in that state.
phungus420
Deity
- Joined
- Mar 1, 2003
- Messages
- 6,296
Yay, good to know it's been found. Let me know when you have a fix up so I can see if I can get the options working in RevDCM.
EmperorFool
Deity
If users would simply always load from a saved game instead of starting new games (the nerve!) there wouldn't even be a problem.
I'm testing the fix now . . . works!
The long term solution is probably to have BUG tell BULL that it is available and ready with CvGameCore::setBugReady() and for BULL to use default/XML values until then. Otherwise this bug may crop up unexpectedly in the future and be similarly troublesome to diagnose. At least now we know the cause: accessing options before BUG has been initialized.
Edit: I have committed the fix so that Ignore Harmless Barbarians won't check the option unless it's needed. That works but is brittle. If some map script creates a human city and places a barbarian next to its border, it will break.
I'm testing the fix now . . . works!
The long term solution is probably to have BUG tell BULL that it is available and ready with CvGameCore::setBugReady() and for BULL to use default/XML values until then. Otherwise this bug may crop up unexpectedly in the future and be similarly troublesome to diagnose. At least now we know the cause: accessing options before BUG has been initialized.
Edit: I have committed the fix so that Ignore Harmless Barbarians won't check the option unless it's needed. That works but is brittle. If some map script creates a human city and places a barbarian next to its border, it will break.
EmperorFool
Deity
I edited my post and committed the fix.
Fimbulvetr
Emperor
"break" as in crash?
EmperorFool
Deity
No, break just like we've been seeing: ignore BUG's options and fall back on the XML values.
Similar threads
