C2C - mass XML changes parser

Is there a way to decide which <UnitInfo> tag is main definition and which is redefinition of a unit? Except checking their lengths and taking longer as definition, of course?
Been thinking on this one and without adding another tag (which could be just an indicator that is included in the schema but has no load-in process in the dll as it would be entirely unnecessary there - probably a boolean would be easiest) I don't think there's any given tag that is reliable enough to set this 'primary key' definition on... I'd say whichever one defines the <Button> tag but even that COULD be subject to change by modular edit.



n47 said:
As I understand redefinitions in modules can modify objects from Assets/XML and from other modules? But what if in one module a value in some object is set to something and in other module it is set to something another? Which one will take action then?
Where you would have two re/over writes you'd find that the tags in the last loaded file in the modular loading sequence would take precedence.

n47 said:
Precisely, if in one module you would have
Code:
<UnitInfo>
			<Class>UNITCLASS_CAVE_LION</Class>
			<Type>UNIT_CAVE_LION</Type>
and in another
Code:
<UnitInfo>
			<Class>UNITCLASS_CAVE_CAT</Class>
			<Type>UNIT_CAVE_LION</Type>
which class will have Cave Lion?
Presuming the second one was the last to be loaded, the Cave Cat would have it.

n47 said:
@Thunderbrd, I think you should include files with redefinitions in your list. Take in consideration what will happen, if someone will set a bad value there. You will get some buggy behavior in the game and you will not know where to look for it. Maybe just add a column "Modifying Files" (or something more English :p) with coma separated lists of files, which modify the tag from File column?
True that I'd like this list to be an xml modder's help guide to rapidly find given units but it would be unnecessary for an edit planning document, which is what this basically is. I'd find it would muddy the waters for the purpose of design planning spreadsheeting.

Type tag has only unique values.

At least in files that i checked.
NOw my XML parser displays red * in unique column and Type looks always unique

EDIT
When compared Subdue_Animals_CIV4UnitInfos.xml and Civ4UnitInfos.xml type tag is not unique
there are two same values:
'UNIT_SCOUT'
'UNIT_GREAT_GENERAL'

Question is do we need to use this ability to redefine the same unit by type tag?
Now it is used very rare so it will be simple to fix it.
It's not so rare as you think. n47's list of inaccuracies derived above is a fairly close approximation of how often it takes place. The REASON for the necessity for this kind of modularization is better explained by DH but I can try. Basically it's so that if a module is introducing a new concept, units, promotions, etc can be updated to adapt to that concept without having to place such adaptations on the core definition. Therefore, if you then turn OFF the module, you won't have a bunch of references not finding their targets.

Take for example many of the worker Build actions. Say a module adds a new type of improvement. Then in that module we add further definition to our workers, adding the build type (action) that produces that new improvement, enabling our workers to now build said improvement. At that point, the worker is otherwise unchanged... only the new feature has been added.

If you turn off the module, not only does the improvement vanish from the assets but so does the worker build definitions.

But if you put those build definitions on the core worker definition on the main UnitInfos.xml, then turn off the improvement, the build lists will start throwing errors when it can't find the definition of that new improvement.

May be a poorly worded example but hopefully you follow.


I'd still keep the file paths on these planning docs though since it helps the planner immensely.

@ Both of you: It occurs to me that it should be painfully easy to flesh out the Era CCs... it would just take a query that would find the prereqtech's era and match it to the corresponding (which we'd have to probably add a tag for in UnitCombats) Era CC then fill it in for the unit on that list appropriately. Anyone want to see what can be done to make that process a bit faster? Even generating a list for the units where the era can be copied into the google doc would be extremely helpful.
 
True that I'd like this list to be an xml modder's help guide to rapidly find given units but it would be unnecessary for an edit planning document, which is what this basically is. I'd find it would muddy the waters for the purpose of design planning spreadsheeting.
Aren't you a modder and isn't it, some values which you care about can be changed in those files?

Where you would have two re/over writes you'd find that the tags in the last loaded file in the modular loading sequence would take precedence.

which class will have Cave Lion?
Presuming the second one was the last to be loaded, the Cave Cat would have it.
There should be no such races. It tastes like a bad design.

@ Both of you: It occurs to me that it should be painfully easy to flesh out the Era CCs... it would just take a query that would find the prereqtech's era and match it to the corresponding (which we'd have to probably add a tag for in UnitCombats) Era CC then fill it in for the unit on that list appropriately. Anyone want to see what can be done to make that process a bit faster? Even generating a list for the units where the era can be copied into the google doc would be extremely helpful.
Do you mean checking in which era a unit appears? This should be two queries, so it is very very complex. I don't think, I can do it. I believe master Nimek will need to take care about this. :bowdown:
 
Aren't you a modder and isn't it, some values which you care about can be changed in those files?
Generally it would be rare for a modder to need to change anything in the modular edits as those are usually just for updating units to be capable of working with whatever the module introduces. Furthermore, in the planning process these documents are designed for, it's only a small portion of the unit tags that are under evaluation. In THIS particular case, only the CCs are under evaluation. It would lead to a lot of blank unit entry rows on the document that would look like I missed something if all the unit edit files are listed out.


There should be no such races. It tastes like a bad design.
I didn't setup WoC modularization but when you think about it, any such modular editing method has a few choices to make about how a change is prioritized and none of those choices are perfect. Can't really blame the designers for choosing this method - it's functional if understood.


Do you mean checking in which era a unit appears? This should be two queries, so it is very very complex. I don't think, I can do it. I believe master Nimek will need to take care about this. :bowdown:
I'm not sure but are you being sarcastic? You realize sarcasm doesn't translate too well in type without a person being able to hear your tone of voice right?

Actually - I realized this would be quite easy to create an era reference on units in the code and have it displayed in the pedia (as a handicap when setting this up anyhow.) So if this sounds like a bit of a pain I do have an alternative solution.
 
It would lead to a lot of blank unit entry rows on the document that would look like I missed something if all the unit edit files are listed out.
:wallbash: Thunddie, cooolumn, column. Not to put it in special rows, but a column. Like at the picture. Or you can hide or put his column at the end if it would disturb you. This is what I meant.

I didn't setup WoC modularization but when you think about it, any such modular editing method has a few choices to make about how a change is prioritized and none of those choices are perfect. Can't really blame the designers for choosing this method - it's functional if understood.
It is not my personal opinion. Such point of view is the one given by software engineering rules of proper programming. There should be some well defined hierarchy here. I am not going to describe it technically, because we will end up like with those empty rows. But it should be done in other way.

I'm not sure but are you being sarcastic? You realize sarcasm doesn't translate too well in type without a person being able to hear your tone of voice right?
Wouldn't it be insane, knowing my relations with Nimek, to take it not as sarcasm? Take some intuitions about what you are reading. How do you read books with such attitude? There is no comment after each sentence said by a character, which explains what he means or what is his attitude.

Actually - I realized this would be quite easy to create an era reference on units in the code and have it displayed in the pedia (as a handicap when setting this up anyhow.) So if this sounds like a bit of a pain I do have an alternative solution.
No, it doesn't. But be specific. In what code? If you want to civlopedia show the era of a unit, it should be done rather at the level of civilopedia code, not in XMLs. But at first I thought, you want to generate entries for your Google Docs.
 

Attachments

  • new_col_thund.jpg
    new_col_thund.jpg
    284.6 KB · Views: 68
@TB

In game code solution will be better because xml tag is static. We often redesign tech tree move units etc so that kind of xml tag can be outdated very quickly.

@n47
Do you have some kind of obsession on my point?
If so. Please go to doctor. Iam worry about you.
 
Why would I? I was looking CIA's Unfortunate accidents price-list just out of curiosity. :p

If you are going to use sarcasm put /s at the end of the sentence.

Example:

Dogs are better than cats. /s
 
I should point out that it is not unusual for when working with WoC modular XML to have tow or more modules of XML that all update the core unit (or whatever).

firstly in WoC the unique id for units is both Class and Type. The example given in
Precisely, if in one module you would have
Code:
<UnitInfo>
			<Class>UNITCLASS_CAVE_LION</Class>
			<Type>UNIT_CAVE_LION</Type>
and in another
Code:
<UnitInfo>
			<Class>UNITCLASS_CAVE_CAT</Class>
			<Type>UNIT_CAVE_LION</Type>
which class will have Cave Lion?
These are two separate definitions and probably will not work because will not work because the Type field is supposed to be unique I think.

On the other hand
Code:
<UnitInfo>
			<Class>UNITCLASS_CAVE_LION</Class>
			<Type>UNIT_CAVE_LION</Type>
and
Code:
<UnitInfo>
			<Class>UNITCLASS_CAVE_LION</Class>
			<Type>UNIT_CAVE_CAT</Type>
will work because you are defining a special type of cave lion in the second.



What you will have is something like
Code:
<UnitInfo>
			<Class>UNITCLASS_CAVE_LION</Class>
			<Type>UNIT_CAVE_LION</Type>
			full definition here
and in another
Code:
<UnitInfo>
			<Class>UNITCLASS_CAVE_LION</Class>
			<Type>UNIT_CAVE_LION</Type>
			changes to one or more values here (none reset to default values)
<UnitInfo>
and then in another
Code:
<UnitInfo>
			<Class>UNITCLASS_CAVE_LION</Class>
			<Type>UNIT_CAVE_LION</Type>
			changes to one or more values here (none reset to default values)
<UnitInfo>
They may change the same items/tags but the final result is a single definition with the updates applied in the order loaded.

Note: WoC does not allow you to reset a value to the default value in this way you need to provide a whole new definition in your module with the force override tag set.
 
n47 said:
Thunddie, cooolumn, column. Not to put it in special rows, but a column. Like at the picture. Or you can hide or put his column at the end if it would disturb you. This is what I meant.
Hmm... ok, that might work yes. I'd not considered that approach considering there's no limit to the number of potential edit entries and each would then need its own column but that wouldn't be too troublesome unless such entries really began to amass far more than they have to date.

No, it doesn't. But be specific. In what code? If you want to civlopedia show the era of a unit, it should be done rather at the level of civilopedia code, not in XMLs. But at first I thought, you want to generate entries for your Google Docs.
I do. If I put this in the civilopedia (which is my patch concept but I'd only do so during the running of a debug dll) then I'd still just use that as reference to go through and assign the era unitcombat definitions on each unit which ultimately is the point I'm trying to get at here.

Nimek said:
In game code solution will be better because xml tag is static. We often redesign tech tree move units etc so that kind of xml tag can be outdated very quickly.
I considered this BUT to properly include it in the unit's list of unitcombats makes that extremely tricky if you want that CC to show up on the BASE unit definition (such as you see when looking at the build lists in the city screen or at the unit definition in the pedia.) Not hard at all to attach it to a unit once the unit is built but I'd rather have it show on the base definition rather than having it limited to units that have manifested in the game itself.

@DH: I'm not sure of this but I THINK Class is actually subservient to <Type>. I was wondering about the points you were making there but I'm not sure it's accurate. Can't say for sure without more research into the matter though. I know it doesn't appear to make sense at first. This doesn't mean that a unit can have two defined classes though... one would override the other. But the primary key of a unit definition is it's Type. You cannot have two units with the same type name but you can have two units under a given unit class.
 
I do. If I put this in the civilopedia (which is my patch concept but I'd only do so during the running of a debug dll) then I'd still just use that as reference to go through and assign the era unitcombat definitions on each unit which ultimately is the point I'm trying to get at here.

I considered this BUT to properly include it in the unit's list of unitcombats makes that extremely tricky if you want that CC to show up on the BASE unit definition (such as you see when looking at the build lists in the city screen or at the unit definition in the pedia.) Not hard at all to attach it to a unit once the unit is built but I'd rather have it show on the base definition rather than having it limited to units that have manifested in the game itself.
It is maybe my poor English, but I can't see what you exactly need this era information for.
Either way Nimek is right. You rather should not put redundant data into database (our XMLs are our database), if you do not have really good reason. You already have the data about eras of units in XMLs. It is achieved by taking required techs identifiers and joining them with data of the techs' eras. Thus you should rather add a function in dll which will provide the era info of a unit, then add a redundant tag. Such function is easy.

Buuut wait. Are you trying to give some parameters to units based on their eras?
 
@Dancing Hoskuld, ok, it sounds reasonable. But are you sure about it? -- I mean, ID = (Class, Type) . -- I would like to have consistent data.
 
It is maybe my poor English, but I can't see what you exactly need this era information for.
Either way Nimek is right. You rather should not put redundant data into database (our XMLs are our database), if you do not have really good reason. You already have the data about eras of units in XMLs. It is achieved by taking required techs identifiers and joining them with data of the techs' eras. Thus you should rather add a function in dll which will provide the era info of a unit, then add a redundant tag. Such function is easy.

Buuut wait. Are you trying to give some parameters to units based on their eras?

Ah clever one... You must understand that CCs have a LOT of utility throughout our pre-existing modding tools. And yes - I do intend to eventually work in promotion factors that apply to and against units of particular eras. The easiest way to do this is to establish an Era CC for each unit. This is useful for equipments but it's also a major key in a project mentioned many months ago about units developing means to combat more advanced technologies via specially accessed promotions made available once said advanced units are encountered. I also like to pave the way for imagination to key in to potential. Additionally, it plays in to later Developing Leader plans I have in mind.

It's also nice to see the era on the unit in the pedia... this isn't the easiest way to make that happen nor the cheapest but it comes with wider potential utility without having to plan for a number of new tags and added code.
 
@Thunderbrd, and what if you will add another era by splitting existing one or resign from one era and merge it with another, or shift some technologies from one era to another? Are you planning to correct all related units? And I can't see why would some units promotion factors would depend on eras. They can depend on their equipment, training, tactics. But on something so abstract like an era? It doesn't look reasonable. Can you bring some real-world example?

This is useful for equipments
Isn't equipment based on techs and resources, not on eras?

but it's also a major key in a project mentioned many months ago about units developing means to combat more advanced technologies via specially accessed promotions made available once said advanced units are encountered.
Ok, I see this. But there is no need for an additional era tag in UnitInfo-s for this.

It's also nice to see the era on the unit in the pedia...
This can also be done without this tag.

but it comes with wider potential utility without having to plan for a number of new tags and added code
Again, there is no need for any new tags. There is only need for a small piece of code.

Say me how have you planed to add this era info into civilopedia? It is not enough to put a new tag into XML, I believe. It doesn't just print any tag you put there.
 
NEw upadate

  • Add ability to add tags inline (green + sign)
  • add full support for bollean type of tags (now appears as checkboxes)
  • All inline editing fields even strong nested supports autocomplete now

Above functions needs to be polished. For example sometimes you must refresh to see checkboxes in boolean fields.

Entire UI design that I plan has one goal. Make XML editing as simple as possible.

Next i plan to add manual adding nested tags to existing tags/columns.

@TB
It is very simple code in dll to check unit era. You simply take prereq tech from unit object and checks that techs era in tech object. Simple and fast. I hope that dll code supportd objects ;)
 
It is very simple code in dll to check unit era. You simply take prereq tech from unit object and checks that techs era in tech object. Simple and fast. I hope that dll code supportd objects ;)
I believe there can be more, then one prerequired tech. But more or less it should be done like this. -- Remember you will also need some code, which can make use of this function.
 
I believe there can be more, then one prerequired tech

Than simple loop throght array of prerequired techs and checks what is the newest (xTech tag?)
and chec era for it.

I belive that someone put a lot of effort to remove redundant prereq techs so all should be in same era in most cases.
 
Ok so I realize I can easily display and establish the unit's era on the unit. But what I cannot as easily do is establish that as a Combat Class.

Combat Classes can be designators that can qualify or disqualify promotions and equipments, can be qualifiers or disqualifiers for combat modifiers, and many more subtle game functions.

Without adding era considerations such as eraprereq tags, eracombatmodifier tags etc into every place where combat classes can be useful, it's much easier to enforce that units gain a combat class that represents their era.

For example: +10% vs Ancient Era Units becomes a use of a pre-existing CC tag for combat modifiers vs a particular CC rather than having to make a new tag for combat modifier vs a unit's era definition.

Another example: Say you want to have a particular piece of equipment unavailable to units of a particular era but not completely obsolete for the earlier units that simply haven't been upgraded yet. Again - easily done with an era CC - takes added coding to the prerequisites segment in the dll if it operates off of the unit's direct era definition.

That said, I could probably add the unit's era to the base unit definition easily enough, and then when the unit is built auto-assign the era combat class during the unit's init process.

Unfortunately, this means that the subcombat class the unit will get won't show alongside all the rest of the CCs in the pedia - not that big a deal I guess when you compare to the potential headache you mention about rewriting all those CCs on all units affected by a major era structure adjustment. You make a good point there but I was kinda figuring we'd already determined we weren't going to be adjusting eras - though it occurs to me it could end up being a kindness to modders of c2c modmods.
 
@Nimek

So I was trying your program out and searched for Balloons. What came up were ...

UNIT_AIRSHIP
UNIT_BALLOON
UNIT_BARRAGE_BALLOON
UNIT_BLIMP

However I know there are a few more not listed ...

- Zephyr (Clockpunk)
- Cloud Destroyer (Steampunk)
- Goliath Airship (Dieselpunk)

These are all under the Alt-Timeline mod. So how do you get them to show up?
 
I have a challenge.

In BuildingInfos

<FreeStartEra>NONE</FreeStartEra>
<MaxStartEra>NONE</MaxStartEra>
<ObsoleteTech>TECH_CONSUMERISM</ObsoleteTech>
<PrereqTech>TECH_COOPERATION</PrereqTech>

This is a Prehistoric Building that requires Consumerism.
Would it be possible for this buiding to be autofilled have FreeStartEra be ANCIENT.

This would be based on the ERA of the PrereqTech

Prehistoric Buidings will have FreeStartEra be ANCIENT
Ancient Buildings will have it be CLASSICAL
Classical Buildings will have MEDIEVAL
and so on.

The code would be:

See PrereqTech in BuildInfos

Find Tech in TechInfos
Find <Era></Era> in Techinfos

Make a trigger rename list.

If TECH is PREHISTORIC put ANCIENT inside <PrereqTech><PrereqTech> of said building.

If TECH is ANCIENT put CLASSICAL inside <PrereqTech><PrereqTech> of said building.

Then we modders can edit select buildings to have NONE instead but the majority will be autofilled in.

This will allow us to really start at any Era.
 
Back
Top Bottom