Mod switcher

But currently it isn't effective if it fails to merge CustomEvenManager or even Modname files!
 
Go ahead and describe an algorithm for merging new, different files from two mods and I'll implement it. Meanwhile, either alter the mods so that the files have different names, or just decide which mod shall take precedence by clicking one of the buttons when the conflict is reported.

In my opinion, this problem should be brought to the attention of modders and better practices should be introduced and applied.

The program is currently quite effective for some mods, e.g. new civilizations. The version number starts with 0 for a reason.
 
I'm for one am very glad you're working on this project. :goodjob:
I also have to agree with you that the modding community should make a big effort to allow the mods to be combined with others, this would also mean a great deal for this mod-switcher.

As you have mentioned before the EFA en MSDA are sharing a common file DomPyHelper.py IIRC. How do you advise using your program merging these two or should I try manually to combine these mods into 1 and use this new mod instead?
 
It seems that actually MSDA has removed one function when compared to EFA (or EFA has added that since MSDA copied the file). To combine, you first need to add this function into class DomPyPlayer:

Code:
  def getStateReligion (self):
    return self.player.getStateReligion()

Then just select MSDA when the program reports the conflict. I haven't tested this myself but it should work.

Would someone want to take up the task of communicating this kind of things to mod makers, or maybe even fixing up mods if needed? I do some of that myself, when I'm starting a new game, but my games tend to go on for weeks.
 
I've been trying to get it to work, but I don't seem to be doing well. :(

I've added the function you described. I found it blanked out with ## so it was easy enough to add it.

If I select both mods (EFA and MSDA) I end up with only MSDA whichever mod I select in the conflict popup. (MSDA is the first in the list)

If I select one mod at a time it works perfectly.

I hope this helps you in resolving this. If you need more info, let me know.
 
It's possible that they both modify some file in ways that can't be trivially combined. I'll take a look at this in a few days.
 
For some reason, it's not letting me use large mods like the Sevomod -- I get the usual windows error. Is this just caused by load on the system (though my computer is pretty new), or is it an actual problem?

Also, with most other mods that I try to load, I get an error message that says, "Value element CommerceChangeOriginalOwners has children. Maybe it isn't really a value element?", or some other value element in place of CommerceChangeOriginalOwners. Then, when I click OK, the program stops trying to load the mod component. When I play the mod component, though, it works fine. Is there any way to work around this?

I would also like to say that this is a great idea for a program, and I think that many people (myself included) will find it very useful.
 
Ah, Windows and its wonderfully verbose error messages. I'll see if I can reproduce the problem and fix it.

As for the value element error, the reason is that that particular element is not supported. Please tell me the mod and file names and I'll add support for them.
 
I get the windows error message when I try to load Sevomod or Total Realism.

For value elements, I had problems with UnitFormations in Civ4FormationInfos.xml in the Immigration Mod (by TheLopez) and CommerceChangeOriginalOwners in CIV4BuildingInfos.xml in the Shinto Mod (by Dual). Now that I try some other mod components, they usually work, so I guess I just tried the wrong ones.

Thanks in advance.
 
tbd I have been adding more stuff to elements.txt and am able to solve most error messages with such, but I am unable to figure out a particular class of XML files, particularly thouse that have multiple children directly under the root element. Civ4GlobalDefines is the most obvious of these but their are others. Anything with the format

<Root>
...<InfoObject>
...<InfoObject>
...<InfoObject>
</Root>

Is generating a "Root element has Children maybe its not a value"
When a file is structured

<Root>
...<Infos>
......<InfoObject>
......<InfoObject>
......<InfoObject>
...</Infos>
</Root>

I have no problems with these, most major files are structured this way and the program handles them fine once I add support for the various InfoObjects. If you can explain or provide an example of how to add elements.txt support for the GlobalDefines style file I should be able to apply it to any other such files which give me trouble.

Also here is the latest element.txt containing additional supported XML files
 

Attachments

Impaler: Make the root element a container. The toplevel type is just a trick to skip the root element. For an example, see the text definition files.

I noticed this when diffing your version against my original:

Code:
@@ -94,12 +217,15 @@
 LeaderHeadInfos Trait object TraitType
 LeaderHeadInfos UnitAIWeightModifier object UnitAIType
 LeaderHeadInfos ImprovementWeightModifier object ImprovementType
+LeaderHeadInfos Trait object TraitType

Any particular reason for adding the Trait element again? Or did you just miss the first definition?

Also, I'd appreciate if you kept the style similar to my own. I.e. add a space after # and drop CIV4 from the file names. (No offense, just a hint for how to be even more useful)
 
Couldn't help it to try some more.

It looks like when a conflict arises civmodder always uses the first in the list, regardless which mod you select, and any files following the file that causes the conflict will be ommitted and only the files from the first one in the list will be used.

I moved the Dompyhelper entry in the diff to the end, and then the next file causes the conflict. When I move that one to the end as well, all files exept those two get merged.

HTH
 
Turns out that the prioritizing code had a bug in it. The fix will be in the next version.
 
Arrrgh. CIV4PlotLSystem.xml is getting more and more difficult. Towards the end of the file, I found LProduction elements, which are similar to the ArtRefs in that the don't have any identifying key. However, they're contained in the root element, along with LNode elements, which _do_ have a key (and which contain the ArtRefs). If I treated the whole root element as a blindset, each LNode would be considered as one unit. However, this would be sub-optimal since mods change or add ArtRefs but leave others in the same LNode untouched. Treating LNodes and LProductions differently produces its own set of problems, since the existing code is not too well suited for that.

Yet more problems come from the fact that the damn file uses CSV lists for things (example from a diff with GreenMod):

Code:
@@ -3050,7 +3738,7 @@
        <!-- input=PlotBuilder_Productions/Node_6x6_03.bmp -->
        <LProduction From="Node_6x6">
                <Attribute Class="Improvement">NO_IMPROVEMENT,IMPROVEMENT_ALL,!IMPROVEMENT_FARM</Attribute>
-               <Attribute Class="Bonus">NO_BONUS,BONUS_ALL,!BONUS_DYE</Attribute>
+               <Attribute Class="Bonus">NO_BONUS,BONUS_ALL,!BONUS_DYE,!BONUS_CANNABIS,!BONUS_COTTON</Attribute>
                <To Name="Node_3x2">
                        <Translate>-2.000000,-1.500000</Translate>
                        <Rotate>90</Rotate>

Now if I wanted to make cannabis and cotton separate mods (and I'd very much like to), I'd have to process the CSV list for additions. And since this is inside an element with no key, I have no way of connecting these additions to the original element when applying the mod.

And it doesn't even end there. If several mods were to change this file, the applying process would fail horribly. You see, mods are applied in sequence, incrementally. The way I had thought blindset to work was to compare everything in the elements to produce a set of additions and removals. But! If mod A removes something and adds something else, and then mod B tries to change the same thing, it doesn't see the original anymore but will add its own, producing a duplicate. Not good.

In short: Arrrgh.

Any ideas are welcome, my supply is starting to run out.
 
As for SevoMod and Total Realism... I'm unable to install them with Cedega to try them (damn nonstandard installers, what's wrong with good old zipfiles?), but it is likely their size will cause problems. Civ4Modder needs to keep the mods entirely in memory when it's doing something with them, and there aren't any checks for memory allocations succeeding. At some points the memory requirement might be more than twice the size of the (uncompressed) "standard" mod.

I'll try with my Windows box at some later time - I'm currently experiencing some hard drive problems with it. Meanwhile, if you could tell me how much RAM your system has, that might help me reproduce the problem.

The Shinto mod is missing some element definitions, I'll add them in the next version. I'll probably be using that mod myself too.
 
Impaler: I put the files in elements.txt in alphabetical order for easier maintenance and added some informational comments at the top. Please use this one as a base for future additions.

http://tdb.fi/~tdb/elements.txt

viper275: Shinto mod builds with this file, so you might want to try it while waiting for the next version. The Shinto buildings won't show up on the world map due to CityLSystem.xml not being processed (see my above rantish post for reasons), but otherwise it works fine.
 
My computer has 512 MB of RAM, so that could explain the problem with Total Realism and Sevomod. Thanks for helping with the Shinto Mod, any ideas with the Immigration Mod?
 
Back
Top Bottom