XML

dartmor

Chieftain
Joined
Oct 23, 2010
Messages
55
Location
Russia
I am trying for some time to run few simple XML changes, but they don't want to work.

1. I want to change the amount of defense generated by fortified unit. I did:

Code:
<GameData>
	<Define>
		<Row Name="FORTIFY_MODIFIER_PER_TURN">
			<Value>3</Value>
		</Row>
		<Row Name="MAX_FORTIFY_TURNS">
			<Value>10</Value>
		</Row>
	</Define>
</GameData>

But i wasn't sure it's right, so i have second script with:
Code:
<GameData>
	<Define>
		<Update>
			<Set Value="3"/>
			<Where Type="FORTIFY_MODIFIER_PER_TURN"/>
		</Update>
		<Update>
			<Set Value="10"/>
			<Where Type="MAX_FORTIFY_TURNS"/>
		</Update>
	</Define>
</GameData>

Both set to "Import to VFS" and are on Action ( OnModActivated > UpdateDatabase ). And i've tried to change <Where Type...> to <Where Name...>, don't help.

So the problem is in script itself. What i did wrong?

Also, i want to allow EVERY policy to lower unhappiness. For example, I've tried:

Code:
<GameData>
	<Policies>
		<Row>
			<ID>0</ID>
			<Type>POLICY_LIBERTY</Type>
			<Description>TXT_KEY_POLICY_BRANCH_LIBERTY</Description>
			<Civilopedia>TXT_KEY_CIV5_POLICY_LIBERTY_TEXT</Civilopedia>
			<Help>TXT_KEY_POLICY_LIBERTY_HELP</Help>
			<CulturePerCity>1</CulturePerCity>
			[B]<UnhappinessMod>50</UnhappinessMod>[/B]
			<PortraitIndex>24</PortraitIndex>
			<IconAtlas>POLICY_ATLAS</IconAtlas>
			<IconAtlasAchieved>POLICY_A_ATLAS</IconAtlasAchieved>
		</Row>
	</Policies>
</GameData>

But that doesn't work. I also tried using <Update>.

That's not all. I also need to improve the amount unit deals if he attack first. So that the first unit who attacks receive attack bonus. I can add promotion that grants attack bonus, to every unit, but it will be some work. Maybe there is simplier way?
 
The second XML file is the one you would want (with Name instead of Type), but you don't need to set it to "Import to VFS". Also, you have the wrong table name; you're using Define instead of Defines. I'm actually not sure if this matters, but the order of the tags might be important; you have Set before Where on each of those updates. Again, I've never tested that, so it might not actually be necessary. My personal preference is to use SQL for updates. If you want to use that instead, put the below into a new SQL file and add the OnModActivated > UpdateDatabase Action just like the XML (does not need to be imported into VFS).

Code:
UPDATE Defines SET Value=3 WHERE Name="FORTIFY_MODIFIER_PER_TURN";
UPDATE Defines SET Value=10 WHERE Name="MAX_FORTIFY_TURNS";

As far as the UnhappinessMod setting, the only thing I can see is that you have it set to a positive number; it needs to be a negative number.

I'm not sure how you would go about doing your last issue. Sorry.
 
Whether you put <Set Blah="1"/> above <Where Blah="Something"/> is immaterial. Works both ways. But the names of tables needs to be exact. If you enable logging whoward69's enable error logging tutorial you should see errors being reported in the Database.log when you have an incorrect table or column name.

----------------------------------------------------------------------------------------------

If your code sample of the policy-change attempt is an exact duplication of what you tried, then that is the problem. For primary game-tables, the game will reject and discard any file where there is a <Row> repeating information for a <Row> it already has. Any game-table that has an <ID> column is a primary table and will follow this rule. Any game-table that has a <Type> column is generally also a primary table and will follow this rule. <Language_en_US> and the other localization language tables are their own special-snowflake-system and also adhere to this rule, but only where there is a repeat of an existing Tag="TXT_KEY_SOMETHING" when that repeat is contained within a <Row> wrapper.

What do I mean by all this?

<Type>POLICY_LIBERTY</Type> and <ID>0</ID> already exists within a <Row> within the <Policies> table, so a repeat occuance of a <Row> with that <Type> or <ID> designation will be rejected by the game, taking the entire file with it as part of that rejected code.

------------------------------------------------------------------------------------------------

As a general rule it is also never a good idea to include <ID> within the code of a mod. There are specific exceptions to this general rule, but I don't believe they apply to your mod.

-------------------------------------------------------------------------------------------------

SQL has its own rules for what gets reported as an error in the Database.log. It often rejects an entire file without giving much of a usable error-message.

-------------------------------------------------------------------------------------------------

Also, as noted, not every column (or command if you like) in the XML accepts negative numbers, and not every column accepts positive numbers. It all depends on what Firaxis chose to impliment in the game's core files (usually the game's dll files): if they had no need for it to achieve an effect, it is a coin-toss dice-roll as to whether they bothered to code-in for all possible cases or if they essentially hard-coded only to accept negative numbers or only to accept positive numbers. Nor can you assume that a column named "Haberdashery" in one game table will work the same if it is also included as a valid column-name in another game table. Each is their own special case.

"Accept" in this sense means "does anything with it". You will not get code-fail errors or file-discards because of these refusals to do anything with the values you enter.
 
Whether you put <Set Blah="1"/> above <Where Blah="Something"/> is immaterial. Works both ways.

That's what I figured, but I never use XML to update so I couldn't be sure. I could envision someone writing the XML parser to enforce the order, especially if they were writing it quickly just to get something implemented and never went back to refactor it.
 
Back
Top Bottom