WoC Lite(made for merging)

[mamba]

Can someone please help me with these questions?

How can the Modules folder be organized (can you have anything more complex than one-subfolder-per-modmod)? If so, why would one do that?

yes, technically you can have any structure you want. I agree that for a mod-mod everything should be within one subfolder (which in turn can then contain additional subdirs) however.

So even if this is not enforced, it certainly would be recommended imo.

That is as long as we are talking about xml, as soon as there are maps or Python scripts, there probably is a reason to have several directories in a mod-mod.

Is there any facility for inter-modmod dependencies such as A won't load if B isn't loaded?

not really on a mod basis but on a single definition basis, that is what the <AndDependencyTypes> tag is for

Is there any facility to disable a modmod without removing its subfolder?

Yes, the MLF file, any subdir (in this case mod-mod) with <bLoad>0</bLoad> will not be loaded

WoCLite requires Modular XML Loading, right? If so, that means it only works with mods in the Mods folder, right? And if so, will it look for Modules in the CustomAssets folder or must everything be in the mod's own folder?

it can load xml from assets/xml as well, but that would not be modular (obviously).

No idea about CustomAssets, never tried it. In theory it should work imo, as there is nothing which prevents the loading from CustomAssets - but as I said, I never put any xml there.

The getAssetFile() function could be used to find artwork that is not pointed to by one of the XML files (the Great Person mod does this). Are there other file types that would benefit from these functions including Modules subfolders? Can you provide some concrete examples? I'd rather not add every subfolder of Modules to the path if I can avoid it.

Not sure why you would want to find files which are not being referenced in xml. Why is this useful (what am I missing) ?

 

[xienwolf]

bForceOverwrite, if set for an entry in a module, will make the contents of the module completely replace absolutely anything already loaded for the item, so basically reverts that single entry to "normal Firaxis Loading" style. Thus you have to be a bit more cautious about the order of modules which all change the same thing, if they come before bForceOverwrite, then none of them matter, if they come after, then they still change things, just not the BASE things, because the Overwrite module replaced the base.




EF:

1. You can do anything you want with folder structure once you get inside the Modules folder.
2. In WoC there is, with their Dependency tags. In Firaxis there is not.
3. Again, in WoC there is, by editing the MLF files, in Firaxis, nope.
4. Actually your setting for Modular Loading doesn't matter one bit for WoCLite, it is ignored. Either that or turning it ON in your ini messed up WoC, can't quite remember now. Everything needs to be in the Mod folder as I recall though.


Bah, crossposted with mamba. That's what I get for trying to respond during a phonecall

 

[EmperorFool]

That is as long as we are talking about xml, as soon as there are maps or Python scripts, there probably is a reason to have several directories in a mod-mod.

I should have been more clear. I envision each module having subfolders to organize its files. In a sense each modmod folder would be an Assets folder:

My Cool ModMod/
    Config/
        bug.xml
    Art/
        Interface/
            Buttons/
        ...
    Python/
        CoolMapScript.py
        MyCoolModModEvents.py
        MyCoolModModGameUtils.py
        ...
    XML/
        Buildings/
        Units/

This I'm okay with an expect for sanity's sake. What I am asking about is if modules are grouped into subfolders within Modules. I remember reading something about modules being loaded alphabetically and that you can group them into subfolders to alter this:

Modules/
    a_LoadTheseFirst/
        MyModule/
        MoOtherModule/
        zzz_AnotherModule/
    b_LoadTheseNext/
        AndYetAnotherModuleThatMustLoadAfterTheOnesAboveButComesFirstAlphabetically/

Here you have four modules, but to get the last one to load last you need to stick it into another folder that puts it after the first folder. Is this in WoCLite? It's manageable--I just need to know for sure what all the rules are.

not really on a mod basis but on a single definition basis, that is what the <AndDependencyTypes> tag is for

This sounds like an XML CvFooInfo thing that BUG won't have to worry about. hew:

Yes, the MLF file, any subdir (in this case mod-mod) with <bLoad>0</bLoad> will not be loaded

Oh I was so hoping to avoid parsing that file, mainly because it complete defeats the purpose of my work here: avoiding a giant file that must be modified by the user to get stuff to load. Is this file mandatory, or can you just stick modules into the Modules folder and have them load automagically?

No idea about CustomAssets, never tried it. In theory it should work imo, as there is nothing which prevents the loading from CustomAssets - but as I said, I never put any xml there.

What I meant about CustomAssets is that if you pointed to a file in Modules but there was a file with the same name and in the same folder hierarchy but under CustomAssets, the second file would override the first one. This is how XML/Art/Python/Res files all work now as long as NoCustomAssets (mod's INI) or Lock Modified Assets (custom game option) aren't set.

I expect WoC doesn't do this; can anyone familiar with the SDK confirm?

Not sure why you would want to find files which are not being referenced in xml. Why is this useful (what am I missing) ?

The Great Person mod uses the name of the great person from the XML to generate the name of a file to look for in the Art/GreatPerson folder. If it isn't found, it uses the generic one for that type of great person. All of those files could be added to a giant XML file, but then you'd need to modify two XML files to add a new great person name and picture, so the modder left that XML file out entirely.

It's one less giant XML file to parse, and there's little gain in having this level of indirection when it's highly doubtful anyone would need it. If you want to change an person's picture, just replace it in the folder.

BUG uses something similar (list of paths to search) to find its configuration XML files. Supporting modules will require adding paths to that list. As long as the number of modules is kept reasonable and the assets aren't accessed repeatedly in a tight loop, it's no big deal to add all the folders.

It would be cleaner, however, to force modmodders to specifically say, "I'll be searching in this folder for random asset files; add it to the search path." Given that they will be using BugPath to find the file, it seems reasonable to make them tell BUG ahead of time about the folder in their config XML file.

Or maybe I'll just automatically add a subfolder called Art and be done with it. All the XML is loaded by WoC, and I doubt each module will add its own font file (mayhem!) or cursors that will need to be accessed by getAssetFile() and not reference in an XML file.

 

[EmperorFool]

Thanks, xienwolf. It looks like you and mamba are pretty much in agreement. And thanks to you too, mamba.

I would also like to hear from a modmodder's perspective on what they would like to see. [I'm looking at you, Afforess. ] I'd hate to code up some awesome feature that ends up falling short of what people need or solving a non-problem.

 

[xienwolf]

You can let your mod players avoid touching the MLF files for the most part, but if they want to disable something they have installed, they either have to delete the item, move it, or edit the MLF to skip it.


To allow people to avoid dealing with the MLF at all, look at how I structured Fall Further. There are 5 pre-made folders within Modules which are loaded in a special order, but once inside each folder, it uses the normal alphabetical method. Few mod makers actually use dependency stuff in FfH right now, so the 5 is actually overkill, but even in base BtS I doubt you would have to get more intricate than that.

So far, numerous people making modules for Fall Further/Rife/Wild Mana, and no complaints yet. But also few people making use of the more involved tags (a couple use Overwrite, I don't know of any who use Dependency). I haven't seen any threads thus far about "How do I use this module?" so either all modules so far are pre-installed, the module makers are being smart and using installers, or the directions are simple enough.

Sidenote: You really ought to link the great person mod through XML/DLL instead of bizarre python lookups. This is also something done in Fall Furhter, so you could look there for the code to be ready built. (You just add an array for the image and for the quote which are ideally set in tandem with the names)

 

[EmperorFool]

To allow people to avoid dealing with the MLF at all, look at how I structured Fall Further. There are 5 pre-made folders within Modules which are loaded in a special order.

My original plan was similar: folders inside Config to control default load order:

1. BUG Core - BUG core; removal at own peril
2. BUG Features - standard BUG features; removal is fine
3. Mod - for mods that include BUG to add their features
4. User - for end-users to add modmods

What are the five that you use in FF? I prefer standards when possible, and the only other mod that does this seems like a good start for a standard.

Few mod makers actually use dependency stuff in FfH right now.

BUG has only one dependency: Reminder requires Autolog since it can log reminders, but now that I think about it I should just create a Reminder event that Autolog can listen for. That would remove the dependency completely. However, I can imagine future cases where dependencies may be helpful for mods that include Python.

How exactly does the dependency work? Do you put it in the MLF or does it go on the XML element that has the dependency? Specifically, do you say module A depends on module B or rather XML element X in module A depends on XML element Y in module B?

So far, numerous people making modules for Fall Further/Rife/Wild Mana, and no complaints yet.

Great to hear. I often get little feedback about BUG--even when people don't like how things work or find it lacking. There are areas I'd like to improve, but without getting feedback from actual modders I can't design a good solution.

Sidenote: You really ought to link the great person mod through XML/DLL instead of bizarre python lookups.

The Python would be trivial and make it more robust. Building the XML file would be a PITA but doable. It simply maps GP name (e.g. "Plato") to a file ("Art/GreatPeople/Plato.dds"). The mapping isn't all that bizarre and makes adding new GP a snap. Of course, who adds new GP except the modder?

BTW, I haven't even included it in BUG because the separate art ZIP is 200MB whereas BUG is only 2MB. I was tempted to include the Python part (tiny) and left users install the art pack on their own. It's more a BAT thing anyway, but having to modify init.xml has kept it out so far. This no setup I'm moving to would make including it in BAT or as an optional install a snap.

 

[JujuLautre]

Thanks for the explanations. I hope Glider1 can include your tag then

 

[Afforess]

...I doubt each module will add its own font file (mayhem!)

Yeah, famous last words. What if I want to add a new religion, resource, or corporation?

RoM had two modmoders editing the game fonts for a while, it was hard work having the coordinate with Zappara to get the final copy the same.

I would also like to hear from a modmodder's perspective on what they would like to see. [I'm looking at you, Afforess. ] I'd hate to code up some awesome feature that ends up falling short of what people need or solving a non-problem.

Figures, hold a conversation while I'm asleep.

You can let your mod players avoid touching the MLF files for the most part, but if they want to disable something they have installed, they either have to delete the item, move it, or edit the MLF to skip it.

To allow people to avoid dealing with the MLF at all, look at how I structured Fall Further. There are 5 pre-made folders within Modules which are loaded in a special order, but once inside each folder, it uses the normal alphabetical method. Few mod makers actually use dependency stuff in FfH right now, so the 5 is actually overkill, but even in base BtS I doubt you would have to get more intricate than that.

I use dependencies.

Most people modmoding RoM started using either these default folders (We had a few, called Custom Units, Custom Buildings... etc) or just created one with thier name, and use that. For example, my modmods go in Rise of Mankind/Assets/Modules/Afforess...

Using the regular folders or ignoring the MLF is all neat and tidy, but it would suck for anyone with a username beginning with the first letter of the alphabet. If I want to make dependencies, I need to be loaded last, or close to last, and so we just use the MLF. It works pretty good, and as long as it remains universal, there have been no issues. I suppose going without one will be fine for most people.

So far, numerous people making modules for Fall Further/Rife/Wild Mana, and no complaints yet. But also few people making use of the more involved tags (a couple use Overwrite, I don't know of any who use Dependency). I haven't seen any threads thus far about "How do I use this module?" so either all modules so far are pre-installed, the module makers are being smart and using installers, or the directions are simple enough.

I use hundreds of dependencies for Realistic Diplomacy.

Installers are the best way to get them to users though, because most users don't really like or want to navigate the folder hierarchy.

My original plan was similar: folders inside Config to control default load order:

1. BUG Core - BUG core; removal at own peril
2. BUG Features - standard BUG features; removal is fine
3. Mod - for mods that include BUG to add their features
4. User - for end-users to add modmods

What are the five that you use in FF? I prefer standards when possible, and the only other mod that does this seems like a good start for a standard.

If you make some standard universal folders in the Modules folder, please, please, please, keep them all one word, or use an underscore instead of a space. BULL forced us to remove ALL spaces from the paths to button dds for buildings too, which caused some issues originally. Having a space in some universal folders is just asking for trouble.

How exactly does the dependency work? Do you put it in the MLF or does it go on the XML element that has the dependency? Specifically, do you say module A depends on module B or rather XML element X in module A depends on XML element Y in module B?

If XML A depends on XML B, you put a dependency tag in XML A for B, and while the game is init XML, and it hasn't seen XML B by the time it gets to XML A, it skips the loading of the particular object. Not the whole file, just each object with the dependency tag.

 

[xienwolf]

Oops, forgot to state my file structure

• Assets
  • Modules
    • Load Order Vital Modules
      • First Load
      • Second Load
      • Third Load
      • Fourth Load
    • Normal Modules

Everything loads up in the order listed, so if there is something which needs to load in a certain order, that loads up first, and there are 4 premade layers to insert yourself into automatically. Should someone require a 5th or further, they would make the extra folders and add them to the MLF so that there remains no user required action really. The MLF can instead be used to specifically state what order to do things in, bu this saves you from having 20 mods trying to replace your MLF with something that doesn't include all of the other 20. Instead each one would just hop into the folder which works for them, typically that would be Normal Modules as it won't matter when each one loads ideally. But if they use bForceOverwrite, then they would jump in on the First Load (so that no other modules are overwritten, just the base XML), and if they use a dependancy they would ensure that what they depend upon is in FirstLoad, and they are in SecondLoad (or wherever things seem to fit best for them). Within each of those folders, the normal Alpha-Load Order takes over, but that can be changed by dropping an MLF into them which isn't empty.

Also note that I don't use any spaces in my folder names, as spaces in the file path for artwork makes them unable to resize automatically (important for promotions in Unit Hover help)



Dependencies are set up on an individual XML Type basis. So in a single Modular UnitInfos.xml file, you could have some Units depend on other stuff, and others not. Same way as the ForceOverwrite works.



One nice thing that the WoC does for the TGA is make you able to skip corporations/religions which you do not use, so you CAN use a single TGA file, but you DO need to ensure that all pieces are in there before release. The easy approach is just to get a Community TGA going which contains bloody well everything anyone might ever want.

 

[Afforess]

One nice thing that the WoC does for the TGA is make you able to skip corporations/religions which you do not use, so you CAN use a single TGA file, but you DO need to ensure that all pieces are in there before release. The easy approach is just to get a Community TGA going which contains bloody well everything anyone might ever want.

I'd steal RoM's TGA, it has about every bloody icon imaginable in it. Tons of resources, many of which we don't even use, and extra corp and religion icons. In case you don't want to download the massive 500mb RoM archive, here's the Fonts folder:

View attachment Fonts.rar

 

[JujuLautre]

waow, thanks a lot Afforess, that should be helpful

 

[mamba]

I should have been more clear. I envision each module having subfolders to organize its files. In a sense each modmod folder would be an Assets folder:

My Cool ModMod/
    Config/
        bug.xml
    Art/
        Interface/
            Buttons/
        ...
    Python/
        CoolMapScript.py
        MyCoolModModEvents.py
        MyCoolModModGameUtils.py
        ...
    XML/
        Buildings/
        Units/

Hm, I thought each modmod would be under Assets/Modules. The way I understand you here it basically is a whole set of Assets dirs (rather than being underneath Modules).

I guess that if you do have Python etc. you cannot simply drop everything under Modules, but shouldn't in that case at least the xml by under Modules/MyModMod ?

This I'm okay with an expect for sanity's sake. What I am asking about is if modules are grouped into subfolders within Modules. I remember reading something about modules being loaded alphabetically and that you can group them into subfolders to alter this:

I doubt modmods are in subfolders underneath Modules (the way I understand this, that means Modules/someDir/MyModMod rather than Modules/MyModMod. I would expect the latter but not the former).

Your alphabetic load order example should work, but the safer way is to use an MLF file to influence load order (note that the different xml file types, e.g. unitart, civilizations etc.) have an inherent load order, only files of the same 'type' are affected by the MLF load order, all files of the same type are loaded at the same time, i.e. right after each other)

Oh I was so hoping to avoid parsing that file, mainly because it complete defeats the purpose of my work here: avoiding a giant file that must be modified by the user to get stuff to load. Is this file mandatory, or can you just stick modules into the Modules folder and have them load automagically?

well, if you do not parse that file while it exists, your interpretation of load order would differ from the one used by the dll (in essence your is alphabetical while the dll one is MLF based)

For WoCLite the MLF file is not needed, for RevDCM it is (otherwise the dir is not loaded)

What I meant about CustomAssets is that if you pointed to a file in Modules but there was a file with the same name and in the same folder hierarchy but under CustomAssets, the second file would override the first one. This is how XML/Art/Python/Res files all work now as long as NoCustomAssets (mod's INI) or Lock Modified Assets (custom game option) aren't set.

Whoa, I would have expected the opposite, a Mod taking precedence over CustomAssets. I never tried this though.

Or maybe I'll just automatically add a subfolder called Art and be done with it. All the XML is loaded by WoC, and I doubt each module will add its own font file (mayhem!) or cursors that will need to be accessed by getAssetFile() and not reference in an XML file.

I'd go with that, if each mod were to have its own font file, they would not be modular anyway as there can only be one (afaik)

 

[Afforess]

I doubt modmods are in subfolders underneath Modules (the way I understand this, that means Modules/someDir/MyModMod rather than Modules/MyModMod. I would expect the latter but not the former).

I'm not sure I agree here. I don't think I've ever seen a modmod that went straight into Modules/Custom_Buildings
(Custom_Buildings is a Mod-specific folder that comes with the mod).

Most modmods are going in Modules/Modder'sNameHere/SpecificModmodsHere/ActualXMLhere.

 

[EmperorFool]

Yeah, famous last words. What if I want to add a new religion, resource, or corporation?

AFAIK even WoC requires that all the font icons be in a single font file. And that file has to have a specific file name (there are two sizes). You can't just say, "oh, load this other font file over here please."

BULL forced us to remove ALL spaces from the paths to button dds for buildings too, which caused some issues originally.

*sigh* Why do I hear of this only now in an unrelated thread instead of back in March when the first pre-releases of BULL got posted? Was the problem with the building icons in the city bar hover?

In any case, I'll definitely not include spaces.

If XML A depends on XML B, you put a dependency tag in XML A for B, and while the game is init XML, and it hasn't seen XML B by the time it gets to XML A, it skips the loading of the particular object. Not the whole file, just each object with the dependency tag.

I envision dependencies for BUG differently because BUG loads only Python files which are loaded after all XML files have been parsed. You would place the unique mod ID of one mod's configuration XML file in another mod's file. When BUG sees this, it puts the file into a queue of "mods with dependencies" for later processing. All mods that have no dependencies are loaded in some predictable but unimportant order (else you'd put a dependency on it).

Once all non-dependent mods are loaded the ones with dependencies would be ordered according to their dependencies. If A depends on B depends on C, A loads, then B, then C as you'd expect. If any mod fail to load or cannot be found, its dependents are not loaded at all.

So in BUG "depends on" means "must load after and cannot load without". I imagine there really aren't too many cases where order will matter in the Python code. If one mod creates a new event type that another mod consumes, either will create the event type automatically. Order would matter more if two mods had a handler for the same event type of game utils callback, but only if one wanted to override the other.

With events, you typically want both mods to receive the event and do whatever they want. With game utils callbacks only one can return a value back to the SDK. BUG allows you to tell it to override previously installed handlers already, but I doubt many people will need this.

Dependency in BUG, then, will be more about one mod requiring another mod to do anything useful (needs a function from or enhances another mod). In this case you only care that the dependent one isn't loaded if the user uninstalls the depended-upon mod.

Dependency in BUG will most definitely not be done per-object. Of course I'm not 100% certain of that, but that seems like a nightmare. For one thing, Python code doesn't break down that easily like XML does. You may depend on the existence of a function in another module or a global variable or an event type or an option setting, etc. There's no way to easily make that all work in the XML. I don't have that kind of time, and no modder would ever understand the documentation anyway so why bother?

Does it still sound like I need to use the MLF files? In my world, the only place where you need to say that one mod depends on another mod is in the mod's own config XML file (the one that depends on the other). This means you can depend on someone else's mod without ever getting them to do anything, nor will the user need to touch an MLF to do it.

BTW, could you please post one example of a dependency tag in use? How do you specify the other object that you depend on? Do you reference it by modmod folder name?

The easy approach is just to get a Community TGA going which contains bloody well everything anyone might ever want.

Yes, I'm really hoping to avoid the need for this with BUG's new configuration. Each mod should be able to identify the other mods it depends upon without needing any coordination. This is unrelated to the font file; this just seemed like a good segue.

Hm, I thought each modmod would be under Assets/Modules. The way I understand you here it basically is a whole set of Assets dirs (rather than being underneath Modules).

A combination of the two, actually.

MyWoCBasedMod/
  Assets/
    Modules/
      BobsModMod/
        Config/
        Python/
        XML/
      FranksModMod/
        Art/
        XML/

Each individual modmod is free to stuff all of its files into its top-level modmod folder if it wants. I tend to prefer organization even for just a few files.

Since BUG will really only be concerned with Python and Config XML (not normal XML loaded by BTS/WoC), these will be better served placed into separate folders. For one thing, I need to add every folder that contains any Python code to the system Python path. The fewer the folders the better, and the fewer non-Python files in them the better.

well if you do not parse that file while it exists, your interpretation of load order would differ from the one used by the dll (in essence your is alphabetical while the dll one is MLF based)

Keep in mind that the overall game load order is file-type based:

1. XML, by object type so all Civs then all Leaders then all Units . . .
2. Fonts
3. BTS Python
4. BUG Config XML
5. BUG-loaded Python

So really, the MLF/WoC load order of the XML files has no impact on BUG's Config XML load order. I could load them in the same order, but the necessary orderings may in fact be different. One modmod which needs to have its Units loaded after another mod's may not care in which order its BUG Config XML is loaded, or it may need it loaded before the other mod.

 

[Afforess]

*sigh* Why do I hear of this only now in an unrelated thread instead of back in March when the first pre-releases of BULL got posted? Was the problem with the building icons in the city bar hover?

Maybe you should explore other forums once in a while.

BTW, could you please post one example of a dependency tag in use? How do you specify the other object that you depend on? Do you reference it by modmod folder name?

Three types:

<bDependency>1<bDependency>

This means this object must already exist* before loading this file. It's useful for when you modmodmod someone else's work, but not all users might have the other person's stuff. Then the game doesn't go off creating new objects that shouldn't exist.

<AndDependencyTypes>
                <DependencyType>XML_OBJECT_TYPE_1</DependencyType>
                <DependencyType>XML_OBJECT_TYPE_2</DependencyType>
</AndDependencyTypes>

Arrays of dependencies that all must exist* before loading.

<OrDependencyTypes>
                 <DependencyType>XML_OBJECT_TYPE_1</DependencyType>
                 <DependencyType>XML_OBJECT_TYPE_2</DependencyType>
</OrDependencyTypes>

Arrays of dependencies where one must exist* before loading.

*I use exist lightly. The XML file must have been parsed before reaching the dependency. If your XML with dependencies is first to load, and the stuff in the dependencies are the last to load, you're going to be surprised when your changes fail to appear.

So really, the MLF/WoC load order of the XML files has no impact on BUG's Config XML load order. I could load them in the same order, but the necessary orderings may in fact be different. One modmod which needs to have its Units loaded after another mod's may not care in which order its BUG Config XML is loaded, or it may need it loaded before the other mod.

Well...Technically not true. What if my python references a unit in a module? If the module loads after the python... bad things happen.

 

[EmperorFool]

Maybe you should explore other forums once in a while.

Yes, I see the , but honestly if I find a bug in someone's software, I tell them instead of hoping they read my rant elsewhere. Note: I haven't peeked into those links yet, but I'm sure they don't include rants. I'm just being cheeky. I don't think it's too much to expect consumers of my code to let me know when stuff doesn't work, especially since I can fix it for them!

Thank you for the dependency examples. It's much clearer now. These dependencies wouldn't allow you to say, "only apply my changes to an existing XML object if some other mod has already changed that existing object". You can only depend on unique things that must have been created by some other mod. Otherwise you need to use the load-ordering bit.

For BUG's dependency I planned to include both:

<mod id="Reminder" depends="Autolog"> ...

<mod id="Autolog" after="GreatPerson"> ...

<mod id="LuckyCharms" before="Autolog" depends="GreatPerson"> ...

"depends" implies "after" with the additional requirement that the mod was actually loaded. "after" and "before" only mean that if those other mods are loaded, they have an ordering restriction.

Well...Technically not true. What if my python references a unit in a module? If the module loads after the python... bad things happen.

All module Units, Buildings, Civs, Leaders, etc are loaded together before any Python can possibly load. Then all Python loads after all XML has loaded. So your Python is guaranteed to be able to reference any units that were created by any loaded mods.

In my post above, that loading happens across all mods. So all mods' Civs are loaded, then all mods' Leaders, ... then all mods' Python. You cannot have any Python load before all of the XML has finished loading. Period.

 

[mamba]

I'm not sure I agree here. I don't think I've ever seen e familiar structure in a modmod that went straight into Modules/Custom_Buildings
(Custom_Buildings is a Mod-specific folder that comes with the mod).

Most modmods are going in Modules/Modder'sNameHere/SpecificModmodsHere/ActualXMLhere.

Maybe I was not clear enough, I would have expected a mod-mod to have a root dir like this

Assets/Modules/MyModMod

with subdirs for buildings etc. underneath that (not all xml right in the MyModMod dir)

I certainly did not expect a mod-mods buildings in Assets/Modules/Custom_Buildings

But then I never used or made a mod-mod, so I certainly might be off (e.g. I would not have put the modder name subdir in).

A combination of the two, actually.

MyWoCBasedMod/
  Assets/
    Modules/
      BobsModMod/
        Config/
        Python/
        XML/
      FranksModMod/
        Art/
        XML/

I certainly did not expect Python or Art here. If you can pull off having Python in a mod-mod dir structures (rather than one big Python dir) I am all for it. No idea if this is possible or how much work it would be however...

For Art having it in a mod-mod certainly is possible, I personally prefer to have it under Assets/Art compared to the WoC standard (of having it in an Art dir underneath the corresponding xml subdir). Your solution seems to be some middle ground of the two and is feasible, personally I still would put it into Assets/Art/FranksModMod however
but that certainly is of no consequence either way for art that is referenced in the xml (as long as you put the right path in it)

Keep in mind that the overall game load order is file-type based:

1. XML, by object type so all Civs then all Leaders then all Units . . .
2. Fonts
3. BTS Python
4. BUG Config XML
5. BUG-loaded Python

So really, the MLF/WoC load order of the XML files has no impact on BUG's Config XML load order. I could load them in the same order, but the necessary orderings may in fact be different. One modmod which needs to have its Units loaded after another mod's may not care in which order its BUG Config XML is loaded, or it may need it loaded before the other mod.

ok, in this case the MLF load order is of no consequence

 

[mamba]

Well...Technically not true. What if my python references a unit in a module? If the module loads after the python... bad things happen.

Given the load order mentioned this would never be the case however, as all xml is loaded before all Python

 

[Afforess]

Yes, I see the , but honestly if I find a bug in someone's software, I tell them instead of hoping they read my rant elsewhere. Note: I haven't peeked into those links yet, but I'm sure they don't include rants. I'm just being cheeky. I don't think it's too much to expect consumers of my code to let me know when stuff doesn't work, especially since I can fix it for them!

Promotions already work that way, so I figured that the reason was because of resizing, and promotions have the same issue there. Can you really fix it, or do you just mean moving icons to directories without whitespace. We already figured that out.

Short Story:

I assumed it was a feature, not a bug.

All module Units, Buildings, Civs, Leaders, etc are loaded together before any Python can possibly load. Then all Python loads after all XML has loaded. So your Python is guaranteed to be able to reference any units that were created by any loaded mods.

In my post above, that loading happens across all mods. So all mods' Civs are loaded, then all mods' Leaders, ... then all mods' Python. You cannot have any Python load before all of the XML has finished loading. Period.

I didn't know enough about python to tell. Good to know that won't be a problem.

All I'm looking for out of this project is the ability to have more than one init.xml file. That would solve all my headaches. But I'm sure features above and beyond you add will be useful to me as I learn more programming.

 

[mamba]

For BUG's dependency I planned to include both:

<mod id="Reminder" depends="Autolog"> ...

<mod id="Autolog" after="GreatPerson"> ...

<mod id="LuckyCharms" before="Autolog" depends="GreatPerson"> ...

"depends" implies "after" with the additional requirement that the mod was actually loaded. "after" and "before" only mean that if those other mods are loaded, they have an ordering restriction.

Hm, in that case there are two 'problems'

- you need to create a logic to resolve those before and after dependencies (solvable but potentially complex)
- you might create conditions which are impossible to solve, e.g. <Autolog after="LuckyCharms"> and <LuckyCharms after="Autolog"> (with MLF you may have a 'wrong' load order but not an impossible one)