Dancing Hoskuld
Deity
Thank, it was newer that the one I was linking to.
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.
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.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.
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?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.
<ElementType name="iPursuit" content="textOnly" dt:type="int"/>
<element type="iPursuit" minOccurs="0"/>
<ElementType name="UnitInfo" content="eltOnly">
<element type="Class" minOccurs="0"/>
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).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?
Correct.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?
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%...
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.
And how does that work exactly?Alternatively you could add order="many" to the ElementType UnitInfo.
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.
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.
Which is good, as the tag is read by the DLL so it should be in the schema.Yeah, I understand that there's probably always a reasoning behind a tag being like this. Just pointing it out![]()
@JM: Thanks! That should certainly suffice for what I need it for at the moment![]()