Unit Not Being Recognized By the Game

[Androrc the Orc]

In my mod I have a unit called the Desert Swordsman. It used to work fine, but for some reason it is no longer being recognized by the game. Here are the contents of the (My Mod's Folder)/Units/Desert Swordsman/DesertSwordsman.xml:

<?xml version="1.0" encoding="utf-8"?>
<!-- Created by ModBuddy on 2012-02-12 2:29:20 PM -->
<GameData>
	<UnitClasses>
		<Row>
			<Type>UNITCLASS_DESERT_SWORDSMAN</Type>
			<Description>TXT_KEY_UNIT_DESERT_SWORDSMAN</Description>
			<DefaultUnit>UNIT_DESERT_SWORDSMAN</DefaultUnit>
		</Row>
	</UnitClasses>
	<Units>
		<Row>
			<Class>UNITCLASS_DESERT_SWORDSMAN</Class>
			<Type>UNIT_DESERT_SWORDSMAN</Type>
			<Combat>11</Combat>
			<Cost>75</Cost>
			<Moves>2</Moves>
			<HurryCostModifier>20</HurryCostModifier>
			<CombatClass>UNITCOMBAT_MELEE</CombatClass>
			<Domain>DOMAIN_LAND</Domain>
			<DefaultUnitAI>UNITAI_ATTACK</DefaultUnitAI>
			<Description>TXT_KEY_UNIT_DESERT_SWORDSMAN</Description>
			<Civilopedia>TXT_KEY_UNIT_DESERT_SWORDSMAN_PEDIA</Civilopedia>
			<Strategy>TXT_KEY_UNIT_DESERT_SWORDSMAN_STRATEGY</Strategy>
			<Help>TXT_KEY_UNIT_DESERT_SWORDSMAN_HELP</Help>
			<MilitarySupport>true</MilitarySupport>
			<MilitaryProduction>true</MilitaryProduction>
			<Pillage>true</Pillage>
			<ObsoleteTech>TECH_GUNPOWDER</ObsoleteTech>
			<GoodyHutUpgradeUnitClass>UNITCLASS_LONGSWORDSMAN</GoodyHutUpgradeUnitClass>
			<AdvancedStartCost>20</AdvancedStartCost>
			<XPValueAttack>3</XPValueAttack>
			<XPValueDefense>3</XPValueDefense>
			<Conscription>1</Conscription>
			<UnitArtInfo>ART_DEF_UNIT_ARABIC_SWORDSMAN</UnitArtInfo>
			<UnitFlagAtlas>UNIT_FLAG_ATLAS</UnitFlagAtlas>
			<UnitFlagIconOffset>14</UnitFlagIconOffset>
			<IconAtlas>AGE_OF_EVOLUTION_UNIT_ATLAS</IconAtlas>
			<PortraitIndex>1</PortraitIndex>
			<MoveRate>HEAVY_BIPED</MoveRate>
		</Row>
	</Units>
	<Unit_AITypes>
		<Row>
			<UnitType>UNIT_DESERT_SWORDSMAN</UnitType>
			<UnitAIType>UNITAI_ATTACK</UnitAIType>
		</Row>
		<Row>
			<UnitType>UNIT_DESERT_SWORDSMAN</UnitType>
			<UnitAIType>UNITAI_DEFENSE</UnitAIType>
		</Row>
	</Unit_AITypes>
	<Unit_ClassUpgrades>
		<Row>
			<UnitType>UNIT_DESERT_SWORDSMAN</UnitType>
			<UnitClassType>UNITCLASS_LONGSWORDSMAN</UnitClassType>
		</Row>
	</Unit_ClassUpgrades>
	<Unit_Flavors>
		<Row>
			<UnitType>UNIT_DESERT_SWORDSMAN</UnitType>
			<FlavorType>FLAVOR_OFFENSE</FlavorType>
			<Flavor>6</Flavor>
		</Row>
		<Row>
			<UnitType>UNIT_DESERT_SWORDSMAN</UnitType>
			<FlavorType>FLAVOR_DEFENSE</FlavorType>
			<Flavor>6</Flavor>
		</Row>
	</Unit_Flavors>
	<Unit_ResourceQuantityRequirements>
		<Row>
			<UnitType>UNIT_DESERT_SWORDSMAN</UnitType>
			<ResourceType>RESOURCE_IRON</ResourceType>
		</Row>
	</Unit_ResourceQuantityRequirements>
	<Unit_FreePromotions>
		<Row>
			<UnitType>UNIT_DESERT_SWORDSMAN</UnitType>
			<PromotionType>PROMOTION_COVER_1</PromotionType>
		</Row>
	</Unit_FreePromotions>
	<Language_en_US>
		<Row Tag="TXT_KEY_UNIT_DESERT_SWORDSMAN">
			<Text>Desert Swordsman</Text>
		</Row>
		<Row Tag="TXT_KEY_UNIT_DESERT_SWORDSMAN_PEDIA">
			<Text>First appearing during the Bronze Age, the earliest swords were little more than extra-large daggers. It wasn't until the development of iron forging (in approximately 1200 BC in Europe) that swords became viable combat weapons. The earliest swords were short and sharp, designed primarily for stabbing. Further advances in iron-work allowed bigger swords, and by the Middle Ages monstrously-long and heavy two-handed swords could cleave through all but the toughest armor.</Text>
		</Row>
		<Row Tag="TXT_KEY_UNIT_DESERT_SWORDSMAN_HELP">
			<Text>Strong, front-line land unit that starts with the Cover I promotion. Unlocked by the Pyramids.</Text></Text>
		</Row>
		<Row Tag="TXT_KEY_UNIT_DESERT_SWORDSMAN_STRATEGY">
			<Text>The Desert Swordsman is one of the most powerful standard melee units the Egyptians can have during the Ancient Era, being stronger than either the Spearman or the Warrior. They are very useful when attacking early-era cities. They receive the Cover I promotion automatically, making them particularly well-suited for combat against ranged units.</Text>
		</Row>
	</Language_en_US>
</GameData>

I don't remember doing any changes to how it was when I tested it and it worked fine, except for creating it's own unit class (previously it was a unit assigned to the UNITCLASS_SWORDSMAN unit class).

Any idea on why it isn't being recognized by the game?

 

[Spatzimaus]

I'm assuming that you've already checked your logfiles to see if they report a problem; pure XML errors almost always show up in either the Database.log or xml.log files. Beyond that, here are a few things:

1> If you think the only change made since the last time it worked was the unit class, then try changing that back to see if it fixes the problem. Chances are it won't, but it's worth a shot.

2> This unit doesn't have a technology prerequisite. Not going to break anything in the game, obviously, but I'm just saying...

3> TXT_KEY_UNIT_DESERT_SWORDSMAN_HELP has two </Text> tags at the end of it. That's probably where it's failing, but there could be other places as well, so fix that and then check again.

 

[Androrc the Orc]

I'm assuming that you've already checked your logfiles to see if they report a problem; pure XML errors almost always show up in either the Database.log or xml.log files. Beyond that, here are a few things:

1> If you think the only change made since the last time it worked was the unit class, then try changing that back to see if it fixes the problem. Chances are it won't, but it's worth a shot.

2> This unit doesn't have a technology prerequisite. Not going to break anything in the game, obviously, but I'm just saying...

3> TXT_KEY_UNIT_DESERT_SWORDSMAN_HELP has two </Text> tags at the end of it. That's probably where it's failing, but there could be other places as well, so fix that and then check again.

Thank you very much! 3. was indeed the problem

About 2., that was done intentionally (the unit is unlocked through Lua by a wonder).

 

[Spatzimaus]

About 2., that was done intentionally (the unit is unlocked through Lua by a wonder).

You want to be really careful with this. Take it from me; this sort of thing can cause all sorts of problems you aren't expecting. For instance, without a tech prerequisite, you won't be able to stop a city-state from gifting this unit to its allies. The UnitClassOverrides table only affects what units a civ can build normally (or spawn from camps, in the case of Barbarians); gifted units use an entirely different set of logic. Similarly, the various CanTrain gameevents can be used to stop certain civs from building certain units, but won't affect the gift process from what I can tell.
No building or project prerequisites will affect this process, but tech prereqs can. I haven't fixed this in my own Mythology mod yet, and it looks like I'm going to have to just use a Kill command in my OnUnitCreated function to remove the erroneous unit and replace it with something more acceptable. It's also possible that I can get around this by removing the flag that makes these units count as "military", but that has a few other effects, like stacking with workers, that I'd prefer not to screw up.

Anyway, just watch out for this. It shouldn't be too bad in your case, since it's an ancient-era unit and you're just getting it a few turns ahead of the normal swordsman; it's a lot worse in mine, where you might get a Dragon or something in the ancient.

 

[Androrc the Orc]

You want to be really careful with this. Take it from me; this sort of thing can cause all sorts of problems you aren't expecting. For instance, without a tech prerequisite, you won't be able to stop a city-state from gifting this unit to its allies. The UnitClassOverrides table only affects what units a civ can build normally (or spawn from camps, in the case of Barbarians); gifted units use an entirely different set of logic. Similarly, the various CanTrain gameevents can be used to stop certain civs from building certain units, but won't affect the gift process from what I can tell.
No building or project prerequisites will affect this process, but tech prereqs can. I haven't fixed this in my own Mythology mod yet, and it looks like I'm going to have to just use a Kill command in my OnUnitCreated function to remove the erroneous unit and replace it with something more acceptable. It's also possible that I can get around this by removing the flag that makes these units count as "military", but that has a few other effects, like stacking with workers, that I'd prefer not to screw up.

Anyway, just watch out for this. It shouldn't be too bad in your case, since it's an ancient-era unit and you're just getting it a few turns ahead of the normal swordsman; it's a lot worse in mine, where you might get a Dragon or something in the ancient.

That is important to know; do you know if resources matter in regards to the gifting of units? This desert swordsman still requires iron, so if resources matter, then it shouldn't be a problem.

 

[Spatzimaus]

That is important to know; do you know if resources matter in regards to the gifting of units?

Not that I've ever seen. I'm pretty sure city-states can gift units that require resources; if they can't, then yes, that'd be an easy way to resolve the issue. Something I can look into tonight, I suppose; if it works, then I can restructure my myth units to consume a new Favor-based resource that'd be generated by my religious buildings. But I'm pretty sure city-states can gift any land units, regardless of civ, whether or not they require resources. Likewise, with the Patronage policy that lets them give you great people, they can gift Khans and such, so clearly a lot of the normal limits don't apply.

 

[killmeplease]

CS once gave me a catapult

 

[whoward69]

I've had Gunships and Rocket Artillery from City States (both of which need Aluminium)



If you don't want a CS to build/gift a unit add a "null" entry to the Civilization_UnitClassOverrides table, such as

<Civilization_UnitClassOverrides>
	<Row>
		<CivilizationType>CIVILIZATION_MINOR</CivilizationType>
		<UnitClassType>UNITCLASS_SCOUT</UnitClassType>
		<UnitType/>
	</Row>
</Civilization_UnitClassOverrides>

 

[Spatzimaus]

If you don't want a CS to build/gift a unit add a "null" entry to the Civilization_UnitClassOverrides table

No. As I said before, the UnitClassOverride table determines what a CS can BUILD, but it has no effect on what a CS can GIFT. They're handled through two entirely separate mechanisms; the CS doesn't build a unit and then decide to gift it, it's spawning a unit through an entirely separate mechanism and assigning it to the ally from the start.

Building prequisites, Project prerequisites, UnitClassOverride entries, CanTrain events... none of these affect gifted units.