The convention is that the schema in the main folders is the up to date one while the ones in the mod folders may be older (and therefore might contain fewer tags).
C2C Database Spreadsheet
- Thread starter jmmendesp
- Start date
Thunderbrd
C2C War Dog
We also have some in the mod folders that have tags that don't exist in the main which I found a bit confusing.
Well, in those cases write them down and I will either add them to the main schemes if they are valid or remove them if they are not.
Progress Update
.xml files in the C2C/Assets/Units folder are about 90% converted. This means PromotionInfos, FormationInfos, etc., to go along with UnitInfos. The conversion reaching 100% will lead to the following:
- Initial spreadsheet formatting. All .xmls in the same Excel file (currently each xml has a separate excel file), with 1 separate worksheet for each xml, stuff like that.
- Finding of possible occurrences of unused schema tags.
- Beginning of work to make the spreadsheet useful and easy to use. Addition of filters, grouping related tags by categories, etc.
After this is done I hope I'll have something worthy of calling itself a reference spreadsheet for the mod's XML, so I'll post the most recent version. With some feedback from the modding team, I'll then proceed to add features to the Units folder spreadsheet, and begin the work of converting the other folders into similar formats.
.xml files in the C2C/Assets/Units folder are about 90% converted. This means PromotionInfos, FormationInfos, etc., to go along with UnitInfos. The conversion reaching 100% will lead to the following:
- Initial spreadsheet formatting. All .xmls in the same Excel file (currently each xml has a separate excel file), with 1 separate worksheet for each xml, stuff like that.
- Finding of possible occurrences of unused schema tags.
- Beginning of work to make the spreadsheet useful and easy to use. Addition of filters, grouping related tags by categories, etc.
After this is done I hope I'll have something worthy of calling itself a reference spreadsheet for the mod's XML, so I'll post the most recent version. With some feedback from the modding team, I'll then proceed to add features to the Units folder spreadsheet, and begin the work of converting the other folders into similar formats.
Dancing Hoskuld
Deity
Some of Afforess' tags are not in the main schema files. The same goes for a couple of BtS ones. I added the bGraphicalOnly one to the main schema files awhile back since I was the only one using it at the time.
Thunderbrd
C2C War Dog
Ok. I mentioned them before. They were in DH's unit schemas I think. Something to do with the commanders or somesuch that created BIG problems when I tried to put them in the core schema. He seems to know what those are about but what I find confusing is why merging them into the core schema caused problems.
Great job so far jmmendesp! Thank you for your efforts!
Often that kind of problem in the schemas happens if you add a tag name that is already there somewhere in the file.
Question.
In C2C/Assets/XML/Units, every single file lists ' xmlns="x-schema:C2C_CIV4UnitSchema.xml">' as its schema - except FormationsInfo, which lists ' xmlns="x-schema:Civ4FormationSchema.xml"> '.
Why is this? According to Thunderbrd's quote, this would be wrong?
FormationInfos is different as its reading is triggered by the EXE (although it is executed in the DLL) and it is also only used by the EXE. So we never changed its schema (which is in the equivalent folder in the BtS installation).
Thunderbrd
C2C War Dog
Hmm... I wonder if that's possibly the answer there... I mean, I know the 'rule' you're referring to there but if that was the case, wouldn't you think that in the compare program, the module's schema would show that it did NOT have the tag in another section where the module DID? Assuming you mean that basically what I was doing was adopting tags that already existed, just in another area of the core schema. I would think that if that was the case I'd either see that it was elsewhere in the core and missing from that spot in the module schema, OR you'd have a crash thanks the module schema itself having listed it twice.
Well, if a tag is defined in there twice, the XML validation fails and therefore it does not even read that XML file (lots of error messages about missing things occur as a result).
It is one of the most common errors I get when I add a new tag with several subtags as the subtag names are often reused.
Some interesting facts about the schemas:
What is used here are XDR schemas, an obsolete standard from Microsoft. Nowadays other schema standards are used.
ElementType can actually have a model defined but that is usually not the case in our schemas. Therefore it defaults to "open" which means that the subelements defined are not the only ones that can occur in as subtags but any of the ElementType defined in that schema can.
It can also define an order but that is not the case in our schemas so it defaults to "seq" which means that the subtags have to occur in the same order as in the schema despite that the XML reading code in the DLL does not care about order at all.
Thunderbrd
C2C War Dog
Good info but I think you missed my point.
If I compare schema A to schema B and I get two lines showing up as differing (extra lines in schema B) and I add those two lines to schema A then I can't imagine how I would get that error.
If schema B had an extra declaration on an already once declared tag then it would've erred when it loaded last.
If it did not, then the compare would've shown not only that schema B had a few extra lines somewhere, but was also missing those lines elsewhere in comparison to schema A.
Since this wasn't the case, I don't see how a doubly defined tag could've caused any problems to come up in a compare merge unless it was a pre-existing condition in either schema already, which was proven not to be the case by the fact that they had both been included in a previous load without error.
Thus, whatever the problem I had encountered could not have been a result of having a doubly defined tag.
I was warned to watch out for that in my tutorials... And the seq part was interesting. I thought that's how I remembered it worked but I wasn't completely sure. So when we define a new tag, then apply it, its only the schema that is determining the proper 'order' and this does not relate to a proper 'order' of loading in the dll, but the dll does have to get order correct when establishing the read and write routines because those only load on a sequential basis as well. That pretty much sums it up where making sure things are in 'order' are concerned right?
If I compare schema A to schema B and I get two lines showing up as differing (extra lines in schema B) and I add those two lines to schema A then I can't imagine how I would get that error.
If schema B had an extra declaration on an already once declared tag then it would've erred when it loaded last.
If it did not, then the compare would've shown not only that schema B had a few extra lines somewhere, but was also missing those lines elsewhere in comparison to schema A.
Since this wasn't the case, I don't see how a doubly defined tag could've caused any problems to come up in a compare merge unless it was a pre-existing condition in either schema already, which was proven not to be the case by the fact that they had both been included in a previous load without error.
Thus, whatever the problem I had encountered could not have been a result of having a doubly defined tag.
I was warned to watch out for that in my tutorials... And the seq part was interesting. I thought that's how I remembered it worked but I wasn't completely sure. So when we define a new tag, then apply it, its only the schema that is determining the proper 'order' and this does not relate to a proper 'order' of loading in the dll, but the dll does have to get order correct when establishing the read and write routines because those only load on a sequential basis as well. That pretty much sums it up where making sure things are in 'order' are concerned right?
Then I don't know what the problem might have been without seeing the specific case.
The read and write routines from and to streams are very order dependent, yes, but only towards each other. There is no need for it to be the same order as in the XML schema.
Buttons!
Ok, so in the button tag, some items will point to the standard .dds file in the art folder.
Example: <Button>Art/Interface/Buttons/Builds/BuildMaglev.dds</Button>
Yet some other start with a comma, then have 2 numbers at the end, separated by commas.
Example: ",Art/Interface/Buttons/Builds/BuildFarm.dds,Art/Interface/Buttons/Actions_Builds_LeaderHeads_Specialists_Atlas.dds,3,7"
The commas create some exporting issues (since koshling's scanner exports the data into comma separated values, seeing the commas as an order to "skip a column"), but I can fix those manually by some copy pasting post-export - so I guess it's mostly out of curiosity that I ask: what do those numbers do, and why do the entries with numbers in them begin with a comma?
Ok, so in the button tag, some items will point to the standard .dds file in the art folder.
Example: <Button>Art/Interface/Buttons/Builds/BuildMaglev.dds</Button>
Yet some other start with a comma, then have 2 numbers at the end, separated by commas.
Example: ",Art/Interface/Buttons/Builds/BuildFarm.dds,Art/Interface/Buttons/Actions_Builds_LeaderHeads_Specialists_Atlas.dds,3,7"
The commas create some exporting issues (since koshling's scanner exports the data into comma separated values, seeing the commas as an order to "skip a column"), but I can fix those manually by some copy pasting post-export - so I guess it's mostly out of curiosity that I ask: what do those numbers do, and why do the entries with numbers in them begin with a comma?
God-Emperor
Deity
The form with the leading comma is used to specify a button in an Atlas.
Each atlas has multiple buttons which are referenced by row and column, which is what the two numbers are. As for what the first of the two files is supposed to be for, that is not clear - I remember someone sating that it may have been the value for a low resolution button or something like that, but that it was never implemented in the game. A lot of them are apparently random junk from whatever entry was copied and pasted when entering a new thing into the file.
Each atlas has multiple buttons which are referenced by row and column, which is what the two numbers are. As for what the first of the two files is supposed to be for, that is not clear - I remember someone sating that it may have been the value for a low resolution button or something like that, but that it was never implemented in the game. A lot of them are apparently random junk from whatever entry was copied and pasted when entering a new thing into the file.
Ah, I see, thanks a lot.
Breakthrough!
Turned out I wasn't using the most recent version of Koshling's app. After searching 100+ pages of the ideas thread for the word "scanner" I found one that manages to export the tags I previously couldn't!
So @Koshling, no need to look at my templates now, a more recent version of your app fixed them
EDITS
a) I also found why the Apache Cavalry had all its data in the wrong columns...commas
b) Now that all the tags are working, can I trust C2C_CIV4UnitSchema in the Assets/XML/Units folder to contain all the tags that are used by the units in Assets/Modules?
Turned out I wasn't using the most recent version of Koshling's app. After searching 100+ pages of the ideas thread for the word "scanner" I found one that manages to export the tags I previously couldn't!
So @Koshling, no need to look at my templates now, a more recent version of your app fixed them
EDITS
a) I also found why the Apache Cavalry had all its data in the wrong columns...commas
b) Now that all the tags are working, can I trust C2C_CIV4UnitSchema in the Assets/XML/Units folder to contain all the tags that are used by the units in Assets/Modules?
Thunderbrd
C2C War Dog
It should be trustworthy enough for the purposes of this project. If we find a discrepancy, we should let you know so you can update on that basis. I could be wrong but I think there are tags in DH's modules that don't exist in the core. I have not tried to verify this suspicion though.
Well done on those breakthroughs! That's the kind of spirit this modding work requires at nearly every turn it seems
Feels good to get past roadblocks like that huh?
Well done on those breakthroughs! That's the kind of spirit this modding work requires at nearly every turn it seems
Feels good to get past roadblocks like that huh?
Dancing Hoskuld
Deity
Breakthrough!
Turned out I wasn't using the most recent version of Koshling's app. After searching 100+ pages of the ideas thread for the word "scanner" I found one that manages to export the tags I previously couldn't!
So @Koshling, no need to look at my templates now, a more recent version of your app fixed them
EDITS
a) I also found why the Apache Cavalry had all its data in the wrong columns...commas
b) Now that all the tags are working, can I trust C2C_CIV4UnitSchema in the Assets/XML/Units folder to contain all the tags that are used by the units in Assets/Modules?
And you provided me with a link to that newer version so I could update the modders documentation?
All other schema files are likely to be a subset of the C2C_ schema files. I think I put any tags that I use that were not in the c2c_ onto them. Note I don't add tags to the dll, it is just that for one reason or other not all tags are in there to start with.
I assume you're asking me to provide you with a link, so here ya go:
http://forums.civfanatics.com/showpost.php?p=10631354&postcount=2817
Note that I found this searching in the ideas thread - so while this is a newer version (June 28th), it may not be the newest.
