XML Idiot Seeks Guidance

[Serenity42]

When it comes to modding Civ, I have a serious disability: I do not understand XML. I've read books, gone through online tutorials, and yet remain an idiot -- frustrating, because I can code C in my sleep. I therefore beg all of you XML-smart people to take pity and guide me out of the woods on two small edits.

1. I'm trying to add Marines as an upgrade option to Infantry. Thanks to Peter450, I know this involves the UnitInfos file, and that I must add a "UnitClassUpgrades" entry, but I cannot find where each unit entry begins and ends, let alone finding the actual entry for Infantry.

2. I'd also like to enable the construction of cottages/villages/towns on Tundra terrain. I know this involves the Civ4ImprovementInfos file thanks to The J, but I cannot even find the proper entry for Tundra, and the flags that apparently set what can and cannot be built make no sense to me.

I realize that all of this probably sounds incredibly pathetic, and I agree. I used to be able to mod Alpha Centauri like it was clay, and I have a degree in programming, yet I seem totally unable to untangle XML. If someone can help me out, I'd be extremely grateful.

 

[xienwolf]

Since you are a programmer, I'll talk in a way which won't really be of use to a normal person potentially, and might even be confusing for you since I suck at Jargon.


XML uses a container type of framework. Using <> around something marks it as kind of a "Book End" for each container. If it is <stuff/> (slash at the end of the label) then it is an empty container, nothing is inside of it. Otherwise, you will find <stuff> (no slash - Opens a container, everything that follows until this container is closed is considered to be INSIDE this container) and </stuff> (slash before the matching label - closes a container, everything that was between this and the matching open container label is inside this container)


Containers can exist within containers (nested), or you can just have text or numbers. Typically you never have both. Also, people typically will indent when nesting containers to make it easier to read, just like in C++ you typically indent when placing items inside an IF statement or other loop/conditional. This is a custom, not a requirement (so works like C, not like Python)



Primary Containers (a specific unit or terrain) are labeled in Civ with <Type>stuff</Type>, typically the first item listed within the container. That is what tells you where to be for your edit purposes.




Schema files exist to tell the programs which load the XML what containers to expect to find within what other containers. Mostly you can ignore the schema files unless you start trying to introduce new elements into XML.


Overall, think of XML not as programming, but as a fancy box to store data in. That is really all it is used for.

 

[Serenity42]

That makes things MUCH clearer! So the entire purpose of XML is to function as a data container language rather than an instruction set. Well, now...that explains why I was getting so confused.

So, for example, within the UnitInfos file, I should be looking for an end-margin line titled something to the effect of <UNITCLASS> UNITCLASS_INFANTRY ...which should be the unit I want to edit, and WITHIN that group should be a nested <UnitClassUpgrades> container for the different units to which Infantry can upgrade, correct?

Okay, I'm on board with you up to that point, but the permissions flags in the terrain upgrades seem to follow different rules. Do they, or is it just formatting messing me up?

 

[The_J]

So, for example, within the UnitInfos file, I should be looking for an end-margin line titled something to the effect of <UNITCLASS> UNITCLASS_INFANTRY ...which should be the unit I want to edit, and WITHIN that group should be a nested <UnitClassUpgrades> container for the different units to which Infantry can upgrade, correct?

Yup, that's it.

Okay, I'm on board with you up to that point, but the permissions flags in the terrain upgrades seem to follow different rules. Do they, or is it just formatting messing me up?

No, this file is like the others.

But don't look at PlotLSystem.xml, that file is strange.

 

[Serenity42]

Yup, that's it.



No, this file is like the others.

But don't look at PlotLSystem.xml, that file is strange.

That one did look even more perplexing than the rest...which, given my abilities, doesn't say much, but I'm glad I'm not the only one.

How are the different terrain types identified? There didn't seem to be any coherent differentiation from one to the next? Worse still, it didn't seem to follow a pattern; I was expecting to find a series of 0/1 flags for the different upgrade types, but didn't see that. Where am I getting lost?

 

[The_J]

I'm not at my civ-computer, so i can't be exact, sorry, but i'll try it:
Terrain: There's a separate container for the terrain:

<TerrainsMakesValid>
<TerrainMakesValid>
<TerrainType>TERRAIN_DESERT</TerrainType>
<bMakesValid>1</bMakesValid>
</TerrainMakesValid>
</TerrainsMakesValid>

or so.


But are some other factors, which influence that.
Like said in an other thread, there are minimum output prereqs for some improvements, like for farms.
I think, the first section, where the yields are mentioned in the farm entry, is it.

Also there's a tag

<bWater>0<bWater>

which says, if it's a water improvement, or not (needs boolean values).

 

[Serenity42]

So is the improvements file organized by Improvement>Terrain>Yes/No, or Terrain>Improvement>Yes/No?

I was looking for the terrain as the primary element, then looking under it for cottages, then a yes/no flag. Was I going backwards?

 

[The_J]

So is the improvements file organized by Improvement>Terrain>Yes/No, or Terrain>Improvement>Yes/No?

The first.

I was looking for the terrain as the primary element, then looking under it for cottages, then a yes/no flag. Was I going backwards?

That was completly wrong.

You have to look for cottages, and then for the terrain.



What i forgot in the last post:
Improvemnt-upgrade is determined through one of the last tags, but i don't know the exact name atm.

 

[xienwolf]

In almost every XML file, the 3rd nesting is where the individual elements start.

For Example, in CVI4UnitInfos.xml the first tag is <Civ4UnitInfos>, which doesn't close until the last line of the file. Then is <UnitInfos> which doesn't close until the next to last line of the file. Then is the primary Container, <UnitInfo>. Each time this container is re-opened, you are in a new unit. All information in there (even if nested deeper) pertains to a single specific unit.


This format is used for essentially all of the files. <CIV4_____s> --> <______s> --> <_____> Where the _____ is also a part of the XML's filename for simplicity.


So nothing will be inside of a group <UNITCLASS>_____, but rather they would be inside of a <UnitClassInfo> along with a <Type>UNITCLASS_XXXX</Type>, and this Type would indicate which particular unitclass we are talking about.



Unfortunately, without looking in the DLL code (C++, so not a problem for you I hope, once you get used to Civ's style) you can only guess at what the data stored in each field will actually mean in terms of game results, but most are pretty self-explanatory.

 

[Serenity42]

I can't believe how simple this whole system was! Thank you so much for explaining it! It all actually makes sense now! I was looking at the whole thing absolutely sideways. I tried out the edits last night and, admittedly, with a couple false starts, I managed to get them to work. Sure, it's not as easy as the text file system that Alpha Centauri used, but it's at least workable now!

Hey, if you guys need any copy written for your mods, just say the word! THAT, at least I can handle without coaching!

This is great! Now I just need to find a 3D modeler and I'm all set!