BUG and WoC

[EmperorFool]

By default, all the WoC modules are disabled, so you'd really be "turning it on if you want it", not being forced to use it.

Ah, I thought the goal was to have a vanilla WoC engine with no mods and then mod authors would convert mods so that they would install into the WoC engine, in a sense. Rather, it sounds like WoC would be like BUG: the team choose mods to convert and then the user chooses which to enable.

In an ideal situation, you'd be able to have the disparate snippets of Python code stored in the Modules folder and have them enabled/disabled by moving the folder itself.

Yes, but this is where my description above about editing prose comes into play. If you have only one mod change each file, it's easy to do. Once multiple mods touch the same file, all bets are off. You could create all combinations by hand, but wow what an ugly and error-prone job that would be.

Zebra 9's zModular Python doesn't support screens, so unfortunately that isn't an option.

I think 99% of BUG involves screen mods. What doesn't?

• Autologger
• Civ4lerts
• Reminders
• Unit Naming

Everything else is screen-based, and quite a few touch CvMainInterface.py (a.k.a. The Beast).

If you could point me in the right direction as to how I might do it (perhaps one example?) I could see if I can make it work.

I see that CyGobalContext has these three methods:

float getDefineFLOAT(string szName)
int getDefineINT(string szName)
string getDefineSTRING(string szName)

It looks like these grab the values out of GlobalDefines.xml. The easiest conversion is to modify the BugOptions subclass access methods. For example, for Reminders make these changes in BugAlertsOptions.py:

...
from CvPythonExtensions import *
gc = CyGlobalContext()
...
def isShowReminders(self):
	#return self.getBoolean('Alert_Reminders')
	return gc.getGlobalINT("ENABLE_REMINDERS") != 0

With a little thought and trial and error, you could modify BugOptions.py to use the method above as a fallback when the option isn't found in the INI file. The benefit here is that you don't have to change any of the individual option files -- all the changes go in one place (BugOptions.py).

 

[NikNaks]

Thanks for that, I'll take a look at it later today. I'm doing a complete checkout of the repo now, as my copy corrupted itself.

Ah, I thought the goal was to have a vanilla WoC engine with no mods and then mod authors would convert mods so that they would install into the WoC engine, in a sense. Rather, it sounds like WoC would be like BUG: the team choose mods to convert and then the user chooses which to enable.

True for SDK and Python, but with XML, it's up to the modders to get their code correct. Just thought I'd clarify that

Yes, but this is where my description above about editing prose comes into play. If you have only one mod change each file, it's easy to do. Once multiple mods touch the same file, all bets are off. You could create all combinations by hand, but wow what an ugly and error-prone job that would be.

In XML, you can do that happily with the new system we have.

I think 99% of BUG involves screen mods. What doesn't?

• Autologger
• Civ4lerts
• Reminders
• Unit Naming

Everything else is screen-based, and quite a few touch CvMainInterface.py (a.k.a. The Beast).

I wonder if they'd work with zModules...

 

[EmperorFool]

I looked at zModular Python, and it's very limited in its functionality. In a sense, the name is misleading. It only makes two objects modular: CvEventManager (which already is with Dr. Elmer Jiggles's CvCustomEventManager) and CvGameUtils. It essentially does for GameUtils what Dr. EJ did for EventManager.

One downside is that it has to enable every Python callback, whether or not it has any code associated with it. This will result in some unknown amount of slowdown to the game. I have no idea how much, but I suspect it's noticeable or Firaxis wouldn't have bothered with the XML configuration to disable them individually.

The four mods included in BUG that I mentioned above are all hooked into EventManager, so they would work with zModular Python with little modification. BUG doesn't use GameUtils as it's pretty much designed for altering game mechanics (cannotTrain, cannotMove, etc).

In any case, Zebra 9 is correct that the same method cannot be applied to the screens for the reasons I posted above. It's not a language issue (C++ vs. Python); it's the difference between instructions (executable code) and data.

 

[NikNaks]

I see. So really, there's very little to be gained from using the zModular Python elements to try and make BUG modular. Good to know.

 

[NikNaks]

Okay, I've made a start on that, and it seems fairly simple to do. Now for something completely different;

How hard would it be to split the INI? More specifically, into files which could be stored inside the modules folder.

 

[EmperorFool]

How hard would it be to split the INI? More specifically, into files which could be stored inside the modules folder.

Yes, this is something I wish I had done from the beginning. In theory, it shouldn't be too difficult. The problem is that the design is for a single global BugOptions object that holds all of the options. The individual module-specific classes (BugAlertsOptions, BugPleOptions, etc) merely point to this global object. When you add an option to BugAlertsOptions, it actually adds it to the global object.

I'd have to make BugOptions be able to point to multiple INI files (Config objects). This shouldn't be too difficult I don't think. The tricky part is handling writing out changes. I guess I could just write each INI file regardless of which ones actually need writing.

I'll do some thinking on this over the next week, as I'll be out of town for a week.

 

[NikNaks]

Okay, I've made some headway and will hopefully post some results tomorrow morning.