BUG Architecture - thoughts for the future

[glider1]

The architecture of BUG is a very wonderful thing for modders. Modding becomes so elegant thanks to BUG's event system, call back handling mechanisms and it's XML subsystem. I have experienced both WoC and BUG within the design of RevolutionDCM, and it appears to me that we are so close to a perfect blend of the two it just has to happen eventually, it is inevitable.

The BUG architecture allows this scheme as it stands now:

/assets/config/init.xml points to the mod.xml configuration xml
/assets/config/mod.xml set's up the mod's call backs and events
/assets/python/mod/mod.py houses the mod's python

Now to make it so that all that is in /assets/python/mod/mod.py can be brought out of that folder and put into:
/assets/modules/mod/woc.xml, mod.py etc
so that finally a mod's python can be truly plug and play, it would appear that there is just a few steps left in the final architecture that melds WoC and BUG. Those steps are:

1) The WOC code in the DLL writes BUG xml configuration data in the woc module to the BUG xml system, before BUG initializes.
2) BUG is told that it can look for python in the modules folder
3) BUG initializes once the WOC DLL is complete and instantiates call backs and events as per normal, pointing to python that is in the modules folder.
4) BUG is programmed so that in the case that there is config XML pointing to non-existent python code, the config xml is ignored and execution continues.

Thank you BUG team and EmperorFool for the BUG system. Whatever happens in the future it is already great now. Great for modders of Civ4 and great as a conceptual model of a possible Civ5.

Thoughts are welcome in this thread.
Cheers.

 

[EmperorFool]

1) The WOC code in the DLL writes BUG xml configuration data in the woc module to the BUG xml system, before BUG initializes.

There's no reason BUG couldn't look in an Assets/Modules/... folder for its XML configuration files. I chose Assets/Config because it seemed like a good place. Unfortunately I didn't consider the modmod community (I had just learned of the Civ mod community) in my first design of BUG.

2) BUG is told that it can look for python in the modules folder

Someone (Zebra 9? odalrick?) recently posted that you can load Python from any folder. I haven't tested it, and there may be some sticky issues with it, but it's something to check out.

4) BUG is programmed so that in the case that there is config XML pointing to non-existent python code, the config xml is ignored and execution continues.

This is certainly possible. The downside to doing this is that it can often make it difficult for detecting problems during development. I've had many a hair-pulling moment trying to figure out why my code wasn't doing what i wanted only to find the module was in the wrong folder. I designed BUG to fail-fast: give you a big nasty error message if you told it to look for something that didn't exist.

I have been thinking about changing the init.xml system to instead load the config files automatically without a master init.xml that loads all the others. This would be a further step allowing for modularization of those config files.

With WoC is there a marker file that you must place in a module's folder to tell WoC about the module, or is that only needed to tell it to ignore a module temporarily?

 

[Afforess]

With WoC is there a marker file that you must place in a module's folder to tell WoC about the module, or is that only needed to tell it to ignore a module temporarily?

There are MLF Control Files, which you must put the name of the module in, or it ignores the files. You used to be able to enable and disable modules from that file, without deleting them, but that feature broke with the 3.19 patch...

 

[EmperorFool]

Do I understand correctly that you need to create a file with a specific fixed name inside your Modules/<Mod> folder that contains <Mod>? Or does the folder just need to exist?

 

[Afforess]

Do I understand correctly that you need to create a file with a specific fixed name inside your Modules/<Mod> folder that contains <Mod>? Or does the folder just need to exist?

I'm not sure what you mean. The only real change WoC made was with Modules. You need to have a MLFControlFile.xml in your Modules folder, along with entries for every module folder you want loaded . Other than that, nothing else (that I know of) is needed.

MLF stands for Module Loading Controls File.
I have one posted on this thread, but you can see what they look like from it.

 

[mamba]

Do I understand correctly that you need to create a file with a specific fixed name inside your Modules/<Mod> folder that contains <Mod>? Or does the folder just need to exist?

I think you got this somewhat wrong.

In Assets/Modules you can have a file called MLF_CIV4ModularLoadingControls.xml (the MLF file). In it you specify which subdirs or Assets/Modules should be loaded and in which order.

e.g.

				<Module>
					<Directory>OriginalBtS</Directory>
					<bLoad>0</bLoad>
				</Module>
				<Module>
					<Directory>GameConcepts</Directory>
					<bLoad>1</bLoad>
				</Module>
				<Module>
					<Directory>Resources</Directory>
					<bLoad>1</bLoad>
				</Module>
				<Module>
					<Directory>Civilizations</Directory>
					<bLoad>1</bLoad>
				</Module>

Depending on its content, the subdirs are being skipped or loaded. In each subdir which is being loaded there can be another MLF file specifying which subdirs of its dir are to be loaded (and in which order) in turn.

In WoC, not having MLF files is equivalent to loading everything. In ReDCM 2.51 it is equivalent to not loading anything (so for RevDCM they are mandatory if you want anything to be loaded).

MLF files control the loading of xml, I do not think they influence the loading of Python in any way (but that can easily be verified if you can load Python from any dir).

 

[EmperorFool]

Oh, now I get it. I thought before that each folder within the Modules folder (each module) needed its own MLF. So WoC has something similar to BUG's init.xml that must be modified to add a module.

The need for that file is unfortunate but certainly understandable, as evidenced by that thread you linked, Afforess. Without that file, a more difficult process would be needed to control load order.

What I planned to do with BUG is have it load all the config XML files automatically but allow any individual file to specify the other files that must load before it.

I'll have to do some testing in BTS to make sure that I can load Python files from directories outside the Python folder easily, including having multiple modules in an outside directory reference each other. What does a typical WoC module folder look like? Are all the XML files in a single folder, units, civs, techs, buildings, leaders, etc?

 

[glider1]

What does a typical WoC module folder look like? Are all the XML files in a single folder, units, civs, techs, buildings, leaders, etc?

Attached is a "smallish" example of the woc structure. It can be a lot less or a lot more than this. As WoC stands now, as Mamba says, MLF files should not be compulsory but currently in RevDCM 2.51 they are apparently.

In a day or two, RevDCM 2.6 will be out which could be used as a standardised testbed for BUG 4.0 and WoC-Lite code cooperation. WoC full apparently does have python modular loading code built into the DLL in it, but the WoC full project is basically dead in the water with no support except for the kind work of Faichele, it's single contributer of late. RevDCM is probably the most actively supported woc-lite platform on CivFanatics. Woc-lite, Johny Smith's baby is very excellent, but the project has been quiet lately and is essentially the same as RevDCM anyway.

The beauty of a BUG-BULL-WoCLite architecture is that BUG and BULL are already well developed and stable, and the WOC lite DLL code has some reasonable chance of good support into the future.

Cheers.

 

[mamba]

What does a typical WoC module folder look like? Are all the XML files in a single folder, units, civs, techs, buildings, leaders, etc?

I am not sure there is actually a typical one

My preferred way of doing it is grouping changes which belong together logically in the same dir (or subdirs if there are multiple changes which are part of a bigger change).

As an example, here is the NextWar module from my mod (note, it itself is in the dir Assets/Modules/NextWar).

This one is about as complex as my use of WoC has become (not just in dir structure but also in the actual xml definitions, see for example the promotions)

 

[Sephi]

Oh, now I get it. I thought before that each folder within the Modules folder (each module) needed its own MLF. So WoC has something similar to BUG's init.xml that must be modified to add a module.

In Xienwolfs Version of the WoC TrueModular system for Fall Further there is no need for a MLF (you can create one but don't have to). I can just create a folder, add an xml file and schema into it and the module will automatically be loaded. In Xienwolfs Version there is also a bForceOverwrite tag which is quite useful for modders.