[Vanilla] Mod prevents unit upgrades, (coding problem?)

Joined
Jan 10, 2019
Messages
1,825
Almost there. I amost complete a release version of my first mod. Now with startup problems sovled, new and nasty ones came in place

My mod prevents unit upgrades despite that it should work in normal game!
upload_2019-12-30_12-7-15.png

Look! No upgrade buttons show up regardless that the conditions to upgrade this unit is met.
I've played this in Vanilla game with 'Gold Editions' (RF and previous DLCs installed, bought on STEAM and i'm sure i legally installed it). in regular sitations (no mods) upgrade buttons should appear since slinger is upgradeable to archer (and i did not mess with this line AT ALL). Actually in previous versions, unit upgradings works fine before :p )

Gameplay codes and Database log are given below. I guess i've messed up unit upgrading lineage or something (possibly re-assigning Redcoats into anti-cavalry ) but the log doesn't inform me of any errors AT ALL. (it might have been fixed or whatsover). or is the latest patch tried to compelled players to buy and install GS similar way Firaxis bugged unit combinations to Corps command when RF was released? if not. then what are problematic codes?

EDIT: Here, My mod + Assets https://drive.google.com/open?id=1yoIlqfi6ymJwCnzUtx_KZVJ3XqlcGKBf (or 'raw' mod, hit 'download' button)
 

Attachments

  • VanillaZaab_GameplayXML_n_DB.rar
    4.8 KB · Views: 120
Last edited:
In general learning to mod Civ6 is a higher 'grab' than for Civ5.
  • Civ6 offers far more direct-access to basic systems through Database Modding than Civ5, but at the price of a more-complicated set of game mechanics that must be manipulated via database methods. This intensifies confusion and disappointment for the Novice Modder when they find it is not nearly so easy to change something as they expected because often a simple alteration in one part of the database requires "matching" alterations in other parts of the database. The Dynamic Modifiers and Dynamic Game Effects systems inherent in Civ6 are an incredulously powerful tool for direct SQL or XML coding (no DLL or lua experience needed !), but they are also not terribly easy to master in my opinion.
.

Particularly when manupulating units by switching classed into ones that's considered more appropriate like when I want to change ENGLISH_REDCOAT from generic Melee into Anti-Cavalry class so to be more compatible with my Rifleman (also Anticavs). it turned out that (I suspected) it prevents unit upgrading mechanics entirely..... i'm making Vanilla mod now and wrestling with this problems.
Do I need SQL coding as well?
 
No. Both SQL and XML are sent to the same database.

The difference is that SQL can allow you to make more complex database alterations such as pulling from an existing row in the database to add part of that row's data into an entirely new row. But other than this sort of capability there is no "magic" to using SQL rather than XML.

These two bits of code are equivalent:

XML:
Code:
<GameData>
	<Units>
		<Update>
			<Where UnitType="UNIT_SETTLER" />
			<Set BaseMoves="4" />
		</Update>
	</Units>
</GameData>

SQL:
Code:
UPDATE Units WHERE UnitType='UNIT_SETTLER' SET BaseMoves=4;
The effect on the game's database will be the same regardless of which of the two code-languages you opt to use.
 
^ So to change Redcoat class to compatible with new upgrade lineage and to prevent 'unit upgrade disabling' bug which i'm suffering right now. Do I still need to alter <TypeTags> in addition to <Units><Update> and <UnitUpgrade> too?
Default type tags. Do I need SQL files to do this as well?

Redcoats class as seen in default Units.XML
Code:
<TypeTags>
........
       <Row Type="UNIT_ENGLISH_REDCOAT" Tag="CLASS_MELEE"/>
.......
</TypeTags>

Do I still have to do this too in ModUnitGameplay.XML ?
Code:
<TypeTags>
........
       <Update>
       <Where Type="UNIT_ENGLISH_REDCOAT" /><Set Tag="CLASS_MELEE"/>
       </Update>
.......
</TypeTags>
or what else has to be done to make it work and no such 'no unit upgrade' bug incurred?
 
You'd be better off posting these sorts of questions on a stand-alone thread since we're kind of hijacking the intent of this thread. You would need to zip and attach the entire mod or provide a link where it can be downloaded rather than posting isolated component-chunks of it.

But the quick and easy answer to your SQL question is that SQL is never needed over and above XML when all you are doing in XML is <Row>, <Update>, <Replace>, or <Delete>.
 
You'd be better off posting these sorts of questions on a stand-alone thread since we're kind of hijacking the intent of this thread.
Moderator Action: yes, posts moved
 
Code:
<Update>
	<Row Unit="UNIT_AMERICAN_ROUGH_RIDER"/>
	<Set UpgradeUnit="UNIT_TANK"/>	
</Update>
Since <Row> cannot be contained within a set of <Update> commands (and vice versa) the game ignores this part
Code:
<Row Unit="UNIT_AMERICAN_ROUGH_RIDER"/>
It executes the Update as if it had been written
Code:
<Update>
	<Set UpgradeUnit="UNIT_TANK"/>	
</Update>
This is in fact acceptable code and logic for an Update command. The result however is not what you desire because it literally updates every existing row within table UnitUpgrades to make the units all want to upgrade to UNIT_TANK. Rows that are added to the table after your code executes are not affected so there seems to be some DLC units that are working correctly and other units that are not. All are actually working correctly. The Civilopedia pages reflect the effects of the mis-formed code on unit upgrades. DLC that loads after your mod is not affected by the error in your code. If you want to make sure your mod executes after all the Vanilla DLC have loaded, you will need to add a LoadOrder setting to your action in Modbuddy -- a LoadOerder value of 200 or 300 should suffice to ensure your mod loads its code after the DLC have loaded into the game.
 
0. Is the aforemented code prevented unit upgrades to be done as I said before about slingers -> archers
1. Tell me more about 'Load Order' setting. If the aforemented DLC did not installed nor activated, what will this thing do? just skip the whole thing
2. And about class switching. in case of Redcoats. what are the correct codes to switch from MELEE to ANTI_CAVALRY on bont <Units> and <TypeTags> ?
 
0 -- yes, because it makes everything want to upgrade to the Tank unit. So the button to upgrade does not even show as an option until you've discovered the tech for the Tank Unit, and you have the needed Oil.
1 -- LoadOrder is a setting within your mod to specify relative order in which your action should be conducted in relation to other mods with a lower setting of LoadOrder. With no specific LoadOrder setting provided, the game uses a default setting of '0'. There's quite a bit of documentation available on the forum in various threads on how to add a LoadOrder setting, as well as explanation on how to do so in the Modding Guide I've created.
2 -- It looked like you had essentially the correct code within table TypeTags to alter the classs setting from Melee to Anti-Cavalry. But you also need to alter the definition in Units to use PromotionClass="PROMOTION_CLASS_ANTI_CAVALRY"
 
As a Custom Property of the action. See the chapter called "Dependancies, References, Load Orders, Blocks" in the Modding Guide I have created. Click on the link in my signature called "LeeS' Civilization 6 Modding Guide". It will take you to a dropbox where you can download the pdf of the Modding Guide as it currently is. I show step-by-step instruction on what to click on in Modbuddy to setup a Load Order setting for an action.
 
Top Bottom