Merging BUG with other Mods

[EmperorFool]

Weird. When I type things into the console, their output appears in PythonDbg.log, including the Python version information displayed on the screen when you enter the console. Can you be more specific about the hex output you saw? Was it all hex output or did you see something like this?

<function blahblah@HEX>

What I find most interesting about your logs is what's in bull.log:

[25251.453] debug - checking for BUG
[25251.453] BULL - got value 1
[25251.453] info  - BUG is present

So why is this suddenly working? Can you try the ACO options?

Edit: When you wrote originally that the ACO options were "locked," what exactly did you mean? Were they grayed out so you couldn't change them, or could you change them but they had no effect on the hover text?

 

[phungus420]

Weird. When I type things into the console, their output appears in PythonDbg.log, including the Python version information displayed on the screen when you enter the console. Can you be more specific about the hex output you saw? Was it all hex output or did you see something like this?

<function blahblah@HEX>

function isBUG 0xblablabla

What I find most interesting about your logs is what's in bull.log:

[25251.453] debug - checking for BUG
[25251.453] BULL - got value 1
[25251.453] info  - BUG is present

So why is this suddenly working? Can you try the ACO options?

Edit: When you wrote originally that the ACO options were "locked," what exactly did you mean? Were they grayed out so you couldn't change them, or could you change them but they had no effect on the hover text?

No BULL options are working. The menu appears normal, I can uncheck boxes, and change values, they simply have no effect. In fact what's in the config xml file has no effect, just the GDA values are used.



For the eTeam issue returning -1 and causing a failed assert, it appears the problem is in Civ4lerts at line 950 specifically:

if eActiveTeam != eNewEnemy and not activeTeam.isHasMet(eNewEnemy):

is being naughty and passing in -1 for eNewEnemy. I haven't tested it yet, but this looks to be the cause.
Edit: Yes, ensuring the eNewEnemy is >=0 fixes this assert, thanks for letting me know how to get python to throw an exception, that's an invaluable debbugging tool.

 

[EmperorFool]

No BULL options are working. The menu appears normal, I can uncheck boxes, and change values, they simply have no effect. In fact what's in the config xml file has no effect, just the GDA values are used.

So isBug() is working now, and yet BULL doesn't use getBugOptionBOOL() to get the option's value? Please launch again and cause BULL to display the ACO hover text, then post bull.log. This will show BULL trying to get the option value form somewhere.

What does GDA stand for?

For the eTeam issue returning -1 and causing a failed assert, it appears the problem is in Civ4lerts at line 950.

I've completely rewritten all that code (not in SVN yet), so hopefully I was more careful about checking for that this time.

 

[phungus420]

GDA stands for GlobalDefinesAlt

I started a game, went in world builder, added a panther, then typed in the console code above, then realized the panther was mine, and went back in world builder and put in a barb panther. Then I tried changing various ACO settings and getting the ACO hover to pop up. Here is the Bull.log file:

 

[EmperorFool]

Okay, now you're back to

[28483.734] debug - checking for BUG
[28483.734] info  - call to isBug() failed; BUG not present

What is the difference between this last time and the time before when isBug() worked? Are you doing these tests in different mods?

 

[phungus420]

Same mod, these are all from Better BUG AI (I'm not using BUG with a BULL dll itself, because I'd need to compile a new gamecore with the message logging code you told me to enable on, and that takes 2 hours on my old computer, so Better BUG AI is the closest thing I have to the original that is ready to go). The only difference I can think of is that before I typed in those console commands, then uploaded the logs, this time I typed in the console commands, entered world builder, messed with the BUG menu (trying to change values in the Odds tab), and then kept bringing up the ACO pain by hovering over the panther unit created in WB with my warrior selected. I want to get this issue resolved, so I'm trying to stay as consistent and concise as possible.

 

[EmperorFool]

isBug() is checked the first time BULL asks for an option value.

I'm a little confused about the DLL. In one bull.log I see the extra option-checking log messages telling me this is a modified DLL, and in the other there are no extra messages. But you say in both tests you are using the same Better BUG AI mod which implies the same DLL. What am I missing?

BTW, uncommenting those extra log lines in CvBugOptions.cpp only requires recompiling that one file and linking the DLL--not a full rebuild.

 

[phungus420]

isBug() is checked the first time BULL asks for an option value.

I'm a little confused about the DLL. In one bull.log I see the extra option-checking log messages telling me this is a modified DLL, and in the other there are no extra messages. But you say in both tests you are using the same Better BUG AI mod which implies the same DLL. What am I missing?

I don't know

I was checking the cause of that assert in RevDCM by eTeam being out of bounds, perhaps I uploaded the wrong log once. I really doubt it though; and the last log posted is definetely from Better BUG AI.

BTW, uncommenting those extra log lines in CvBugOptions.cpp only requires recompiling that one file and linking the DLL--not a full rebuild.

I don't have BULL set up as it's own project, so I'd have to set it up new. I can do so, but as I say it'll take 2 hours to finish compiling. (Plus I'm building a fresh dll now for RevDCM that I'd rather not stop, but if needed I will). I can't see how there is any relevant difference between Better BUG AI and a pure BULL gamecore though. The same bug is afflicting both mods.

 

[EmperorFool]

Don't bother building BULL yourself. If need be I can send you an up-to-date DLL with that stuff uncommented. I'll download and install Better BUG AI soon, but it's very strange that you and I created the same setup (BUG 4.3 + BULL 1.1) but saw different results.

And then one time above you ran LoR and BULL saw isBug(), but now it's not anymore? Can you please post bull.log after the next time you try LoR (and hover over something that BULL has an option for)?

 

[phungus420]

Testing this out, what most likely happened is that I accidently clicked the BUG mod shortcut, instead of BULLAI. The shortcuts are next to each other, and I can see that happening (I however can't really see how I could have screwed up and sent logs from RevDCM).

BUG itself is actually responding correctly for ACO, so it makes sense that it's showing that it's finding BULL. However the option Train Military Units forever does not seem to be working, so I'm clueless as to what could be causing that. But yes, ACO does work in Pure BUG. Here are the logs for Pure BUG (with a BULL dll), and Better BUG AI.

 

[Fimbulvetr]

I doubt installing my mod will help you here, it's all working for me like it is for you and I should have to same setup as phungus (XP, clean customassets). phungus has the same trouble, no matter if he tries BULL, Better BUG AI or RevDCM, and neither me nor you can reproduce the failing isBug() call he keeps getting.
edit: ok so pure BUG + BULL works now?
What BUG and BULL revision are those?

 

[EmperorFool]

BUG itself is actually responding correctly for ACO, so it makes sense that it's showing that it's finding BULL . . . . But yes, ACO does work in Pure BUG.

But it wasn't working for you just yesterday? And nothing changed?

To summarize the latest situation:

• BUG + BULL works for everyone [ignore training military units for now]
• Better BUG AI works for Fuyu but doesn't work for phungus
• RevDCM doesn't work for phungus

Do I have that right?

 

[phungus420]

That is correct yes.

Fuyu could you download and install RevDCM and see if the ACO options are responsive for you?

 

[EmperorFool]

Regarding Train Military Units Forever, you say this doesn't work using plain BUG + BULL? Are you sure you have the correct option unchecked? This works fine for me here. I can understand it not working if all BULL options are failing, but alone it makes no sense.

 

[EmperorFool]

That is correct yes.

Can you think of what would have fixed it between yesterday and today? I think that's the key.

 

[Fimbulvetr]

ACO is fully responsive now (as far as I can tell), even on/off with newest BUG SVN - for Better BUG AI at least.
Updated to latest BBAI revision too, BUG is detected as always.

 

[phungus420]

Can you think of what would have fixed it between yesterday and today? I think that's the key.

Probably just simply reloading. It's possible that when I initially checked the ini files hadn't been generated yet, as I just started up the game, tested, ACO didn't respond and I declared it failed. Had I reloaded it may have worked. Nothing else has changed. And I still think the strangest thing here is that the BUG options themselves work, while BULL does not. I think the difference in how BULL finds the ini files and BUG does is the key.

Regarding Train Military Units Forever, you say this doesn't work using plain BUG + BULL? Are you sure you have the correct option unchecked? This works fine for me here. I can understand it not working if all BULL options are failing, but alone it makes no sense.

Just checked it again, and it's behaving strangely. The option was checked, yet I was asked what I wanted to build after a warrior was built. So I clicked it off, and clicked it back on again. It was working, and now it will not turn off...
But as you say, probably best to ignore this for now, unless you think it's behavior is important.

 

[EmperorFool]

ACO is fully responsive now (as far as I can tell), even on/off with newest BUG SVN.

Yes, the master ACO on/off checkbox was not handled correctly because it didn't have a key attribute for the INI file. BUG should have used its id but instead turned it into an unsaved option. This combined with another bug with how unsaved options handled boolean values. Both bugs are fixed.

Sadly, none of that is related to BULL not seeing isBug() for phungus.

 

[EmperorFool]

I think the difference in how BULL finds the ini files and BUG does is the key.

That's just it, BULL doesn't know anything about INI files. When BULL needs an option value it asks BUG via CvAppInterface.getOptionBOOL(). If BUG is not running or the option doesn't exist, BULL will fall back on GDA.xml, and if the option isn't there it uses the compile-time default.

Because BULL cannot see isBug() it thinks BUG is not running. Yet BUG clearly states in the logs that it is exporting that function without error. We need to figure out why that happens in RevDCM for you. As I said, I'll download RevDCM soon and give that a shot.

Just checked it again, and it's behaving strangely. The option was checked, yet I was asked what I wanted to build after a warrior was built.

It may be a little confusing but the option only takes effect when you select a (military) unit in the production popup. If you click a unit's build button on the main/city screen, the option is not checked. This is because you can use ALT + Click on the build button but not in the production popup.

Thus if you have a unit that is being built continuously (* next to it in queue) and uncheck the option, nothing changes for that unit. Is this what's tripping you up?

 

[phungus420]

Yeah, that's it, I guess I just did not fully realize how that option worked. I'm still confused as to how ACO is responding for Fuyu in Better BUG AI, but not myself. I'm pretty much expecting ACO to work for you in RevDCM. This seems to be a user specific problem, but it doesn't appear to be a rare one. User reports of it are how I became aware of it in the first place.