Mod Combining

Stalin_Bulldog

Chieftain
Joined
Dec 3, 2005
Messages
74
I have seen alot of posts on this general topic, but to fully facilitate it we should standardize the way we tag mods, this will allow a crawler program to find the edited portions of code and insert them in the correct place when appending them to main xml/python files

i'd sugguest a very general style along the lines of
xml: //<mod="MODNAME">
//</mod="MODNAME">
python: #<mod="MODNAME">
#</mod="MODNAME">

these are just examples, but in general most modders block their mods in comments, and if we could standardize the modding community on this topic a crawler program would be very easy to build.
 
would it be possible for this to let you choose more than one (non conflicting) mod? if so, it'd rock.
 
If we could get an established standard you could merge two mods together very easily, since the program would just parse out the altered parts and combine them into one larger file, as for conflict identification, it'd be difficult, and certainly not in initial release, but i believe it would be possible to identify some of the conflicts
 
I for one would love to see a utility that would compile custom mods out of 'modules' made by modders. A standardized way of modding would allow so much, and it would probably be far simpler to make such mods in the future. IE, a script that would contain all steps in modding XML files and links to all art that needs inclusion in the mod, the utility would then simply append all the files, write them, and copy over all the art. and anyone could get whatever they like best. I think its well worth the effort, and if there's any programmer willing to take this upon themselves I'm more than willing to help. I would start this myself, but, alas, my programming skill end with Borland Turbo Pascal.
 
Yea i am a CS major, and while i lack alot in the departments of art, and taste required to make a full mod, i was thinking perhapes i could use my skills to help modders in a smaller way

If a standard was implimented, i could easily get a program that manages them out by early January,
 
Well, I just did some experimenting with a few files and I think I can set something up, it shouldnt be that difficult. Once its up a simple script could build mods.

I'll get on working out a concept. Try to keep it simple and noobfriendly.
 
[HEADER]The name, version and description of the module[/HEADER]

[ADDFILE=Root_folder\File_name]Target_folder\File_name[/ADDFILE] - copies artwork that needs to be included into the mod

[MODFILE=File that needs to be modded]Data that needs to be inserted[/MODFILE] - adds modded data to files

[\MODFILE=File that needs to be modded]Data that needs to be deleted[/MODFILE] - deletes original data from files

I think this would be all the syntax this compiler would need to get working. Here's how I envisioned it:

You start up the program and it detects all the modules you have in your mods folder. When you click on a module it gives you the info from the header so you know what it contains.

When your're satisfied with your pick it compiles the result. The script really needs to know only three orders. Copy, Add and Delete. It needs to copy artwork it will include. Add new code to the original. If original code needs to be deleted, then it deletes it, if it needs to be modified, it deletes existing and adds modified.

The rest is all about very simple standardization on how to make scripts for modules and standardized naming so that names do not overlap.
 
Here's my idea for basic standard:

xxx-yyy-zzz

xxx-unique modder code(IE. ARC for Anima Croatorum)
yyy-unique mod code, designated by modder(IE. 001 for my Croatia mod, 002 for my Hungary mod)
zzz-mod version(IE. 101 for my 1.01 version)

Each modder would pick and register the xxx part and use the yyy and zzz however he pleases, since all the relevant info for the end user would be in the header, accessible when picking stuff to include or not.

So, basically, my Croatia mod would be ARC-001-101.mod, all artwork would be stored within the ARC-001-101 folder and subfolders, leaders, units, sounds... doesnt matter. So there wouldnt be any overlapping.

No original artwork would be modded(IE. the three .dds files in the art\interface\buttons folder) but additions would be in a separate file.
 
Uniqueness would definately have to be enforced, but using full modder names is much easier than abbreviations, since first of all, there are probably more than 26^3 modders, and even if there aren't there would almost certainly be substantial collisions, i'm not talking full real names, privacy should be respected, but for instance, civfanatics SNs, although there is a problem with overlap with apolyton, it will most likely be very limited

But otherwise yea thats a very good way to do it
 
26x26x26=17576, but it does not matter really, I'd simply prefer if everyone used a code of equal length, 3,8,15, doesnt matter. It will be easier to keep track and organize once theres over a few dozen modders.

Other than that its just a matter of following simple guidelines. Not to complicate things, but to make it easier. It would be a standard, but also a manual on how to make the best possible mod, with least trouble and errors.
 
Anima Croatorum said:
[ADDFILE=Root_folder\File_name]Target_folder\File_name[/ADDFILE] - copies artwork that needs to be included into the mod

This is plain stupid. You shouldnt even bother adding files, just add the entire folder to the mod.

[ADDFOLDER=Folder] - includes a folder into the mod.

IE. [ADDFOLDER=ARC-001-101] and it copies all the artwork the mod needs.
 
Okay, so what do you want the actual modders to do within their files?
And // doesn't comment code in Civ4's XML files. <!-- text --> does.
You can also break up the comments to something like
<!--
Comments here
-->
 
And // doesn't comment code in Civ4's XML files. <!-- text --> does.
oh sorry, i assumed it followed c-commentes

And also on the topic of standardized lengths, it is reasonable, but it'd be much easier to use a terminus charecter, like a semi-colon after then end of someone's name

On the topic of artwork copying, in the interest of simplicity, all the artwork would be copied, doing anything else is just putting too much pressure on the modder

And lastly, this is meant to allow modders and users to consolidate mods, the topic of better modding techniques is misplaced in this.
 
Basically, the mod would be just one file with instructions of what to include into the xml files.

Everything you added to the xml files would be copy/pasted into this file along with the adress to which file it relates to.

IE.

[Modfile=XML\Civilizations\civ4civilizations.xml]
you insert all relevant data for your civ that goes into this file
[/Modfile]

then next, file, then next...

The utility would then use this script to include your civ along with others.
Art and Sounds would not be in a subfolder not to interfere with other mods. The buttons(unit_resource_atlas, actions_builds_leaderheads_specialists_atlas, civics_civilizations_religions_atlas) files for civilopedia would not be modded, but would be in a new file. Tried it out this evening, and it works and makes the mod smaller(Made a 256x64 .dds containing the flag, unit and two leader buttons)
 
An import file is not required, digging through the mod's custom assests file would give you all the req. files, the import part that must be deliminated is the area of the file that was altered, now... there are ways to detect that without specific tagging but they'll often lead to innacuracies
 
Well, you're the programmer. Whatever works best. As it is, there are like 100+ xml files and another 600+ python files that are moddable.

You could make an algorhytm that recognizes the file syntax, determines blocks of data(like units, civs...) checks for unique ones and inserts them into apropriate place within the file syntax.

The only 'problematic' ones would be original entries that were modded. IE. You make a Texas civ and remove Texan cities from America. Would the procedure add both Texas and Texas-less America while leaving original America?
 
Back
Top Bottom