WoC Lite(made for merging)

- you might create conditions which are impossible to solve, e.g. <Autolog after="LuckyCharms"> and <LuckyCharms before="Autolog">

You could make it "pass" and read the config once first to check for those kinds of loops. If it finds them, disregard all related files and spit something into the error logs, then "pass" again and load stuff.
 
The problem with BULL seems to be BTS's slightly brain-dead usage of HTML for displaying text. Here's how you would normally put an image into HTML:

Code:
<img src="path/to/file.dds" size="24"></img>

Old HTML (pre 4.0) allowed you to drop the ""s around values that didn't have spaces. BTS goes one further: it drops "src=" and disallows quotes entirely:

Code:
<img=path/to/file/without/spaces/or/yer/screwed.dds size=24></img>

I just tried putting quotes in there and it ends up a) ignoring the size and b) using the Atlas instead. :crazyeye: So there's nothing I can do in BULL, sadly. I remember now wrestling with this back then, but I never encountered the spaces issues since I was working with unmodded BTS XML.

I'm glad you figured it out and helped out the community with the issue. In the future a ping back to me would be helpful so that I can help make people aware of it.

Okay, back to the modmodding structure. My main goal is to allow the user to install a modmod by copying a single self-contained folder into the Modules folder (or some subfolder under it as they please). Having to copy some files into Art and some into Modules and others into Python is a nightmare, necessitating installers and detracting from plug-and-play.

I'm not sure this will be possible, but I can do some preliminary testing to verify it. I just want to be sure that I've got a good target that will solve the actual problems at hand. If nothing else, I'm sure I can remove the need for a single master init.xml, even if none of this other stuff comes to fruition in BUG.
 
Okay, back to the modmodding structure. My main goal is to allow the user to install a modmod by copying a single self-contained folder into the Modules folder (or some subfolder under it as they please). Having to copy some files into Art and some into Modules and others into Python is a nightmare, necessitating installers and detracting from plug-and-play.

Art with WoC can be in the modules, so generally, modmod can just be dropped in the Modules folder...

Except when the order is specific, you need to clear the contents of a array or text value, or the file is one of those silly enum files. Then you need to edit the base files.

<gripe>
My installer let's users check off components that they want, and I silently install required files, like the modified dll and global defines, and some picky XML files... and a bunch of python. (Who knew adding a new concepts page to the sevopedia would force me to learn python and edit 10+ files in the python alone!!) I pretty much gave up on being completely modular-plug-in-play a few weeks ago though, it was a bit much, and it's pretty much impossible to make a python file edit the contents of another python file, without changing the first python file a bit. At this point, my installer backs up the XML, Config, and Python folders and when you uninstall it just wipes those and replaces them with backups. I still try to be as modular as possible, but limitations prevent me...
</gripe>
 
- you need to create a logic to resolve those before and after dependencies (solvable but potentially complex)

Pretty easy by doing what I said above. Since these dependencies will have to be on the root document XML element, I can detect them immediately and stop parsing that file, putting it into queue for later.

- you might create conditions which are impossible to solve, e.g. <Autolog after="LuckyCharms"> and <LuckyCharms after="Autolog">

Tricky, but not that hard. Plenty of dependency graph research and algorithms abound on the net. When I detect a cycle (as this is) or other such impossibility, I'll skip the offending mods and report them in the logs. Or maybe I'll just spike the voltage to the CPU. :mischief:
 
Okay, back to the modmodding structure. My main goal is to allow the user to install a modmod by copying a single self-contained folder into the Modules folder (or some subfolder under it as they please). Having to copy some files into Art and some into Modules and others into Python is a nightmare, necessitating installers and detracting from plug-and-play.

I'm not sure this will be possible, but I can do some preliminary testing to verify it. I just want to be sure that I've got a good target that will solve the actual problems at hand. If nothing else, I'm sure I can remove the need for a single master init.xml, even if none of this other stuff comes to fruition in BUG.

I certainly would prefer having everything which makes up a modmod be part of one single dir underneath Modules, I just did not think it would be possible to do so today.

If you can get that to work, I certainly would prefer that way. In that case the Assets/Modules/MyModMod dir becomes the Assets dir for the modmod, including all the Art and Python etc. (with the noted exception of the Fonts dir). I like that, it is simple and easy (from a modders and users perspective, probably not so much from the perspective of someone who wants to make this happen).
 
Tricky, but not that hard. Plenty of dependency graph research and algorithms abound on the net. When I detect a cycle (as this is) or other such impossibility, I'll skip the offending mods and report them in the logs. Or maybe I'll just spike the voltage to the CPU. :mischief:


That's exactly what I suggested, except I would turn off the computers fans. Silent but deadly. :lol:
 
It's pretty much impossible to make a python file edit the contents of another python file, without changing the first python file a bit. At this point, my installer backs up the XML, Config, and Python folders and when you uninstall it just wipes those and replaces them with backups. I still try to be as modular as possible, but limitations prevent me...

Yes, some Python stuff--especially screens--just can't be modular. Events and Game Utils (and Random Events maybe) are really the only truly modularizable Python items simply due to their nature of self-containment. Many of BUG's core features are totally self-contained in their own modules. The only reason they're packed into one Contrib folder is because of the way BTS loads Python modules. I think I can get around that, so we'll see . . . .

One problem with doing the install as you've done (but there's no other good option) is if another modder does the same thing as you. If I install your mod, install his, and finally remove yours, kapow! I am left with some original BTS files you backed up overwriting the files he had installed (if they had files in common).

This is why I originally didn't think too much about modular stuff for BUG. I figured people would take BUG and build their mod upon it, adding whatever they wanted. Users would install a single packaged mod, never bits and pieces from other people. I would love users to have that ability, but it's trickier with Python than XML and Art.
 
One problem with doing the install as you've done (but there's no other good option) is if another modder does the same thing as you. If I install your mod, install his, and finally remove yours, kapow! I am left with some original BTS files you backed up overwriting the files he had installed (if they had files in common).

Which is why I've made certain to stamp out any budding RoM modmoders...:mischief:

Actually, I've made it more of a community installer, offering to include other peoples work in it too. (You kinda have to when someone makes a sweet SDK mod. Thank heaven for game options.)

ATM, I have 29 components in the install screen, about 60% made by me. Maintaining it isn't fun, but I have a good install creator and backed up everything offsite in case the worst happens.

I'm not sure there is any better option. The upshot is that other people can use the 30 or so new XML tags I've made.
 
no custom scenario option

no planet generator_68

few other map type generators missing. Is there a fix?

edit - i hate wen i post and solve my own problem a few minutes later lol.
 
no custom scenario option

no planet generator_68

few other map type generators missing. Is there a fix?

edit - i hate wen i post and solve my own problem a few minutes later lol.

The fix is to open the WoC Lite.ini file and make this change:

Code:
NoCustomScenario = 0

Orion Veteran :cool:
 
Is there a version of this merged with BUG ? Would anyone share it with me and a few of my friends ? We all play together and we trying to make our own mod.
 
Is there a version of this merged with BUG ? Would anyone share it with me and a few of my friends ? We all play together and we trying to make our own mod.

Use RevDCM, it's a stable base with WoC and BUG, and you can turn off all the features you dislike fairly easily.
 
RevDCM wol't work for him, MP is a stated requirement.
 
What exactly doesn't work with MP in RevDCM? It seems we should just fix that. :)

Actually, MP RevDCM is in progress ATM, and has been for several weeks now. MP is as about as broken as it could possibly be in RevDCM 2.61, the latest release.
 
We have fun making our own, so i don't think we use revdcm. The mod we are making is a vast collection of modcomps in which we think is the best to enhance gameplay but not change it, We have used something from you Afforess.. maybe two things. We discuss Bug and Woc Lite is the bare standard to start with, they are just so good. Even tho we have nearly merged everything we want, We struggle on the vast amount of python bug brings to the table because we only start doing sdk/python/xml for the love of the game. So if anyone has already done the merge of Woc lite and Bug. Please-o-Please share with community.
 
Yes there is. Try out Orion's Grand Inquisition. http://forums.civfanatics.com/downloads.php?do=file&id=13380

It has WOC Lite, BUG 4.2, Orion's Inquisition and Better BTS AI; as a core base to work from.

Enjoy!

Orion Veteran :cool:

Oh way hay! Thanks we are trying to use this at the moment but have some trouble. We are taking full advantage of this modular loading from WoC Lite, we have added good things from civfanatics downloads.

We are trying to put in modular wonders that need changes in the following files :
CvEventManager
PyHelpers
CvGameUtils

Where do we put the changes from those files? BuG really is confusing... but good ha!
 
CvEventManager

See BUG Core : Events for instructions on adding event handlers. You'll want to compare the new CvEventManager to the one from BTS and remove everything that's the same. Then change the name of the class and module to something else such as MyModEventManager. Now you can add

Code:
<events module=""/>

near the bottom of BUG's Config/init.xml. Ideally you should create your own configuration XML and load it from init.xml, but that's your choice. See BUG Core : Configuration for details.

PyHelpers

BUG doesn't touch this file. Put yours in the root of the Python folder of your merged mod. If there is one already there, it's from WoCLite or some other already-merged mod, and you'll have to merge them using WinMerge or by hand.

CvGameUtils

Similar to events, you need to remove everything in BTS's CvGameUtils from your new file. Rename the module and the class (MyModGameUtils) and add

Code:
<gamutils module="MyModGameUtils" class="MyModGameUtils"/>

to init.xml. This is covered under BUG Core : GameUtils.
 
Back
Top Bottom