<Update>

Riker13

King
Joined
Nov 9, 2001
Messages
853
Location
UK
Modders, in CiV there was this function <Update> which was used to quickly change the vanilla specs of things.

As an example and for arguments sake I wanted to change a Nukes cost from 300 to 600 and range from 20 to 30, I would write this.....
<Update>
<Set Cost="600" Range="30"/>
<Where Type="UNIT_NUCLEAR_MISSILE"/>
</Update>

Has anybody come across any function that can do this yet in Civ 6?

Regards

Riker13:crazyeye:
 
Ahh thanks, so as an example what would be the full code for my OP, not that I intend to change the Nuke but its just for my knowledge. :)

Sorry so are you saying Set cost and Range is the same?
 
Last edited:
You can do it in XML but IMO in the long term you're better off going with SQL. In my experience, XML is best reserved mainly for when creating entirely new units, civs, or leaders (and sometimes not even then). I could go into why, but it may be beyond the scope of your question. :) One of the bigger reasons though is SQLite is not proprietary like the XML structure is, so you can find many answers by reading any SQLite resource.

The SQL version of the code you posted would be:


Code:
UPDATE Units SET Cost=600, Range=30 WHERE UnitType='UNIT_NUCLEAR_MISSILE' ;
 
@isau
Thanks, yes SQL does seem to be the best choice but instead of UPDATE would it be Delete Type as UncilvilizedGuy suggested?
or are you saying UPDATE is available in Civ 6?
 
@isau
Thanks, yes SQL does seem to be the best choice but instead of UPDATE would it be Delete Type as UncilvilizedGuy suggested?
or are you saying UPDATE is available in Civ 6?


I think what UncivilizedGuy was saying is that you could use DELETE if you wanted to totally delete the unit and insert something similar in its place.

FWIW most of the various XML tags I know of are echoes of SQL.

UPDATE: Change a value
INSERT: Insert a new value
DELETE: Delete a record

So basically XML and SQL do the same thing. The thing is tho, SQL can take some of these things further in ways I'm not sure are possible in XML, or that at least would be very tricky. Since testing the mod often involves writing SQL anyway, I find SQL much easier to work with than XML. Again the possible exception is when creating totally new Units, Buildings, etc. But even there I tend to lean more toward SQL. I like that SQL makes it easy to add comments throughout the file, and that its basic structure makes the file generally more "readable." In particular once you start getting to Modifiers and Requirements I like how easy it is to keep related things together, versus XML where it is often more of a hassle.
 
Thanks for the information, I will go away and see if it can be done or more precise see if I can get it done ;)

All the best.
 
There is no change I have been able to see to the way <Update> worked in Civ5 as to the way it works in Civ6. The differences are really only in the column-names used by the tables, and you should be referring to the table-defintiions or at least the basegame files to determine whether (for example) the column is still called "Type" or is now called "UnitType" in table "Units".

There is no real advantage to using SQL except in that you can make your UPDATE statement conditional on something else that may or may not be in the database. Otherwise if your mod is always going to alter a column value in a specific table, there really is no superiority of SQL over XML

<Replace> also adds a new row into the game-table if there is no existing row within the table that matches for primary columns to the data in the <Replace> command. In SQL it is essentially the same command but I think most people use INSERT OR REPLACE INTO because just plain REPLACE in SQL is not supported apparently by all versions.

These updates all work fine but I haven't checked against the latest patch whether they've changed a bunch of stuff again on the type of cost progression model being used. Note that I'm also adding a couple new Yields to the Pagoda
Spoiler :
Code:
<GameInfo>
	<Districts>
		<Update>
			<Where CostProgressionModel="COST_PROGRESSION_NUM_UNDER_AVG_PLUS_TECH" CostProgressionParam1="25" />
			<Set CostProgressionModel="COST_PROGRESSION_GAME_PROGRESS" CostProgressionParam1="100" />
		</Update>
		<Update>
			<Where CostProgressionModel="COST_PROGRESSION_GAME_PROGRESS" CostProgressionParam1="1000" />
			<Set CostProgressionModel="COST_PROGRESSION_GAME_PROGRESS" CostProgressionParam1="100" />
		</Update>
		<Update>
			<Where DistrictType="DISTRICT_BATH" />
			<Set CostProgressionModel="COST_PROGRESSION_GAME_PROGRESS" CostProgressionParam1="50" Housing="4" Entertainment="2" />
		</Update>
		<Update>
			<Where DistrictType="DISTRICT_AQUEDUCT" />
			<Set CostProgressionModel="COST_PROGRESSION_GAME_PROGRESS" CostProgressionParam1="100" />
		</Update>
	</Districts>
	<Yields>
		<Update>
			<Set OccupiedCityChange="0" />
		</Update>
	</Yields>
	<GlobalParameters>
		<Update>
			<Where Name="SCIENCE_PERCENTAGE_YIELD_PER_POP" />
			<Set Value="25" />
		</Update>
	</GlobalParameters>
	<Buildings>
		<Update>
			<Where BuildingType="BUILDING_PAGODA" />
			<Set Housing="2" CitizenSlots="2" />
		</Update>
	</Buildings>
	<Building_YieldChanges>
		<Row BuildingType="BUILDING_PAGODA" YieldType="YIELD_FOOD" YieldChange="1"/>
		<Row BuildingType="BUILDING_PAGODA" YieldType="YIELD_PRODUCTION" YieldChange="1"/>
	</Building_YieldChanges>
	<ModifierArguments>
		<Update>
			<Where ModifierId="TITHE_GOLD_FOLLOWER_MODIFIER" Name="PerXItems" />
			<Set Value="3" />
		</Update>
		<Update>
			<Where ModifierId="RELIGIOUS_COMMUNITY_SHRINE_HOUSING_MODIFIER" Name="Amount" />
			<Set Value="2" />
		</Update>
		<Update>
			<Where ModifierId="RELIGIOUS_COMMUNITY_TEMPLE_HOUSING_MODIFIER" Name="Amount" />
			<Set Value="2" />
		</Update>
		<Update>
			<Where ModifierId="RELIGIOUS_SETTLEMENTS_CULTUREBORDER" Name="Amount" />
			<Set Value="25" />
		</Update>
	</ModifierArguments>
</GameInfo>
XML is superior to SQL in one respect: you get far more useful information in Database.log when your code has gone awry.
 
Thank you all guys, you have been most helpful, I am glad that the Update function is still around it will help with my own little mod.
And although I have been playing around with SQL and a bit of LAU I do admit to my sins I am still really only up to dealing with XML which as you say LeeS does help with the Database.log when I muck up somewhere. :)
 
Top Bottom