BUG mod

[DarkLunaPhantom]

Are BUG mod components essential for functioning of FFP? The game doesn't work (it throws exceptions) when I disable it.

 

[God-Emperor]

Almost certainly it will not work if BUG is not initialized, unless some reprogramming is done.

The way the event handlers are loaded requires BUG to be loaded first. The CvFinalFrontierEvents.py file doesn't have anything in it anymore, for example. The event handlers are in FinalFrontierEvents.py and loaded by BUG. I expect this could be changed back, but it would take some effort and a knowledge of Python programming. It also loads the callback functions in FinalFrontierGameUtils.py via BUG and without BUG it would not use those, just the ones in the regular CvGameUtils.py which is missing the programming that makes a lot of FF work.

I expect there are also other things in the Python that do not check to see if BUG has not been initialized and try to do things that won't work if it isn't. When I added BUG in, I did it in the easiest way possible which was to just to add it in with no checks to see if it was actually being initialized.

I'm not sure what all it requires in addition to the event handlers being loaded. I expect there are some graphics functions (UI elements such as the scoreboard and the bug options button itself) which could be a problem. It needs some of the functions from BUG for other things too such as FinalFrontierEvents.py uses the BugData functions to store information across saves, although I don't know if disabling BUG would have any effect on that as long as you left the file it loads to do that where it is (assuming you fixed it to load that that file in the first place, as it is currently loaded by BUG).

In general, I see no reason to disable BUG enitrely. You should be able to turn off any features of it that you don't want to use via the BUG Options screen. There might be some things that are not controllable this way but the only one I can think of is maybe the BUG Options button itself (and it might be possible to turn that off, I don't remember). So if there is some feature you don't want to use, you should be able to just turn it off. TC01 has said that he turns most of it off. It should remember your settings.

 

[DarkLunaPhantom]

What I am trying to do is host a PitBoss FFP game. The problem with BUG is that it considers PitBoss as just another player and that causes errors. The usual solution which works for most other mods where BUG isn't used for anything other than data display is to disable BUG initialization in PitBoss by adding:

if CyGame().isPitbossHost():
	return

at the beginning of init function in BugInit.py. That way BUG doesn't cause errors in PitBoss and players are free to use BUG if they want.


I'll try to deal with these errors one by one now that I know that disabling BUG isn't as easy as I hoped.

 

[TC01]

Interesting... the Pitboss thing sounds like something that BUG should have fixed. Maybe they couldn't... any idea what part of BUG is responsible for this issue?

Short of trying to rewrite some of the BUG internals the easiest fix seems like implementing some sort of workaround where we load the BUG event manager and game utils but don't do anything else. We'd need to figure out what loads this file and how it's related to BugInit.

That's where I'd start. I may have a go at this later this evening or tomorrow.

Assuming we can fix this I'll release a patch.

 

[DarkLunaPhantom]

any idea what part of BUG is responsible for this issue?

Python errors are caused whenever BUG treats PitBoss as regular player and tries to do/access things which don't exist in PitBoss. And there's probably a lot of such things, anything related to the graphic interface or "active player" (because that's PitBoss in its own instance) is potentially problematic.

EDIT: I've fixed a few of these python exceptions by now and it turns out only one was BUG related (something with scoreboard) and all others are from FFP code (although it's usually a part which uses BugEventManager or (More)Civ4lerts). But the cause is same, it is always getActivePlayer or some similar function returning PitBoss as "active player" and then some other function tries to get a list of cities or something else which doesn't exist for PitBoss.

 

[TC01]

Ah, I see.

Well, if you manage to get this all to work in such a way that BUG is still useful for all other players but that the problematic code doesn't run for the pitboss host, feel free to send us your changes (either attach them here, or submit a pull request on the git repo, or...) and I'll include them in a patch, like I said.

 

[DarkLunaPhantom]

I got a bit confused before, most of the python exceptions were actually caused by BUG mod and its alerts. I think I have fixed them all now and I've let AIs play alone for few hundred turns a few times and there were no exceptions. Also, it seems that BUG mod still works normally for human players.

All of my changes are preceded by a comment containing:

#DLP

I've added one more change to make PitBoss games properly trackable by PitBoss tracker civstats.com. Civstats can only recognize dates in format "X BC" or "X AD" (and it reads the date from the PitBoss window), so I've changed the date displayed in PitBoss window to "YYMM AD" (where YY are the last two numbers in year). This change applies only to the date display in PitBoss window and doesn't change anything for any of the human players. I don't know if you want to include that in the patch, but I've included it in the attached files (it is in /PitBoss/PbAdmin.py, FFP ordinarily uses stock BTS version of that file.)

I've attached the files I've changed.

 

[TC01]

Thanks for the code! I've merged it in with our git repository; I'll likely release a 1.84 over the next few days with a few other fixes too.