C2C Database Spreadsheet

The unit and promotion schemas are in the same file. To tell if a tag belongs to promoions or to units (or to both) you need to look at where the element defiend is used. If it's in the PromtionInfo element definition (in the schema) then it's used by promotions, if in the untiInfo by units.

Could you please explain this a little further?

You say that by looking at the schema, I can tell, for each tag, which .xml file(s) they belong to?

Looking specifically at C2C_CIV4UnitSchema.xml, unless I'm missing something, I don't see how this could be done. For example, after AIAndy's expressions, the next thing in this particular schema are the PropertyManipulators. This group of tags are used by FormationInfos and by UnitInfos - is there a way I could've concluded this only by looking at the schema? They're not defined in any xml element definition, as far as I can tell. They're just...defined.

This would be extremely useful and time-saving, as the best option that I currently have is taking each tag present in the schema, and then searching for it in all the other 9 xml files in the units folder.

EDIT - And in all the files in the modules folder that appear to be related to Units.

EDIT - I think I'm beginning to understand why nobody had already done this before xD
 
Could you please explain this a little further?

You say that by looking at the schema, I can tell, for each tag, which .xml file(s) they belong to?

Looking specifically at C2C_CIV4UnitSchema.xml, unless I'm missing something, I don't see how this could be done. For example, after AIAndy's expressions, the next thing in this particular schema are the PropertyManipulators. This group of tags are used by FormationInfos and by UnitInfos - is there a way I could've concluded this only by looking at the schema? They're not defined in any xml element definition, as far as I can tell. They're just...defined.
Because expressions are very nested in each other I took the easy way and only defined the tag names. The default XDR model is open so you can have tags even if they are not defined within their parent tag.
In general though most of the tags that can occur in UnitInfos or similar are defined as a subelement in their respective parent element.

If you want to be sure if something can be used somewhere, only the XML reading code in the DLL can give you certainty.
 
Because expressions are very nested in each other I took the easy way and only defined the tag names. The default XDR model is open so you can have tags even if they are not defined within their parent tag.
In general though most of the tags that can occur in UnitInfos or similar are defined as a subelement in their respective parent element.

If you want to be sure if something can be used somewhere, only the XML reading code in the DLL can give you certainty.

Thanks.

Well, in that case, I think I'm gonna have to publish what I can find and rely on you folks to point to any tag, or use of one, that I missed.

EDIT - This feels a bit like failure since the exact point of the project was to create a reference database so nobody needed to be on the lookout for missing tags.
 
Well, here's a simpler more effective way to see what's used where. Simply copy all the text in the xmls (in xml format) into an excel sheet. Name each sheet with the name of the respective xml.

Do a search for each tag in the schema.

Select "Find All"

Excel will show you every occurrence of the tag, and in which sheet (= in which xml).

Only problem is the sheer amount of tags to search for :D But it'll do.

EDIT - <3 Excel http://i.imm.io/waVH.png
 
About updating the database for future versions of the mod. I'm hoping that keeping a backup of the previous version's xml's and schemas, and getting some kind of software that allows for xml file comparison will do the trick. It would still take some manual work.
 
If its any consolation, this confused me as well:
Because expressions are very nested in each other I took the easy way and only defined the tag names. The default XDR model is open so you can have tags even if they are not defined within their parent tag.
How does that work? Are you saying that tags don't need to be nested into the specific info files they can be used in? Does this mean that any declared tag in the schema can be used anywhere? Or are you saying that if the dll calls for a tag in the xml, there's really no absolute necessity that it be even mentioned in the schema at all?

MY limited understanding states that if you're adding a tag, you have two steps in the schema:
1) Declare the tag:
Code:
<ElementType name="iPursuit" content="textOnly" dt:type="int"/>
From what I know, it can pretty much be declared anywhere but near the beginning of the file is best because it should (or maybe MUST) come before the nested statements. This bit of code is particularly locatable by the fact that it states '<ElementType name=' rather than the nested statements which start off as the following does, with <element type=.

2) Nest the tag.
Code:
<element type="iPursuit" minOccurs="0"/>
Here, we're applying the tag and it can be done multiple times throughout the schema under the various info file types defined. Info files are defined as portions of the nested statements, headers that guide the schema reader to understand what they are referring to. For example, that above tag will be under UnitClassInfos so it comes under:
Code:
	<ElementType name="UnitInfo" content="eltOnly">
		<element type="Class" minOccurs="0"/>
and where it is placed in the list that proceeds from there defines the order in which it needs to be delivered in the actual info file under each entry. Since minOccurs="0" exists, it is not required to be present for things to function properly. If I wanted to include the tag in another info file, I could just call another nested statement like this one under that element as well. (but I avoid this so as to reduce confusion and to make it easier for me to work with in the dll as it makes it easy to create an incorrect call to one or the other if tag names are shared.)

When I go into the dll, its a whole 'nother ball game with its own steps. But I'm reading here that somehow the dll can be asked to look up a tag without the schema even having the tag listed? huh... I guess there's a reason I look at your programming codes and shrug and move on without trying too hard to understand them ;)
 
If its any consolation, this confused me as well:
How does that work? Are you saying that tags don't need to be nested into the specific info files they can be used in? Does this mean that any declared tag in the schema can be used anywhere?
Yes, exactly. Any declared tag can be used anywhere and the schema validation will allow it because the default for ElementType in XDR schemas is an open model (it has to be in the same schema file of course).
Using a unit specific tag in a promotion will be ignored by the DLL reading code though.
So regardless of if you do step 2, your schema will work.
 
But that defines the order the tag needs to be listed in the info file right? So if you bypass this step, can you just put the tag anywhere you want in a particular info? For example, if I skip the tag I mentioned above in the nested portion, could I then use that tag at the end, somewhere random in the middle, or even at the beginning of a unit definition?
 
But that defines the order the tag needs to be listed in the info file right? So if you bypass this step, can you just put the tag anywhere you want in a particular info? For example, if I skip the tag I mentioned above in the nested portion, could I then use that tag at the end, somewhere random in the middle, or even at the beginning of a unit definition?
Correct.
Alternatively you could add order="many" to the ElementType UnitInfo.
 
Alright. I'm gonna start tackling the modules folder.

1) Find any possible tags that may be in the modules' schemas, and not in the core schema. Gonna be using ExamXML for this. Pretty nifty tool, makes the task fairly quick. Once I've found and added these, I'll be confident that I have every single tag accounted for.

2) Having every tag accounted for, I need to look for every use of each tag. This will be a bit dull, but easy.

3) Check that all these uses are in the XMLScanner template, so that all of them are exported into the spreadsheet. A bit dull but easy, same as 2).

4) Repeat the process for other folders besides Units.

EDITS:

Step 1) complete (for Units). Found only 1 tag in the modules that wasn't in the core schema: iBaseFoodChange, in the Food_Merchants folder. It's not used in any xml, so I won't include it in the spreadsheet. Most likely some feature not implemented yet. On to step 2)!

Excel has a built-in import xml file feature?? Boy, have I been wasting time xD
 
Folks, is there any reason why I should still use Koshling's XML Scanner to do this project?

I just found out about Excel's Import XML feature, and it cuts down on the amount of work by something like 90%...:crazyeye:

It basically works, it seems to me, the same as a scanner template for Koshling's app, with every single tag in it.

Now, since with Excel I don't need to write the template, OR look for the aforementioned every singe tag, it saves literally days of work. My only concern now would be the way results are displayed, but should be OK.
 
Folks, is there any reason why I should still use Koshling's XML Scanner to do this project?

I just found out about Excel's Import XML feature, and it cuts down on the amount of work by something like 90%...:crazyeye:

It basically works, it seems to me, the same as a scanner template for Koshling's app, with every single tag in it.

Now, since with Excel I don't need to write the template, OR look for the aforementioned every singe tag, it saves literally days of work. My only concern now would be the way results are displayed, but should be OK.

No reason at all! I probably would never have written it if I had realised Excel could import complex XML like this!
 
I had noticed that Excel could work with XML and had thought I had played around with it enough to have eliminated it from contention as a possible solution as I could not get it to import anything in a useful manner. If you figured out how to get it to work right, more power to ya man!

I have a special request too. I'm about to do a thorough review and massive rewrite of the promotion structure and will be needing to get the promotions spreadsheet for that purpose. I'm patient but it is something coming up quicker than I thought it would. (Which is a good thing ;) ) I don't know how fast these things are coming together for you but I figured I'd ask for a priority of focus as its something I'll be needing soon.

Thanks!

Alternatively you could add order="many" to the ElementType UnitInfo.
And how does that work exactly?
 
I have a special request too. I'm about to do a thorough review and massive rewrite of the promotion structure and will be needing to get the promotions spreadsheet for that purpose. I'm patient but it is something coming up quicker than I thought it would. (Which is a good thing ;) ) I don't know how fast these things are coming together for you but I figured I'd ask for a priority of focus as its something I'll be needing soon.

That would be PromotionInfos, correct? Here's what I got for Promotion so far.

Things to note:

a) This includes all promotions both in the core and modules folder - however, I haven't checked yet for tags used by the modules and not by the core ones. What this means is, all promotions from the modules will show up alongside the core promotions; however if any of the modules' promotions uses a tag that none of the core promotions use, that use of the tag will not be reflected in the spreadsheet.

b) Spreadsheet is totally un-formatted. The main issue this may give you is with tags that have multiple entries, like for example UnitCombatMods. You'll find their values a bit confusing, because for the moment the spreadsheet list all values for a particular tag in the same cell.

For example, you'll see this in the UnitCombatMods tag for the Ambush promotion, all in the same cell:

([UnitCombatType=UNITCOMBAT_TRACKED] [iUnitCombatMod=20]) ([UnitCombatType=UNITCOMBAT_WHEELED] [iUnitCombatMod=20])

This means that the promo gives 20 vs both Tracked and Wheeled combat classes.
 

Attachments

Step 1) complete (for Units). Found only 1 tag in the modules that wasn't in the core schema: iBaseFoodChange, in the Food_Merchants folder. It's not used in any xml, so I won't include it in the spreadsheet. Most likely some feature not implemented yet. On to step 2)!

iBaseFoodChange is one of the changes Afforess made to the RoM:AND schema files but the functionality behind it was never tested. In this case the AI should work since it is just another caravan but the unit doesn't do what it is supposed to add the food.

There is a complete list of his tags here they should all be valid for C2C but some we have not used and so are not in the schema files.
 
iBaseFoodChange is one of the changes Afforess made to the RoM:AND schema files but the functionality behind it was never tested. In this case the AI should work since it is just another caravan but the unit doesn't do what it is supposed to add the food.

There is a complete list of his tags here they should all be valid for C2C but some we have not used and so are not in the schema files.

Yeah, I understand that there's probably always a reasoning behind a tag being like this. Just pointing it out :)
 
Yeah, I understand that there's probably always a reasoning behind a tag being like this. Just pointing it out :)
Which is good, as the tag is read by the DLL so it should be in the schema.

@Thunderbrd: When you add order="many" to a parent tag ElementType, the order of its subtypes will not matter, so they can be in any order in the XML.
 
Thanks for the tip AIAndy! Cool little things to know there that I'd've never thought to ask.

@JM: Thanks! That should certainly suffice for what I need it for at the moment :)
 
@JM: Thanks! That should certainly suffice for what I need it for at the moment :)

Now that you've seen some of what I've done, what do you think would be the most important thing to do next?

There's the option of looking through the modules for uses of tags, which is what I've doing. This is an important but dull process, and takes quite a bit of time - I need to search in dozens of different xmls just for the unit-related stuff - and I still haven't found a very streamlined way of doing this (I spoke too soon about Excel's XML importing...a lot of imports get messed up and I don't know why).

Do you think that the priority should be getting every use of every tag accounted for, getting it done for Units, and then move on to buildings and such? Or should I prioritize into something else? I'm asking you because you're the one who wanted to see this project developed :)
 
Back
Top Bottom