Common Novice-Modder Mistakes

LeeS

Imperator
Joined
Jul 23, 2013
Messages
7,241
Location
Illinois, USA
Common Novice-Modder Mistakes

Support Issues Related to the Impending Release of Civ6:
  1. Other than to clean up any small whoopses or typos that may exist in the information presented I have no intentions of adding to the information nor of making any great changes to format of how the info is presented
  2. I am attempting to wind-down my Civ5 modding in preperation for the release of 6.
  3. I am not abandoning the Civ5 modding forum, I am just winding down the stuff I have in the works and that I can reasonably expect to put to bed prior to the release of 6.
  4. I intend to move on to 6 modding for the most part (or for the all part), assuming 6 is not a mess or a BE
  5. I am sorry if this disappoints anyone who was looking for me to finish this project, but I can't see that other than adding a few things and cleaning up a couple of the posts that I'll be doing much more on this thread.
  6. In any event, anyone who feels like they have content to add should just go ahead and do so.


Introduction:

New mod-makers tend to a large extent to make the same basic mistakes. These mistakes largely fall into five basic categories:
  1. Typo and syntax errors in XML files. SQL and LUA errors of these types will not be covered since they are not generally mistakes made so often by the novice modder.
  2. A lack of information on how to correctly create the game-code, art files, or unit graphic files needed to accomplish a desired effect in-game causing a mod to not work or not work in the desired fashion.
  3. Misunderstandings about the processes needed in ModBuddy to get a mod to correctly operate in-game.
  4. Misunderstandings about the structure of the game's different types of operating files, and about what can be accomplished in the various types of mod files available to the mod-creator.
  5. A bad general approach to modding caused by simple inexperience.
This thread is intended as a Guide to provide some information on how to cure the most common of the mistakes that experienced members of the forum most often see when people ask for help with a broken mod.

How to Use This Guide:

This Guide is intended to for use by the novice modder, and contains information on the following:
  • The novice modder's most-commonly made general types of errors (IE, #s (4) and (5) on the list in the introduction), with hints on how to cure these mistakes. The hints will often take the form of links to tutorials or references that cover the issue in greater detail than is really appropriate to the scope of this Guide.
  • Links to tutorials and references generally of use to novice modders.
  • Information on some specific problems novice modders encounter, and the likely causes, with hints on how to cure these mistakes. The hints will often take the form of links to tutorials or references that cover the issue in greater detail than is really appropriate to the scope of this Guide.
  • In cases where your problem is not shown here, you should as a general rule start a thread asking for help with your problem. Please follow the guidelines shown when starting a new thread asking for help: New Thread Guidelines


In order to make it a little easier to find the type of information you may be looking for, a set of navigation jump-links is provided.
  • Some of these navigation links will re-direct the thread to the appropriate internal point, and will be referred to as "jump links". For cases of jump-links, an additional re-direct is provided to return you back to the listing of internal links. In order for these internal links to operate correctly you have to have your forum viewing options set to display at least 10 posts per page of a thread.
  • Other links will cause a pop-up window to appear for the appropriate thread post #, and will be referred to as "pop-up links". You can review the pertinant material in the pop-up window, and then simply close it to return to the main thread.
  • Within a post there may be a set of navigation links that allow easier movement within that single post.

The following navigation jump-links are all internal to this thread, and will take you directly to the section of the thread described:

Internal Navigation Links:
  1. Links to tutorials and references generally of use to novice modders
  2. MODDING PROCEDURAL MISTAKES
    • NOT USING LOGGING
    • NOT TAKING A COMPONENTIZED APPROACH TO MAKING A LARGE MOD
    • NOT BECOMING FAMILIAR WITH THE GAME DATABASE
    • USING OUTDATED FILE STRUCTURES (For Unit Art Defines)
    • RUNNING MORE MODS THAN ABSOLUTELY NECCESSARY TO TEST A NEW MOD
    • MAKING OR USING A MOD THAT IS INCOMPATIBLE WITH Gods&Kings OR BraveNewWorld
    • USING A SLIGHTLY-ALTERED VERSION OF AN ORIGINAL GAME-FILE AS PART OF A MOD
    • USING VANILLA XML AS YOUR REFERENCE WHEN YOU HAVE Gods&Kings OR BraveNewWorld
    • PROBLEMS DELETING FIRAXIS-SUPPLIED ELEMENTS OF THE GAME (Buildings, Units, Policies, Beliefs, Techs, Traits, etc.)
    • NOT PROPERLY TESTING THE MOD BEFORE PUBLISHING IT
  3. Jump to the listing of General errors commonly made
    • INCORRECT OPERATION IN MODBUDDY
      • NOT GIVING XML-FILES AN "ONMODACTIVATED"
      • NOT GIVING DDS FILES AN "IMPORT INTO VFS=TRUE" (Note: this also applies to sound files, and certain other files. Full info on other files requiring this setting (link opens a tutorial as a pop-up) )
      • Lua files not set as "InGameUIAddin" under content when required
      • "PLOPPING" FILES INTO THE MODBUDDY PROJECT FOLDER FROM THE BROWSER INSTEAD OF ADDING THEM WITHIN MODBUDDY
      • NOT CHECKING THE REQUIRED MODBUDDY CHECK-BOXES
      • NOT USING MODBUDDY TO VIEW XML FILES FOR SYNTAX ERRORS
      • NOT DOING A "BUILD" AND/OR "BUILD SOLUTION"
      • TYPING FILE NAMES INTO "ACTIONS" OR "CONTENT" DIALOG BOXES
      • BELEIVING IT IS NECESSARY TO UPLOAD A MOD TO STEAM SO THAT IT CAN THEN BE SUBSCRIBED-TO AND DOWNLOADED BEFORE IT CAN BE USED
    • COMMON SYNTAX ERRORS MADE WITHIN XML FILES
      • TYPOS SUCH AS <RWO> INSTEAD OF <ROW>
      • INCORRECT CAPITALIZATION WHERE REQUIRED
      • USING <ROW>, <REPLACE>, OR <UPDATE> OUTSIDE OF TABLE WRAPS
      • WRAPPING <UPDATE> WITH <ROW>, OR VICE VERSA
      • Omitting <Row> or <Update>
      • Omitting a <Where> or <Set> "clause" in an <Update>
      • INCORRECT REFERENCES FROM TYPOS INSTEAD OF USING COPY-PASTE
    • COMMON SYNTAX ERRORS THAT OCCUR WITHIN XML FILES (cont)
      • NOT CLOSING A TABLE OR ROW BEFORE STARTING ANOTHER ROW OR TABLE
      • INCORRECTLY USING COLUMN NAMES
      • Use of Yields in tables where YIELD_X is not usable
      • Use of YIELD_HAPPINESS and YIELD_TOURISM
    • COMMON SYNTAX ERRORS THAT OCCUR WITHIN XML FILES (cont)
      • SHOWING TABLE DEFINITIONS WITHIN AN XML-FILE
      • REPEATING OF LANGUAGE TABLE "TAGS" WITHIN <ROW> COMMANDS
      • NOT USING <UPDATES> AND INSTEAD RE-STATING THE <ROW> WITH CHANGES
  4. Jump to the listing of specific errors commonly made
  5. New Thread Guidelines



  1. In your original post you should try to be as specific as you can as to what your problem is, so far as you are able to understand what has gone wrong with your mod. Many times, however, what the novice modder thinks the problem is and what the problem actually is are two different things. Which is why, at a minimum, you need to adhere to #2 and #3 in this list of what you should do when starting a thread to ask for help.
  2. In your original post, attach a zipped-up copy of the built version of your mod. See this tutorial for how to add the attachment, and what is meant by the built version of the mod.
  3. Start the thread in the main Creation & Customization forum. DO NOT start your thread in any of the sub-forums: Civ5 - Modding Tutorials & Reference, Civ5 - Modpacks, Civ5 - Mod Components , Civ5 - Graphics modpacks, Civ5 - Unit Graphics, Civ5 - New Civilizations, Civ5 - Scenarios, Civ5 - Custom maps, Civ5 - Map Scripts, Civ5 - Utility Programs, Civ5 - Project & Mod Development (or any of its sub-forums). You should avoid posting your question in the Civ5 - SDK / LUA sub-forum unless you are certain you have a question directly related to creating C++/lua programs.
Return to the list of Internal Navigation Links
 

  • All Tutorials and Reference links shown open the related thread for the tutorial or reference as a pop-up window.

References on XML/SQL "Command" Formats:
  1. XML-SQL_Cheat_Sheet_(Civ5) (Link to the CivFanatics Modwiki Article)

Mod Creation Tutorials:
  1. Derek "Keal" Paxton's Original How-To for CIV5 modding. Keal's guide is a little out of date in some particulars because he wrote it lo these many years ago and quite a few things have changed since then. It still, however, gives a good overview of how to mod in CIV5.
  2. The Newbie&#8217;s Guide to Modding Civilization 5 (by LuvToBuild)
  3. what ModBuddy setting for what file types tutorial (by whoward69)
  4. Modding Basics (by ceej12) This is a guide on Steam

Mod DeBugging Tutorials:
  1. enable error logging tutorial (by whoward69)

Forum Use Tutorials:
  1. zip your mods and attach tutorial (by whoward69)

Civilizations Tutorials:
  1. XML data files for Standard Civilizations (inc DLC) tutorial (by whoward69)

Buildings and Wonders Tutorials:
  1. [TUTORIAL] How to make a building: Entry level. (by Thadian)
  2. [TUTORIAL] XML (Advanced) Guide to Adding Buildings and Wonders to Brave New World (by LeeS)

Audio Add-ins Tutorials:
  1. [TUTORIAL] Making a custom Leader use Custom Music! (by Leugi)
  2. [TUTORIAL] Creating your own Soundtrack! (by Leugi)

Unit Tutorials:

Unit Graphics Tutorials:

Icon Creation:
  1. Civilization Icon Template (by sukritact)
  2. DDS Texture (Image File) Creation and Usage for Beginners (by whoward69)
  3. Icon and Screen Pixel Dimension Reference (by FramedArchitect)
  4. Civilization V-style Icons with Gimp (by DJS Henninger)
  5. Wodhann's Icon Graphic Tutorial (by Wodhann)
  6. Improvement, Policy & Unit Action Icons (Firaxis-style) (by Lord Tirian)

Lua Tutorials:
  1. [Lua] Basic Modding Guide for Civ5 (by bane_)

Useful References & Info Threads:
These are not categorized and will generally include charts (or something similar) on elements of modding for CIV5.
  1. [REFERENCE] Text Icons (by BigCece) shows a full listing of commands to insert CIV5 icons into text you create in your mods. The reference was created because this page is somewhat broken.

Multiplayer With Mods:
  1. Jaii der Herr's [BNW] MP Mod Manager
  2. Helpful Dude's Working Civ5 Multiplayer WITH MODS

Return to the list of Internal Navigation Links
 

Attachments

  • Example_MOD_Build_Function_Menu_Opened.jpg
    Example_MOD_Build_Function_Menu_Opened.jpg
    123.9 KB · Views: 4,892

Topics Covered


Of all the Topics listed above, NOT USING LOGGING is probably the most important for the novice modder. Logging allows you to:
  1. begin to examine why your mod does not work in a logical and methodical manner rather than in a haphazzard spitball-and-guess methodology.
  2. more quickly find both which files have errors in them, but also which game tables and even at times within a game-table, which Row you are trying to add to the game contains one or more of the errors that are killing your mod.
  3. bring some kind of an idea to the discussion of the trouble that is causing your mod to fail when you ask others for help. Very often if you read through many posts on the forum you'll see someone post a comment along the lines of:
    Code:
    MemberA:		Troubles! Help!
    MemberB:		What do your error logs tell you?
    MemberA:		Error logs? What are those?
You may not right now at this moment be an expert at understanding what the error logs are telling you. About a year and a half ago I had very little idea of how to use error logs, but I don't bother trouble-shooting code anymore without them (unless it's the sort of obvious syntax and format presentation error that can be spotted by a quick look-through of someone else's code). I've included a short tutorial on how to read the error messages that will occur in the file called "Database.log". I've been convinced by others on the Forum that this topic is so central to learning how to mod in CIV5 that I've arranged this topic as the first covered, after the listing of useful tutorials:​

(1) NOT USING LOGGING
This is a big mistake often made by novice mod-creators. The very first thing you should do if you have not yet enabled logging is to click the link provided here and enable logging as shown in whoward's tutorial: enable error logging tutorial (by whoward69)

Once you enable logging, you should also follow the other procedures as outlined within whoward's tutorial so you have a better idea what errors are "normal" and which are actually being caused by your mod. At least to start, most of you attention should be given to errors that show in the file called "DataBase.log". Here is an example of the kind of error you might get:
Spoiler :
Code:
[777851.390] no such table: Civlizations
[777851.390] In Query - insert into Civlizations('Type', 'Description', 'ShortDescription', 'Adjective', 'Civilopedia', 'CivilopediaTag', 'DefaultPlayerColor', 'ArtDefineTag', 'ArtStyleType', 'ArtStyleSuffix', 'ArtStylePrefix', 'PortraitIndex', 'IconAtlas', 'AlphaIcon', 'MapImage', 'DawnOfManQuote', 'DawnOfManImage') values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?);
[777851.390] In XMLSerializer while updating table Civlizations from file XML/Civilizations/Civ_Redacted.xml.
This was a real set of error reports taken directly from DataBase.log from a real request for help from a novice mod-author.
  • Note that all three lines begin with "[777851.390]". When an error is encountered, and data for it is dumped into one of the error-log files, all lines of text related to that error will have the same numeric error pre-fix. There may be more lines that related to similar but additional errors with the same leading error-number shown within the log, but all lines given that related to an individual error always will show the same numeric "prefix" to the error line. This is so that you can see which lines should be associated with each other.
  • The first line in a related set of lines will generally tell you the exact error that was encountered. I have highlighted the line in blue here:

    Code:
    [777851.390] [COLOR="Blue"]no such table: Civlizations[/COLOR]
    [777851.390] In Query - insert into Civlizations('Type', 'Description', 'ShortDescription', 'Adjective', 'Civilopedia', 'CivilopediaTag', 'DefaultPlayerColor', 'ArtDefineTag', 'ArtStyleType', 'ArtStyleSuffix', 'ArtStylePrefix', 'PortraitIndex', 'IconAtlas', 'AlphaIcon', 'MapImage', 'DawnOfManQuote', 'DawnOfManImage') values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?);
    [777851.390] In XMLSerializer while updating table Civlizations from file XML/Civilizations/Civ_Redacted.xml
  • The second line will generally be telling you what the game was trying to do when it encountered the error. The In Query - insert into Civlizations is saying that the XML-to-SQL system was trying to add new information to the game table Civlizations. This line is good information but isn't quite as useful as the first and last of the three lines.
  • The third line specifies which file from within an individual mod caused the error. Again, highlighted in blue:

    Code:
    [777851.390] no such table: Civlizations
    [777851.390] In Query - insert into Civlizations('Type', 'Description', 'ShortDescription', 'Adjective', 'Civilopedia', 'CivilopediaTag', 'DefaultPlayerColor', 'ArtDefineTag', 'ArtStyleType', 'ArtStyleSuffix', 'ArtStylePrefix', 'PortraitIndex', 'IconAtlas', 'AlphaIcon', 'MapImage', 'DawnOfManQuote', 'DawnOfManImage') values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?);
    [777851.390] In XMLSerializer while updating table Civlizations from file [COLOR="Blue"]XML/Civilizations/Civ_Redacted.xml[/COLOR]
  • Of those three error code lines, I have highlighted the most important ones so far as diagnosing a problem are concerned:

    Code:
    [777851.390] [COLOR="Blue"]no such table: Civlizations[/COLOR]
    [777851.390] In Query - insert into Civlizations('Type', 'Description', 'ShortDescription', 'Adjective', 'Civilopedia', 'CivilopediaTag', 'DefaultPlayerColor', 'ArtDefineTag', 'ArtStyleType', 'ArtStyleSuffix', 'ArtStylePrefix', 'PortraitIndex', 'IconAtlas', 'AlphaIcon', 'MapImage', 'DawnOfManQuote', 'DawnOfManImage') values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?);
    [777851.390] In XMLSerializer while updating [COLOR="Blue"]table Civlizations[/COLOR] from file [COLOR="Blue"]XML/Civilizations/Civ_Redacted.xml[/COLOR]
  • Can't see the problem?

    Spoiler hint :
    Civlizations is spelled incorrectly


Return to the list of Internal Navigation Links
Return to the list of Procedural Mistakes

(2) NOT TAKING A COMPONENTIZED APPROACH TO MAKING A LARGE MOD
I also sometimes refer to this as Eating the Elelphant in One Bite. The trouble for any modder is that mistakes tend to creep into your code as you go along. Typos happen, for example. If you build an entire giant mod all in one go, before you test any one portion of it, you will be faced with a spate of errors that will confuse and dishearten you. Sometimes two or three small errors become synergystic in that they cause compounding, or "cascading", of each into a much larger problem. A typo in the code for a unique building can cause that to fail, which can cause an entire new-civilization mod to fail.

What is meant by "Larger Mod"?
  • I categorize all custom civilization mods as being "larger mods" because every individual element must work properly on its own before the larger whole will work.
  • Any mod that adds more than about two buildings or units to the game is a "Larger Mod" in the way I define it.
  • Any mod that re-defines the Social Policy system
  • Any mod that re-defines the Tech system
  • Any mod that adds a new game mechanic such as a Health and Plague System

What is the solution?
  • Take a "Componentized" approach to creating a larger mod.

That may not seem very helpful at first glance. Let's consider an example of a custom civilization mod. How would I test the sub-components of such a mod without having the whole Civ up and running as a mod?

I would test my sub-components by "attaching" them to a Firaxis-Made civilization, and seeing whether they work properly. So, if I am adding a unique building, I might temporarily add it as a unique to America. I do so by adding a Row to the <Civilization_BuildingClassOverrides> table that will add the unique building to America. Pay no attention when testing in this manner that America (or any other civ) would have more than the normal two (2) uniques. At this point you do not care about balanced-game issues, you just want to see if the building works. The game does not care if a single civ has more than the normal two (2) uniques, it only cares if the civ has less than the normal two (2) uniques.

Here is what my code for adding a unique replacement for the Barracks to America might look like (all it does at this point is assign a building called "Fort" to America as a replacement for "Barracks"):
Code:
<GameData>
	<Civilization_BuildingClassOverrides>
		<Row>
			<CivilizationType>CIVILIZATION_AMERICA</CivilizationType>
			<BuildingClassType>BUILDINGCLASS_BARRACKS</BuildingClassType>
			<BuildingType>BUILDING_FORT</BuildingType>
		</Row>
	</Civilization_BuildingClassOverrides>
</GameData>
You will need this code in your mod anyway, so there's nothing "extra" you would be doing. You can either place this code in an XML-file on its own or you can add it to the rest of the code for the "Fort", like this:
Spoiler :
Code:
<GameData>
	<Civilization_BuildingClassOverrides>
		<Row>
			<CivilizationType>CIVILIZATION_AMERICA</CivilizationType>
			<BuildingClassType>BUILDINGCLASS_BARRACKS</BuildingClassType>
			<BuildingType>BUILDING_FORT</BuildingType>
		</Row>
	</Civilization_BuildingClassOverrides>
	<Buildings>
		<Row>
			<Type>BUILDING_FORT</Type>
			<BuildingClass>BUILDINGCLASS_BARRACKS</BuildingClass>
			<FreeStartEra>ERA_INDUSTRIAL</FreeStartEra>
			<Cost>50</Cost>
			<GoldMaintenance>1</GoldMaintenance>
			<PrereqTech>TECH_BRONZE_WORKING</PrereqTech>
			<Help>TXT_KEY_BUILDING_FORT_HELP</Help>
			<Description>Fort</Description>
			<Civilopedia>TXT_KEY_CIV5_BUILDINGS_FORT_TEXT</Civilopedia>
			<Strategy>TXT_KEY_BUILDING_FORT_STRATEGY</Strategy>
			<ArtDefineTag>ART_DEF_BUILDING_BARRACKS</ArtDefineTag>
			<MinAreaSize>-1</MinAreaSize>
			<UnmoddedHappiness>1</UnmoddedHappiness>
			<HurryCostModifier>25</HurryCostModifier>
			<IconAtlas>BW_ATLAS_1</IconAtlas>
			<NeverCapture>true</NeverCapture>
			<PortraitIndex>5</PortraitIndex>
			<PlotCultureCostModifier>-25</PlotCultureCostModifier>
		</Row>
	</Buildings>
	<Building_DomainFreeExperiences>
		<!-- Fort same as barracks -->
		<Row>
			<BuildingType>BUILDING_FORT</BuildingType>
			<DomainType>DOMAIN_LAND</DomainType>
			<Experience>15</Experience>
		</Row>
		<Row>
			<BuildingType>BUILDING_FORT</BuildingType>
			<DomainType>DOMAIN_SEA</DomainType>
			<Experience>15</Experience>
		</Row>
		<Row>
			<BuildingType>BUILDING_FORT</BuildingType>
			<DomainType>DOMAIN_AIR</DomainType>
			<Experience>15</Experience>
		</Row>
	</Building_DomainFreeExperiences>
</GameData>
But my civilization name is CIVILIZATION_MUGHALS not CIVILIZATION_AMERICA !! How can this possibly help me?
Once you have tested out BUILDING_FORT and ensured it does everything you want it to, you simply change CIVILIZATION_AMERICA to CIVILIZATION_MUGHALS in your XML. I do advise, however, that you leave all the components "attached" to America (as example) until all of the components are known to work. If you start assigning them to CIVILIZATION_MUGHALS and trying to test your mod in-game before everything is ready, you will simply have failures because CIVILIZATION_MUGHALS is incomplete in your XML.​
What can be "componentized" for a new Civilization?

  • Buildings.
  • Units.
  • Improvements.
  • DOM Images and Maps. (though this is a bit trickier to figure out how to do)
  • DOM Text. (though this is a bit trickier to figure out how to do)
  • Traits. (though this is a bit trickier to figure out how to do)
  • Leaders. (though this is a bit trickier to figure out how to do)
All the preceeding is fine for a new Civilization, but what if I want to add 10 new building types to the game that aren't new uniques they're a new sort of a building?

  • Simply add them to the mod one at a time, and test each one before adding the next

Return to the list of Internal Navigation Links
Return to the list of Procedural Mistakes

(3) NOT BECOMING FAMILIAR WITH THE GAME DATABASE
Not becoming familiar with the game's pre-existing database of XML/SQL game-tables falls into three basic categories:
  1. Not understanding the structure of how game-tables are organized, both in a general sense and in a specific sense.
  2. Not understanding what the database is and how you can make use of it as a tool to trouble-shoot your mod(s)
  3. Not understanding how the localization system works
Some Points of Clarification
  • We as mod-makers tend to speak of the "Database" both when discussing XML commands and when discussing SQL commands. But the real database as used by the game only exists as SQL. Anything contained within an XML file is simply converted into SQL before it is added into the game's database.
  • When I speak of the database in this particular topic I will be referring to it as the XML/SQL database for this reason. When you add new stuff to the game (such as a civilization) you can use either XML or SQL to do so. When you want to look at what has actually been added to the database, however, you must do so through an SQL database-viewer-program of some kind. If you just open the file where the actual database is kept using notepad or some other text-edit program, all you'll see is a lot of disorganized gibberish.
  • It is worth noting that as you progress as a mod-maker you will encounter a few types of game elements that must be added via XML only. But for the novice mod-maker this doesn't really apply so for now I will skip any discussion of these particular requirements. If you want to know a bit more now on this subject, take a slow and careful read of whoward69's what ModBuddy setting for what file types tutorial.
The Three Main Errors Re The XML/SQL Database and What They Mean
  1. Not understanding the structure of how game-tables are organized, both in a general sense and in a specific sense.

  2. Not understanding what the database is and how you can make use of it as a tool to trouble-shoot your mod(s)

  3. Not understanding how the localization system works


Return to the list of Internal Navigation Links
Return to the list of Procedural Mistakes

(4) USING OUTDATED FILE STRUCTURES (For Unit Art Defines especially)

Since the first introduction of the game, Firaxis has made various changes to the way certain elements are added into the game via mods. Unfortunately there is little to no documentation provided by Firaxis on the exact changes that have been made.
  1. The single most 'stand-out' of these changes is the way in which unit animations are added to the game. Previously, a mod-maker would use the same tables as are still used by Firaxis in the game's core XML files:
    Code:
    <UnitArtInfos>
    	<UnitArtInfo>
    <UnitMemberArtInfos>
    	<UnitMemberArtInfo>
    Which have been replaced by these tables for defining the "Art" a new unit should use:
    Code:
    <ArtDefine_UnitInfos>
    <ArtDefine_UnitInfoMemberInfos>
    <ArtDefine_UnitMemberInfos>
    <ArtDefine_StrategicView>
    <ArtDefine_UnitMemberCombats>
    <ArtDefine_UnitMemberCombatWeapons>
  2. The second most 'stand-out' of these changes is the difference in expansion levels on how to add Culture yield to a Building.
    • In Vanilla, <Culture>2</Culture> would be used as a column directly within the <Buildings> table to add +2 Culture per turn to a Building.
    • In both G&K and BNW, the <Culture> column is no longer valid, and will cause any file containing such a column within the <Buildings> table to be rejected by the game. G&K and BNW require the same effect to be accomplished using the <Building_YieldChanges> table.

Return to the list of Internal Navigation Links
Return to the list of Procedural Mistakes

(5) RUNNING MORE MODS THAN ABSOLUTELY NECCESSARY TO TEST A NEW MOD

This is far more important than the average novice mod-maker credits.
  1. You should never run your mod in testing with any other mod active which is not absolutely required by your mod or for which you are not specifically testing compatibility to your mod.
  2. The only exception to Rule #1 is the In-Game Editor (IGE) mod.
    • I have never found an occasion where IGE was interfering with any mod I was creating.
    • You will generally want IGE running when you make mod tests because otherwise it is too difficult to create the conditions needed to really test whether a mod is functioning properly code-wise
The primary reasons why you should adhere to these two rules are:
  • You need to know whether your mod runs correctly on its own. Having too many mods running at the same time vastly complicates this task, and makes it nigh on to impossible for the inexperienced mod-maker to determine where and why an error is occuring.
  • You will find it near to impossible to determine what specific mod yours conflicts with (when there is such a conflict) if you have too many mods all running at one time.
Bear in mind that whilst testing a mod, you are not playing the game, you are testing whether or not your mod works. All those favorite mods you enjoy using when you are playing the game simply create clutter during a test process.

Return to the list of Internal Navigation Links
Return to the list of Procedural Mistakes

(6) MAKING OR USING A MOD THAT IS INCOMPATIBLE WITH Gods&Kings OR BraveNewWorld

(7) USING A SLIGHTLY-ALTERED VERSION OF AN ORIGINAL GAME-FILE AS PART OF A MOD

(8) USING VANILLA XML AS YOUR REFERENCE WHEN YOU HAVE Gods&Kings OR BraveNewWorld

(9) PROBLEMS DELETING FIRAXIS-SUPPLIED ELEMENTS OF THE GAME (Buildings, Units, Policies, Beliefs, Techs, Traits, etc.)

(10) NOT PROPERLY TESTING THE MOD BEFORE PUBLISHING IT

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

Attachments

  • Example_MOD_NoOnModActivateds.jpg
    Example_MOD_NoOnModActivateds.jpg
    187.9 KB · Views: 5,015
  • Example_MOD_WithOnModActivateds.jpg
    Example_MOD_WithOnModActivateds.jpg
    180.5 KB · Views: 4,771
  • Example_MOD_NoImportIntoVFS.jpg
    Example_MOD_NoImportIntoVFS.jpg
    172.2 KB · Views: 5,001
  • Example_MOD_WithImportIntoVFS.jpg
    Example_MOD_WithImportIntoVFS.jpg
    173.1 KB · Views: 4,846
  • Example_MOD_AddedArtFilesViaPlopping_Browser.jpg
    Example_MOD_AddedArtFilesViaPlopping_Browser.jpg
    116.4 KB · Views: 4,845
  • Example_MOD_AddedArtFilesViaPlopping_ModBuddy.jpg
    Example_MOD_AddedArtFilesViaPlopping_ModBuddy.jpg
    180.2 KB · Views: 4,923
  • Example_MOD_MOD Info_Systems_Checkboxes.jpg
    Example_MOD_MOD Info_Systems_Checkboxes.jpg
    123.2 KB · Views: 5,336
  • Example_MOD_Garbare_ProperlyFormatted.jpg
    Example_MOD_Garbare_ProperlyFormatted.jpg
    174.8 KB · Views: 5,010
  • Example_MOD_Garbare_ImProperlyFormatted_WithErrors.jpg
    Example_MOD_Garbare_ImProperlyFormatted_WithErrors.jpg
    148.7 KB · Views: 4,982
  • Example_MOD_Build_Function_Menu_Circled.jpg
    Example_MOD_Build_Function_Menu_Circled.jpg
    117.4 KB · Views: 4,878

Topics Covered

(1) NOT GIVING XML-FILES AN "ONMODACTIVATED"

Nearly all XML files require a setting within Modbuddy refered to as an OnModActivated UpdateDatabase to tell the game to load the information in the XML file into the game. Failing to have such a setting when required means that while the XML file is part of the mod, it isn't doing anything. See whoward69's what ModBuddy setting for what file types tutorial for further information and visual instructions on what you should be seeing in ModBUddy to add these OnModActivated UpdateDatabase instructions.

If in Modbuddy you see this, then you have not told the game to do anything with your xml files:

Spoiler :


It ought to look like this:

Spoiler :


Return to List of Incorrect ModBuddy Operation Topics
Return to the list of Internal Navigation Links

(2) NOT GIVING DDS FILES AN "IMPORT INTO VFS=TRUE"

All DDS art files require a setting of "Import Into VFS=true". Without this setting in Modbuddy, the art files will not be active in-game. See whoward69's what ModBuddy setting for what file types tutorial for further information and visual instructions on what you should be seeing in ModBUddy to add these "Import Into VFS" instructions.

If in Modbuddy you see this, then you have not told the game to do anything with your art files:

Spoiler :


It ought to look like this:

Spoiler :


Spoiler more detailed instructions :

  1. Project Opened in Modbuddy:
    Spoiler :
  2. Art File Selected
    • You can also select multiple art files at the same time before going to the next step, and all such multiple-selected files will have their "Import Into VFS" setting changed at the same time and all in one "go" instead of individually selecting each art file and changing the VFS setting
    Spoiler :
  3. Right-Click the Art File name to Bring up menu
    Spoiler :
  4. Properties in the pop-up menu
    Spoiler :
  5. Properties selected changes display. Note that "false" is set for Import Into VFS
    Spoiler :
  6. Selector is brought up by clicking on "false"
    Spoiler :
  7. "True" chosen in place of false
    Spoiler :
  • Directly after you open the mod project in ModBuddy, if you cannot see the "Solution Explorer" window, press "CTRL + ALT + L"
  • Do not use the "File Open" button to open a dds file. Use it only for XML, SQL, and LUA files.
    • This is mentioned because some people have misunderstood and attempted to get at the dds file's properties window by 1st opening the dds file within ModBuddy


Return to List of Incorrect ModBuddy Operation Topics
Return to the list of Internal Navigation Links

(3) Lua files not set as "InGameUIAddin" under content when required

This is probably the most common error made within ModBuddy in relation to Lua files. Probably greater than 8 out of 10 lua files written need to be added to the game in this way. However, many Lua files are not added in this manner. See whoward69's what ModBuddy setting for what file types tutorial for detailed information on each type of Lua file and what settings within ModBuddy are required.

Return to List of Incorrect ModBuddy Operation Topics
Return to the list of Internal Navigation Links

(4) "PLOPPING" FILES INTO THE MODBUDDY PROJECT FOLDER FROM THE BROWSER INSTEAD OF ADDING THEM WITHIN MODBUDDY

By "plopping" I mean using copy-paste or dragging the files from a directory somewhere on one's computer to the folder ModBUddy creates for the Mod. This is OK in and of itself so long as you are able to keep track of which files have been placed into the ModBuddy Mod-directory in this way, and those which have actually been added to the mod via ModBuddy's internal file-add system.

Examine the following image. It shows an expanded directory view in my browser of the ModBuddy folder and file structure for a Mod called "Example MOD". Note that there are five DDS file names showing in the directory "ART". They were added to the mod's directory by pasting them in via my browser.

Spoiler :


Here is the view of the same Mod file and directory structure from within ModBuddy. I am unable to expand the "ART" folder to show the files within it because so far as ModBuddy is concerned those DDS files do not exist as part of the mod. The reason the files are not recognized by ModBuddy is that I "Plopped" the files in from my browser, and did not use ModBuddy's internal file-add system.

Spoiler :


No changes were made either using my browser or using modbuddy between when the two image captures were taken.
Spoiler the Experienced Mod-Creator :
Yes, Yes, I know all about how you can paste a new version of an lua, SQL, or XML file into your Modbuddy Project directly from your browser, and I do this very often myself, but:
  1. This is written towards the needs of the Inexperienced Mod-Creator
  2. So let's please not confuse the issue for them by long-winded posts about advanced methodologies.

Return to List of Incorrect ModBuddy Operation Topics
Return to the list of Internal Navigation Links

(5) NOT CHECKING THE REQUIRED MODBUDDY CHECK-BOXES

When adding audio files, unit graphics, or stategic-view icons (for units) you need to check certain checkboxes in Modbuddy in order for the game to know that it should, for lack of a better description, "re-initialise" certain game "Systems". Checking the check-boxes tells the game to do so when the mod gets loaded. This is where the checkboxes are located within Modbuddy:

Spoiler :


You will have to scroll down once you select the "MOD Info" tab. Some mod-creators always check the four boxes regardless of whether they are adding an element that will require it: so far as I know there's no downside to this method of dealing with the check-boxes.

Return to List of Incorrect ModBuddy Operation Topics
Return to the list of Internal Navigation Links

(6) NOT USING MODBUDDY TO VIEW XML FILES FOR SYNTAX ERRORS

In ModBuddy, when you select an XML file by double-clicking on it, the contents of the file will be displayed, and any format errors will be noted in the "Error List" window.

Spoiler :


The text of the XML may be a little hard to read, so I've repeated it here:
Code:
<GameData>
	<Quatloos>
		<Update>
			<Where Type="BUILDING_CONSCRIPT" />
			<Set Longwindedness="47" SpacialRelation="true" />
		</Update>
	</Quatloos>
</GameData>
There's no such game table as <Quatloos>, and there's certainly no Columns within it called either Longwindedness or SpacialRelation, so why are there no errors showing in the ModBuddy Error List window? No errors are showing because ModBuddy does not generate errors based on content. It only generates errors based on selected syntax criterion.

So Long as there is an "opener", such as <Quatloos>, that looks like it is properly formatted, and is followed by a similar "closer" that also looks like it is properly formatted, there will be no errors generated. The contents of these commands can be complete rubbish so long as they are presented in the correct form.

Here is a case where Modbuddy is reporting an error:

Spoiler :


To "cure" these errors I would need to add a </Row> closer, or even better, delete the <Row> opener, since <Row> -- </Row> is never used to "wrap" <Update> -- </Update>. Issues of when to use <Row>, <Update>, and <Replace> will be covered later, here Common Novice-Modder Mistakes -- "COMMON SYNTAX ERRORS MADE WITHIN XML FILES" (pop-up link).

The types of errors that ModBuddy will catch are typo errors, forgetting to close <Rows> or tables, and missing items such as the "/", "<", ">" characters. Modbuddy is not perfect, but it is a tool you have, so use it.

Return to List of Incorrect ModBuddy Operation Topics
Return to the list of Internal Navigation Links

(7) NOT DOING A "BUILD" AND "BUILD SOLUTION"

A common first-time mistake is to simply save all the work done in ModBuddy, but never doing a "Build" of the mod. There's been some confusion from time to time with novice modders thinking that "Building the mod" is the same as adding-in files and actions, and then saving one's work. Saving one's work often is a good policy in ModBuddy (as it is in any software program) but does not in any way "Build" the mod. Nor does "Building the mod" send it to the Steam Workshop.

Simply adding files and giving them their required activation instructions is not the same thing as "Building the MOD". You have to "Build" the mod in order for ModBuddy to generate the "control" file that tells the game what to do with your mod. Without this file (it will have a file extension of ".modinfo") the game will have no instructions on what to do with the files that are included within your ModBuddy project. The way you "Build" the mod is to use ModBuddy's "Build" menu on the top panel of ModBuddy:

Spoiler :


Clicking on "Build" in ModBuddy opens this drop-down menu:

Spoiler :


  • Clicking on "Build Solution" will actually make Modbuddy do the "Build" function, and a game-usable copy of the mod will be sent to the Sid Meier's Civilization 5 / MODS folder.
  • "Build Solution" also creates a zipped version of the mod (in the form of a xxx.civ5mod file) that can be used for sharing the mod with others (including if you want to offer the mod on the Steam Workshop). The civ5mod type of file will be located in a "Packages" folder at ~Documents/Firaxis ModBuddy/Example MOD/Packages
    • Obviouosly, your mod will have a different folder name than ~/Example MOD/~
If you still have format errors in your XML, SQL, or lua files, or if you have errors such as not setting VFS=true for artwork DDS files, you will NOT get an error in the errors list box of ModBuddy. The only times you will get errors is for such things as ModBuddy cannot "read" the files because there's a corruption in the file of some kind, for example. But these will be the sorts of errors that are not of the "can be read by humans" kind, these will be errors that are of the "only computers can read the code(s) that are missing or corrupt" kind. The ModBuddy software operating-level sort of stuff is what will show in the errors list when you "Build" your mod.


Return to List of Incorrect ModBuddy Operation Topics
Return to the list of Internal Navigation Links

(8) TYPING FILE NAMES INTO "ACTIONS" OR "CONTENT" DIALOG BOXES


Return to List of Incorrect ModBuddy Operation Topics
Return to the list of Internal Navigation Links

(9) BELEIVING IT IS NECESSARY TO UPLOAD A MOD TO STEAM SO THAT IT CAN THEN BE SUBSCRIBED-TO AND DOWNLOADED BEFORE IT CAN BE USED

Nothing is further from the truth. "Building the mod" creates a usable copy of the mod in the MODS folder of the person who created it. For a mod you make for your own personal use, you never need to upload it to Steam, nor subscribe to it on Steam, or anything at all with Steam. The Steam Workshop is for sharing mods you make with others, and is not needed to run a mod you make for yourself.

Return to List of Incorrect ModBuddy Operation Topics
Return to the list of Internal Navigation Links
 


(1) TYPOS SUCH AS <RWO> INSTEAD OF <ROW>

It may seem self-evident that such typos will make a mod not function properly, but often it is the transpositional typos that are the most difficult to spot. Viewing the file in ModBuddy will highlight these types of errors. Some of the other commonly-made typographical and transpositional errors:
  1. >!-- some comment text --> instead of <!-- some comment text -->

Return to top of Post
Return to the list of Internal Navigation Links

(2) INCORRECT CAPITALIZATION WHERE REQUIRED

Most (if not all) of the Firaxis-made table and column names within XML have combinations of Caps and lower-case. These table and column names must be presented within a mod exactly as they were used by Firaxis. This is also true of table names (such as <Buildings> ) and "control-code" commands (such as <Row> or <Update>) in XML. It is not optional to present "Row" as "row": the "R" must be a capital letter.

Return to top of Post
Return to the list of Internal Navigation Links

(3) USING <ROW>, <REPLACE>, OR <UPDATE> OUTSIDE OF TABLE WRAPS

A very common error is to do this:
Code:
<GameData>
	[COLOR="Red"]<Row>[/COLOR]
		<Buildings>
			<Type>BUILDING_TEST</Type>
			<BuildingClass>BUILDINGCLASS_TEST</BuildingClass>
			<Cost>50</Cost>
			<PrereqTech>NULL</PrereqTech>
			<ArtDefineTag>NONE</ArtDefineTag>
			<MinAreaSize>-1</MinAreaSize>
			<NeverCapture>true</NeverCapture>
			<HurryCostModifier>-1</HurryCostModifier>
			<IconAtlas>BW_ATLAS_1</IconAtlas>
			<PortraitIndex>19</PortraitIndex>
			<Description>TXT_KEY_BUILDING_TEST</Description>
		</Buildings>
	[COLOR="Red"]</Row>[/COLOR]
</GameData>
Or this:
Code:
<GameData>
	[COLOR="Red"]<Replace>[/COLOR]
		<Buildings>
			<Type>BUILDING_TEST</Type>
			<BuildingClass>BUILDINGCLASS_TEST</BuildingClass>
			<Cost>50</Cost>
			<PrereqTech>NULL</PrereqTech>
			<ArtDefineTag>NONE</ArtDefineTag>
			<MinAreaSize>-1</MinAreaSize>
			<NeverCapture>true</NeverCapture>
			<HurryCostModifier>-1</HurryCostModifier>
			<IconAtlas>BW_ATLAS_1</IconAtlas>
			<PortraitIndex>19</PortraitIndex>
			<Description>TXT_KEY_BUILDING_TEST</Description>
		</Buildings>
	[COLOR="Red"]</Replace>[/COLOR]
</GameData>
Or this:
Code:
<GameData>
	[COLOR="Red"]<Update>[/COLOR]
		<Buildings>
			<Where Type="BUILDING_TEST" />
			<Set Cost="60" />
		</Buildings>
	[COLOR="Red"]</Update>[/COLOR]
</GameData>
All of the foregoing are incorrect because the <Row> -- </Row>, <Update> -- </Update>, and <Replace> -- </Replace> "wrappers" are around the table name (<Buildings>). The two things to remember here are that (a) <Row>, <Update>, and <Replace> all either create or alter a row within a game table, and are used in place of each other, and (b) since they are adding or altering data within a table, they can never appear outside the name of the table.

The correct syntax for all three commands <Row>, <Replace>, and <Update> would be as follows:
Code:
<GameData>
	<Buildings>
		[COLOR="blue"]<Row>[/COLOR]
			<Type>BUILDING_TEST</Type>
			<BuildingClass>BUILDINGCLASS_TEST</BuildingClass>
			<Cost>50</Cost>
			<PrereqTech>NULL</PrereqTech>
			<ArtDefineTag>NONE</ArtDefineTag>
			<MinAreaSize>-1</MinAreaSize>
			<NeverCapture>true</NeverCapture>
			<HurryCostModifier>-1</HurryCostModifier>
			<IconAtlas>BW_ATLAS_1</IconAtlas>
			<PortraitIndex>19</PortraitIndex>
			<Description>TXT_KEY_BUILDING_TEST</Description>
		[COLOR="blue"]</Row>[/COLOR]
	</Buildings>
</GameData>
Or this:
Code:
<GameData>
	<Buildings>
		[COLOR="blue"]<Replace>[/COLOR]
			<Type>BUILDING_TEST</Type>
			<BuildingClass>BUILDINGCLASS_TEST</BuildingClass>
			<Cost>50</Cost>
			<PrereqTech>NULL</PrereqTech>
			<ArtDefineTag>NONE</ArtDefineTag>
			<MinAreaSize>-1</MinAreaSize>
			<NeverCapture>true</NeverCapture>
			<HurryCostModifier>-1</HurryCostModifier>
			<IconAtlas>BW_ATLAS_1</IconAtlas>
			<PortraitIndex>19</PortraitIndex>
			<Description>TXT_KEY_BUILDING_TEST</Description>
		[COLOR="blue"]</Replace>[/COLOR]
	</Buildings>
</GameData>
Or this:
Code:
<GameData>
	<Buildings>
		[COLOR="blue"]<Update>[/COLOR]
			<Where Type="BUILDING_TEST" />
			<Set Cost="60" />
		[COLOR="blue"]</Update>[/COLOR]
	</Buildings>
</GameData>

Another related common mistake is to have "orphan" Rows shown in the XML without any reference to a game table, such as:
Code:
<GameData>
	<Buildings>
		[COLOR="blue"]<Row>[/COLOR]
			<Type>BUILDING_TEST</Type>
			<BuildingClass>BUILDINGCLASS_TEST</BuildingClass>
			<Cost>50</Cost>
			<PrereqTech>NULL</PrereqTech>
			<ArtDefineTag>NONE</ArtDefineTag>
			<MinAreaSize>-1</MinAreaSize>
			<NeverCapture>true</NeverCapture>
			<HurryCostModifier>-1</HurryCostModifier>
			<IconAtlas>BW_ATLAS_1</IconAtlas>
			<PortraitIndex>19</PortraitIndex>
			<Description>TXT_KEY_BUILDING_TEST</Description>
		[COLOR="blue"]</Row>[/COLOR]
	</Buildings>

		[color="red"]<Row>
			<BuildingType>BUILDING_BAZAAR</BuildingType>
			<FlavorType>FLAVOR_I_TRADE_ORIGIN</FlavorType>
			<Flavor>25</Flavor>
		</Row>[/color]

	<Building_LocalResourceAnds>
		<Row>
			<BuildingType>BUILDING_FORGE</BuildingType>
			<ResourceType>RESOURCE_IRON</ResourceType>
		</Row>
	</Building_LocalResourceAnds>
</GameData>
The portion highlighted in red should be shown as a Row within the Table <Building_Flavors>, but as it is it is part of no game table, and will simply cause the game to discard the entire file where such a mistake occurs.

Return to top of Post
Return to the list of Internal Navigation Links

(4) WRAPPING <UPDATE> WITH <ROW>, OR VICE VERSA


<Row> and <Update> are used in place of each other, and are never used to "wrap" the other. These are both wrong, and not the correct way to structure an <Update>:
Code:
<GameData>
	<Traits>
		[COLOR="Red"]<Row>[/COLOR]
			<Update>
				<Where Type="TRAIT_OCEAN_MOVEMENT" />
				<Set ExtraFoundedCityTerritoryClaimRange="6" />
			</Update>
		[COLOR="Red"]</Row>[/COLOR]

		<Update>
			[COLOR="Red"]<Row>[/COLOR]
				<Where Type="TRAIT_CAPITAL_BUILDINGS_CHEAPER" />
				<Set PlotBuyCostModifier="-25" />
			[COLOR="Red"]</Row>[/COLOR]
		</Update>
	</Traits>
</GameData>
This would be the correct code:
Code:
<GameData>
	<Traits>
		<Update>
			<Where Type="TRAIT_OCEAN_MOVEMENT" />
			<Set ExtraFoundedCityTerritoryClaimRange="6" />
		</Update>

		<Update>
			<Where Type="TRAIT_CAPITAL_BUILDINGS_CHEAPER" />
			<Set PlotBuyCostModifier="-25" />
		</Update>
	</Traits>
</GameData>
Similarly, you do not use an <Update> pair to "wrap" <Row> within a mod, even though it might seem like you ought to since after all you are updating the game's basic data. As reasonable as this method of thinking about things might seem, it is not how the structure of mod-making for CIV5 works. The confusion for the novice mod-creator seems to be primarily in understanding when a <Row> pair is required and when an <Update> pair is required.
  • When a table already has a <Row> within it giving information about a unit, or a building, or a social policy, or a leader trait, or a belief, it is a good bet that an <Update> will be required.
  • Where a game table has a "<Type>" column, it will be required to use an <Update> pair to change the information pertaining to one of the "Types" that have been defined under that table. So, since the game already has a "Type" called "TRAIT_CAPITAL_BUILDINGS_CHEAPER" within the table "<Traits>", it is necessary to use an <Update> structure to add-on new data to the trait "TRAIT_CAPITAL_BUILDINGS_CHEAPER". Attempting to use a <Row> structure will simply be rejected by the game.
  • If a game table has no <Row> within it related to the information you wish to add or change, <Row> structure is required.
    There is no <Row> within the table <Trait_ImprovementYieldChanges> for the trait type TRAIT_RIVER_EXPANSION, so if I only wanted to change this trait to allow a certain improvement to yield one extra food than normal, I would need to use a <Row> structuring to my mod, and not an <Update> structuring:
    Code:
    <GameData>
    	<Trait_ImprovementYieldChanges>
    		<Row>
    			<TraitType>TRAIT_RIVER_EXPANSION</TraitType>
    			<ImprovementType>IMPROVEMENT_FISHING_BOATS</ImprovementType>
    			<YieldType>YIELD_FOOD</YieldType>
    			<Yield>1</Yield>
    		</Row>
    	</Trait_ImprovementYieldChanges>
    </GameData>
    This would make all fishing boats yield an extra food for America.

    Return to #14 of the common XML Syntax errors

Spoiler additional note :

<Replace> can also be used, in place of <Update>. But when using <Replace>, the entire new definition of the "row" must be presented, and not just the portions which need to be altered.


Return to top of Post
Return to the list of Internal Navigation Links

(5) Omitting <Row> or <Update>


A common mistake is to forget entirely the required <Row> wrappers around a new entry into a game table.

For adding a new row to a table, this is incorrect:
Code:
<GameData>
	<Belief_BuildingClassYieldChanges>
		<BeliefType>BELIEF_SHRINE_ENHANCER</BeliefType>
		<BuildingClassType>BUILDINGCLASS_SHRINE</BuildingClassType>
		<YieldType>YIELD_CULTURE</YieldType>
		<YieldChange>1</YieldChange>
	</Belief_BuildingClassYieldChanges>
</GameData>
While this is correct:
Code:
<GameData>
	<Belief_BuildingClassYieldChanges>
		[COLOR="blue"]<Row>[/COLOR]
			<BeliefType>BELIEF_SHRINE_ENHANCER</BeliefType>
			<BuildingClassType>BUILDINGCLASS_SHRINE</BuildingClassType>
			<YieldType>YIELD_CULTURE</YieldType>
			<YieldChange>1</YieldChange>
		[COLOR="blue"]</Row>[/COLOR]
	</Belief_BuildingClassYieldChanges>
</GameData>
For altering an existing row within a table, this is incorrect:
Code:
<GameData>
	<Belief_BuildingClassYieldChanges>
		<Where BeliefType="BELIEF_ANCESTOR_WORSHIP" YieldType="YIELD_CULTURE" />
		<Set YieldChange="2" />
	</Belief_BuildingClassYieldChanges>
</GameData>
And this also is incorrect*:
Code:
<GameData>
	<Belief_BuildingClassYieldChanges>
		<Row>
			<BeliefType>BELIEF_ANCESTOR_WORSHIP</BeliefType>
			<BuildingClassType>BUILDINGCLASS_SHRINE</BuildingClassType>
			<YieldType>YIELD_CULTURE</YieldType>
			<YieldChange>2</YieldChange>
		</Row>
	</Belief_BuildingClassYieldChanges>
</GameData>
* note that there are some game tables where the incorrect example just shown will not cause the game to discard the entire file where the error occurs, but the desired change won't be made correctly.

This is correct:
Code:
<GameData>
	<Belief_BuildingClassYieldChanges>
		[COLOR="blue"]<Update>[/COLOR]
			<Where BeliefType="BELIEF_ANCESTOR_WORSHIP" YieldType="YIELD_CULTURE" />
			<Set YieldChange="2" />
		[COLOR="blue"]</Update>[/COLOR]
	</Belief_BuildingClassYieldChanges>
</GameData>
Similarly, multiple "additions" or "alterations" within a table each require their own <Row> or <Update> pair, as in this, which is correct:
Spoiler :
The color coding is being used to distingiush the two sets of rows from one another.
Code:
<GameData>
	<Belief_BuildingClassYieldChanges>
		[COLOR="blue"]<Row>
			<BeliefType>BELIEF_ANCESTOR_WORSHIP</BeliefType>
			<BuildingClassType>BUILDINGCLASS_SHRINE</BuildingClassType>
			<YieldType>YIELD_CULTURE</YieldType>
			<YieldChange>1</YieldChange>
		</Row>[/COLOR]
		[COLOR="green"]<Row>
			<BeliefType>BELIEF_FEED_WORLD</BeliefType>
			<BuildingClassType>BUILDINGCLASS_SHRINE</BuildingClassType>
			<YieldType>YIELD_FOOD</YieldType>
			<YieldChange>1</YieldChange>
		</Row>[/COLOR]
	</Belief_BuildingClassYieldChanges>
</GameData>
But NOT this, which will simply cause the game to discard an entire file:
Spoiler :
This whole thing is bad. The green and blue coloring are being used to distinguish the parts that ought to be included within thier own <Row> -- </Row> pairs instead of being lumped all into one.
Code:
<GameData>
	<Belief_BuildingClassYieldChanges>
		[COLOR="red"]<Row>[/COLOR]
			[COLOR="blue"]<BeliefType>BELIEF_ANCESTOR_WORSHIP</BeliefType>
			<BuildingClassType>BUILDINGCLASS_SHRINE</BuildingClassType>
			<YieldType>YIELD_CULTURE</YieldType>
			<YieldChange>1</YieldChange>[/COLOR]
			[COLOR="green"]<BeliefType>BELIEF_FEED_WORLD</BeliefType>
			<BuildingClassType>BUILDINGCLASS_SHRINE</BuildingClassType>
			<YieldType>YIELD_FOOD</YieldType>
			<YieldChange>1</YieldChange>[/COLOR]
		[COLOR="red"]</Row>[/COLOR]
	</Belief_BuildingClassYieldChanges>
</GameData>

Return to top of Post
Return to the list of Internal Navigation Links

(6) Omitting a <Where> or <Set> "clause" in an <Update>


In creating updates to existing code, these are common mistakes:
Code:
<GameData>
	<Belief_BuildingClassYieldChanges>
		<Update>
			<Where BeliefType="BELIEF_ANCESTOR_WORSHIP" YieldType="YIELD_CULTURE" />
		</Update>
	</Belief_BuildingClassYieldChanges>
</GameData>
or
Code:
<GameData>
	<Belief_BuildingClassYieldChanges>
		<Update>
			<Set YieldChange="2" />
		</Update>
	</Belief_BuildingClassYieldChanges>
</GameData>
  • In the first, there is only a "Where" statement, but no "Set" statement, so the game knows which BeliefType within the table <Belief_BuildingClassYieldChanges> should be changed, but it has no instruction on what change to make.
  • In the second, the error is just the opposite: the game has an instruction on what change to make, but not where to apply the change. This second mistake can have wildly different results than those anticipated, since it would want to alter all the entries within the table <Belief_BuildingClassYieldChanges> to give a YieldChange of "2".
As in # 5, the correct code would be:
Code:
<GameData>
	<Belief_BuildingClassYieldChanges>
		<Update>
			<Where BeliefType="BELIEF_ANCESTOR_WORSHIP" YieldType="YIELD_CULTURE" />
			<Set YieldChange="2" />
		</Update>
	</Belief_BuildingClassYieldChanges>
</GameData>
Except in very limited circumstances you will always want an <Update> pair to include both a Where and a Set clause.

Return to top of Post
Return to the list of Internal Navigation Links

(7) INCORRECT REFERENCES FROM TYPOS INSTEAD OF USING COPY-PASTE

Instead of using a copy-and-paste method for pulling references to existing Firaxis code, or to code created previously in an XML file, many times a mod-creator will re-type the reference from memory. This leads to incorrect references in building-names, unit-names, flavor-names, etc. These types of errors are not always fatal to a file (IE, does not always cause the game to discard the entire file), but will make the mod not operate in the manner desired. More often than not, though, and according to Murphy's Law, such as incorrect reference will cause the game to discard the entire file where such an error occurs. It is better to use copy-and-paste than to rely on memory. These types of errors also often occur with table names or column names within tables. There is really no better solution to both of these issues than familiarity with the structure of the game's database, and copying a building-name, unit-name, etc., that you have created where the reference to this new name is required.

This is the sort of error that occurs when creating a new building, for example:
Spoiler :
Code:
<GameData>
	<Buildings>
		<Row>
			<Type>[COLOR="red"]BUILDING_HORSES_MARKET[/COLOR]</Type>
			<BuildingClass>[COLOR="red"]BUILDINGCLASS_HORSES_MARKET[/COLOR]</BuildingClass>
			<Cost>100</Cost>
			<GoldMaintenance>1</GoldMaintenance>
			<PrereqTech>TECH_MATHEMATICS</PrereqTech>
			<FreeStartEra>ERA_MODERN</FreeStartEra>
			<Help>TXT_KEY_BUILDING_HORSES_MARKET_HELP</Help>
			<Description>TXT_KEY_BUILDING_HORSES_MARKET</Description>
			<Civilopedia>TXT_KEY_BUILDING_HORSES_MARKET_PEDIA</Civilopedia>
			<Strategy>TXT_KEY_BUILDING_HORSES_MARKET_STRATEGY</Strategy>
			<ArtDefineTag>NONE</ArtDefineTag>
			<MinAreaSize>-1</MinAreaSize>
			<NeverCapture>true</NeverCapture>
			<IconAtlas>HORSES_MARKET_ATLAS</IconAtlas>
			<PortraitIndex>0</PortraitIndex>
		</Row>
	</Buildings>
	<BuildingClasses>
		<Row>
			<Type>[COLOR="red"]BUILDINGCLASS_HORSE_MARKET[/COLOR]</Type>
			<DefaultBuilding>[COLOR="red"]BUILDING_HORSE_MARKET[/COLOR]</DefaultBuilding>
			<Description>TXT_KEY_BUILDING_HORSES_MARKET</Description>
		</Row>
	</BuildingClasses>
</GameData>
  • The two sets of references are very close in name, but they are not exactly the same. The game is literal: it requires exact match of character strings.
  • In case the error still eludes you, there is an extra "S" in "HORSE" for the <Buildings> table columns <Type> and <BuildingClass>.
  • Refer here (insert a link to appropriate thread or jump-point) for information on becoming familiar with the game's database.

COMMON SYNTAX ERRORS MADE WITHIN XML FILES will be continued in next post​
 
(COMMON SYNTAX ERRORS THAT OCCUR WITHIN XML FILES continued from previous post)​

Topics Covered

(8) NOT CLOSING A TABLE OR ROW BEFORE STARTING ANOTHER ROW OR TABLE
Also Known As:
  • "Wrapping" or "Encapsulating" one Game-table within another. Commonly made with the <Language_en_US> table.

Every time you "open" a game table or row, you must "close" the same game table or row before you can "open" the next needed one.

Game Tables:
  • By "opening a game table", I mean a statement in XML such as: <Buildings>
  • The required "closer" that must follow before a new game-table can be opened is the same table-name preceeded by the / character, so to close the example just shown, I need to state: </Buildings>
  • You can add as many <Row> -- </Row> or <Update> -- </Update> pairs within a game table between the opener and closer as are needed, but you must preceed the <Row> or <Update> pairs with the table opener, and you must follow them with the table closer.

Rows:
  • By "opening a row", I mean this statement in XML: <Row>
  • The required "closer" that must follow before a new row can be opened in the same table is simply: </Row>
  • The same rule applies to <Update> and <Replace>.
I can do the following:
Spoiler :
Taken, I believe, from an old version of a JFD mod. The color codings are to show the "pair-ups" needed for the table opener and closer commands, but are not otherwise significant in this example.
Code:
<GameData>
	[COLOR="blue"]<BuildingClasses>[/COLOR]
		<Row>
			<Type>BUILDINGCLASS_SUPREMECOURT</Type>
			<DefaultBuilding>BUILDING_SUPREMECOURT</DefaultBuilding>
			<Description>TXT_KEY_BUILDING_SUPREMECOURT</Description>
			<MaxPlayerInstances>1</MaxPlayerInstances>
		</Row>
		<Row>
			<Type>BUILDINGCLASS_HIGHCOURT</Type>
			<DefaultBuilding>BUILDING_HIGHCOURT</DefaultBuilding>
			<Description>TXT_KEY_BUILDING_HIGHCOURT</Description>
		</Row>
		<Row>
			<Type>BUILDINGCLASS_MAGISTRATECOURT</Type>
			<DefaultBuilding>BUILDING_MAGISTRATECOURT</DefaultBuilding>
			<Description>TXT_KEY_BUILDING_MAGISTRATECOURT</Description>
		</Row>
	[COLOR="blue"]</BuildingClasses>[/COLOR]
	[COLOR="red"]<Buildings>[/COLOR]
		<Row>
			<Type>BUILDING_SUPREMECOURT</Type>
			<BuildingClass>BUILDINGCLASS_SUPREMECOURT</BuildingClass>
			<Cost>220</Cost>
			<PrereqTech>TECH_CODE_OF_LAWS</PrereqTech>
			<Help>TXT_KEY_WONDER_SUPREMECOURT_HELP</Help>
			<Description>TXT_KEY_BUILDING_SUPREMECOURT</Description>
			<Civilopedia>TXT_KEY_WONDER_SUPREMECOURT_DESC</Civilopedia>
			<Strategy>TXT_KEY_BUILDING_SUPREMECOURT_STRATEGY</Strategy>
			<ArtDefineTag>NONE</ArtDefineTag>
			<PolicyCostModifier>-10</PolicyCostModifier>
			<NukeImmune>true</NukeImmune>
			<UnmoddedHappiness>4</UnmoddedHappiness>
			<HurryCostModifier>-1</HurryCostModifier>
			<MinAreaSize>10</MinAreaSize>
			<ConquestProb>100</ConquestProb>
			<IconAtlas>JFDBUILDINGATLAS</IconAtlas>
			<PortraitIndex>0</PortraitIndex>
		</Row>
		<Row>
			<Type>BUILDING_HIGHCOURT</Type>
			<BuildingClass>BUILDINGCLASS_HIGHCOURT</BuildingClass>
			<Cost>130</Cost>
			<PrereqTech>TECH_CODE_OF_LAWS</PrereqTech>
			<Help>TXT_KEY_HIGHCOURT_HELP</Help>
			<GoldMaintenance>3</GoldMaintenance>
			<Description>TXT_KEY_BUILDING_HIGHCOURT</Description>
			<Civilopedia>TXT_KEY_HIGHCOURT_DESC</Civilopedia>
			<Strategy>TXT_KEY_BUILDING_HIGHCOURT_STRATEGY</Strategy>
			<BuildingProductionModifier>15</BuildingProductionModifier>
			<Happiness>2</Happiness>
			<ArtDefineTag>NONE</ArtDefineTag>
			<MinAreaSize>-1</MinAreaSize>
			<HurryCostModifier>25</HurryCostModifier>
			<ConquestProb>0</ConquestProb>
			<IconAtlas>JFDBUILDINGATLAS</IconAtlas>
			<PortraitIndex>1</PortraitIndex>
		</Row>
		<Row>
			<Type>BUILDING_MAGISTRATECOURT</Type>
			<BuildingClass>BUILDINGCLASS_MAGISTRATECOURT</BuildingClass>
			<Cost>90</Cost>
			<PrereqTech>TECH_WRITING</PrereqTech>
			<Help>TXT_KEY_MAGISTRATECOURT_HELP</Help>
			<GoldMaintenance>2</GoldMaintenance>
			<Description>TXT_KEY_BUILDING_MAGISTRATECOURT</Description>
			<Civilopedia>TXT_KEY_MAGISTRATECOURT_DESC</Civilopedia>
			<Strategy>TXT_KEY_BUILDING_MAGISTRATECOURT_STRATEGY</Strategy>
			<BuildingProductionModifier>10</BuildingProductionModifier>
			<Happiness>1</Happiness>
			<ArtDefineTag>NONE</ArtDefineTag>
			<MinAreaSize>-1</MinAreaSize>
			<HurryCostModifier>25</HurryCostModifier>
			<ConquestProb>0</ConquestProb>
			<IconAtlas>JFDBUILDINGATLAS</IconAtlas>
			<PortraitIndex>2</PortraitIndex>
		</Row>
	[COLOR="red"]</Buildings>[/COLOR]
	[COLOR="green"]<Building_PrereqBuildingClasses>[/COLOR]
		<Row>
			<BuildingType>BUILDING_SUPREMECOURT</BuildingType>
			<BuildingClassType>BUILDINGCLASS_HIGHCOURT</BuildingClassType>
			<NumBuildingNeeded>-1</NumBuildingNeeded>
		</Row>
	[COLOR="green"]</Building_PrereqBuildingClasses>[/COLOR]
</GameData>
But I cannot do the following:
Spoiler :

  • Same code as previous, but with the game table opener and closers shown in an improper order. The color codings are to show the "pair-ups" of table opener and closer commands, but are not otherwise significant in this example. The "pair-ups" of the table openers and closers are themselves, however, shown in a manner that the game will not accept.
  • Nor will any other permutation of where to include the table openers and where to include the table closers suffice to create a working mod.
Code:
<GameData>
	[COLOR="blue"]<BuildingClasses>[/COLOR]
		<Row>
			<Type>BUILDINGCLASS_SUPREMECOURT</Type>
			<DefaultBuilding>BUILDING_SUPREMECOURT</DefaultBuilding>
			<Description>TXT_KEY_BUILDING_SUPREMECOURT</Description>
			<MaxPlayerInstances>1</MaxPlayerInstances>
		</Row>
		<Row>
			<Type>BUILDINGCLASS_HIGHCOURT</Type>
			<DefaultBuilding>BUILDING_HIGHCOURT</DefaultBuilding>
			<Description>TXT_KEY_BUILDING_HIGHCOURT</Description>
		</Row>
		<Row>
			<Type>BUILDINGCLASS_MAGISTRATECOURT</Type>
			<DefaultBuilding>BUILDING_MAGISTRATECOURT</DefaultBuilding>
			<Description>TXT_KEY_BUILDING_MAGISTRATECOURT</Description>
		</Row>
	[COLOR="red"]<Buildings>[/COLOR]
		<Row>
			<Type>BUILDING_SUPREMECOURT</Type>
			<BuildingClass>BUILDINGCLASS_SUPREMECOURT</BuildingClass>
			<Cost>220</Cost>
			<PrereqTech>TECH_CODE_OF_LAWS</PrereqTech>
			<Help>TXT_KEY_WONDER_SUPREMECOURT_HELP</Help>
			<Description>TXT_KEY_BUILDING_SUPREMECOURT</Description>
			<Civilopedia>TXT_KEY_WONDER_SUPREMECOURT_DESC</Civilopedia>
			<Strategy>TXT_KEY_BUILDING_SUPREMECOURT_STRATEGY</Strategy>
			<ArtDefineTag>NONE</ArtDefineTag>
			<PolicyCostModifier>-10</PolicyCostModifier>
			<NukeImmune>true</NukeImmune>
			<UnmoddedHappiness>4</UnmoddedHappiness>
			<HurryCostModifier>-1</HurryCostModifier>
			<MinAreaSize>10</MinAreaSize>
			<ConquestProb>100</ConquestProb>
			<IconAtlas>JFDBUILDINGATLAS</IconAtlas>
			<PortraitIndex>0</PortraitIndex>
		</Row>
		<Row>
			<Type>BUILDING_HIGHCOURT</Type>
			<BuildingClass>BUILDINGCLASS_HIGHCOURT</BuildingClass>
			<Cost>130</Cost>
			<PrereqTech>TECH_CODE_OF_LAWS</PrereqTech>
			<Help>TXT_KEY_HIGHCOURT_HELP</Help>
			<GoldMaintenance>3</GoldMaintenance>
			<Description>TXT_KEY_BUILDING_HIGHCOURT</Description>
			<Civilopedia>TXT_KEY_HIGHCOURT_DESC</Civilopedia>
			<Strategy>TXT_KEY_BUILDING_HIGHCOURT_STRATEGY</Strategy>
			<BuildingProductionModifier>15</BuildingProductionModifier>
			<Happiness>2</Happiness>
			<ArtDefineTag>NONE</ArtDefineTag>
			<MinAreaSize>-1</MinAreaSize>
			<HurryCostModifier>25</HurryCostModifier>
			<ConquestProb>0</ConquestProb>
			<IconAtlas>JFDBUILDINGATLAS</IconAtlas>
			<PortraitIndex>1</PortraitIndex>
		</Row>
		<Row>
			<Type>BUILDING_MAGISTRATECOURT</Type>
			<BuildingClass>BUILDINGCLASS_MAGISTRATECOURT</BuildingClass>
			<Cost>90</Cost>
			<PrereqTech>TECH_WRITING</PrereqTech>
			<Help>TXT_KEY_MAGISTRATECOURT_HELP</Help>
			<GoldMaintenance>2</GoldMaintenance>
			<Description>TXT_KEY_BUILDING_MAGISTRATECOURT</Description>
			<Civilopedia>TXT_KEY_MAGISTRATECOURT_DESC</Civilopedia>
			<Strategy>TXT_KEY_BUILDING_MAGISTRATECOURT_STRATEGY</Strategy>
			<BuildingProductionModifier>10</BuildingProductionModifier>
			<Happiness>1</Happiness>
			<ArtDefineTag>NONE</ArtDefineTag>
			<MinAreaSize>-1</MinAreaSize>
			<HurryCostModifier>25</HurryCostModifier>
			<ConquestProb>0</ConquestProb>
			<IconAtlas>JFDBUILDINGATLAS</IconAtlas>
			<PortraitIndex>2</PortraitIndex>
		</Row>
	[COLOR="green"]<Building_PrereqBuildingClasses>[/COLOR]
		<Row>
			<BuildingType>BUILDING_SUPREMECOURT</BuildingType>
			<BuildingClassType>BUILDINGCLASS_HIGHCOURT</BuildingClassType>
			<NumBuildingNeeded>-1</NumBuildingNeeded>
		</Row>
	[COLOR="green"]</Building_PrereqBuildingClasses>[/COLOR]
	[COLOR="red"]</Buildings>[/COLOR]
	[COLOR="blue"]</BuildingClasses>[/COLOR]
</GameData>
Here is an example of a common error made with the <Language_en_US> table:
Spoiler :
Code:
<GameData>
	[COLOR="Red"]<Traits>[/COLOR]
		<Language_en_US>
			<Row Tag="TXT_KEY_TRAIT_BLAH">
				<Text>This Triat is really [COLOR_POSITIVE_TEXT]blah[ENDCOLOR], plus I may have misspelled Trait more than once, I think.</Text>
			</Row>
			<Row Tag="TXT_KEY_TRAIT_BLAH_SHORT">
				<Text>The Blah Trait</Text>
			</Row>
		</Language_en_US>
	[COLOR="red"]</Traits>[/COLOR]
</GameData>
  • <Language_en_US> is its own stand-alone table and is never "wrapped" or "encapsulated" within another table.
  • The result is that instead of The Blah Trait, what is seen in-game is TXT_KEY_TRAIT_BLAH_SHORT.
  • Whenever you see in-game a display of TXT_KEY_BLAH_SOMETHING it is an indication there is an error occuring in the file where you have your Language_en_US rows. It indicates that the building, civ, unit, policy, trait, etc., is functioning properly but that there's a mistake that is causing the game to discard the whole file where the <Language_en_US> definitions of what text to display in-game are made.

You should always write your XML files in the following basic outline:
Spoiler :
Code:
<GameData>
	<TableNameAsUsedExactlyTheWayFiraxisDid>
		<Row>
			<ColumnNameShownExactlyAsFiraxisDidWithinTheTable>[COLOR="red"]data[/COLOR]</ColumnNameShownExactlyAsFiraxisDidWithinTheTable>
			<AnotherColumnNameShownExactlyAsFiraxisDidWithinTheTable>[COLOR="red"]data[/COLOR]</AnotherColumnNameShownExactlyAsFiraxisDidWithinTheTable>
		</Row>
	</TableNameAsUsedExactlyTheWayFiraxisDid>

	<AnotherTableNameAsUsedExactlyTheWayFiraxisDid>
		<Row>
			<ColumnNameShownExactlyAsFiraxisDidWithinTheTable>[COLOR="red"]data[/COLOR]</ColumnNameShownExactlyAsFiraxisDidWithinTheTable>
			<AnotherColumnNameShownExactlyAsFiraxisDidWithinTheTable>[COLOR="red"]data[/COLOR]</AnotherColumnNameShownExactlyAsFiraxisDidWithinTheTable>
		</Row>
	</AnotherTableNameAsUsedExactlyTheWayFiraxisDid>
</GameData>

* data as shown can be an integer value, such as "10", or a boolean such as "true" or "false", or a reference such as "YIELD_CULTURE".


Return to top of Post
Return to the list of Internal Navigation Links

(9) INCORRECTLY USING COLUMN NAMES

The mistake takes multiple specific forms, but is all essentially the same mistake. The root of this mistake is in misunderstanding how the game works. The more-specific versions of this overall mistake are:
  1. Using a Column Name in the Wrong Game Table
  2. Incorrectly Spelled or Capitalized column names. This has the exact same effect on the mod as # 1.
  3. "Inventing" column names
  4. Re-use of a <ColumnName> within the same <Row>
  5. Dangling a column outside of a table and/or a row.
Taking each of these in turn, starting with #1:

  • Every column that is used in a game table is pre-defined to belong within that game table. And in and of itself, the text that is seen within an XML file as provided by Firaxis really does not do anything. The DLL/C++ and lua programs that Firaxis also provided as part of the game essentially look through the XML and take actions based on what the XML is set to for a building or a unit or a leader trait. If Firaxis did not add anything to the DLL/C++ and lua programs for a column named <Largosity> within the <Policies> table, then nothing will happen if you stick a column called <Largosity> into a policy. The game simply won't have any pre-definition of it, nor any instructions on what to do with it, so it will simply discard the entire file where it sees such a thing.
  • You cannot therefore take a column from one game table and stick it into another game table.
  • The table definitions that were provided by Firaxis are there as guides as to what is acceptable within each game table. Here is the definition of a game table:
    Code:
    <Table name="Domains">
    	<Column name="ID" type="integer" primarykey="true" autoincrement="true"/>
    	<Column name="Type" type="text" notnull="true" unique="true"/>
    	<Column name="Description" type="text"/>
    </Table>
    • First, this definition of the table tells us that there shall be a game table called Domains. The line
      <Table name="Domains">
      is giving us this declaration of the table name.
    • Next, a column that shall be named ID is specified for use within the table named Domains. ID is to be an integer, is to be a "primarykey", and the ID value for each row within table Domains will automatically be incremented so that no two rows will have the same integer value for ID. The line
      <Column name="ID" type="integer" primarykey="true" autoincrement="true"/>
      is giving us this declaration of the column name ID.
    • Third, a column that shall be named Type is specified for use within the table named Domains. Type is to be "text" as opposed to a number or true/false. By "text" is meant stuff like DOMAIN_LAND and DOMAIN_SEA. Column Type can never be omitted, and must be given a valid value (notnull="true"). Also, every row must have a unique text string for column Type. The line
      <Column name="Type" type="text" notnull="true" unique="true"/>
      is giving us this declaration of the column name Type.
    • Last, a column that shall be named Description is specified for use within the table named Domains. Description is to be "text" as opposed to a number or true/false. By "text" is meant stuff like TXT_KEY_DOMAIN_LAND. We know this last bit about "text" meaning a TXT_KEY_SOMETHING designation instead of something like BUILDING_WALLS or DOMAIN_AIR from accumulated experience and trial and error. Anywhere you see a column named Description with a type="text" what the game wants is a TXT_KEY_SOMETHING tag name that it can look up in the appropriate user's language database to know what in-game name should be displayed. The line
      <Column name="Description" type="text"/>
      is giving us this declaration of the column name Description.
    • The line </Table> simply closes out the definition of the table named Domains.
We cannot throw anything into the table Domains that does not show in this definition of the table. Nor can we really copy anything we find in Domains and assume it will work in any other game table. Nor can we assume that because two different game tables both have a column named Type they will function in the same way in both game tables. They may (and Type often does), or they may not. For example, FreeBuilding occurs in both the Traits and the Buildings game tables, but the columns work in very different ways for Traits as compared to Buildings.
  • Incorrectly Spelled or Capitalized column names.
So far as the game is concerned the net effect of this is the same as Using a Column Name in the Wrong Game Table. The game software, like all computer programs, is literal. Close doesn't count: exactitude is required.

These are incorrect:
Code:
<buildingtype>
<BuildingTypes>
<NumbuildingsNeeded>
These are the correct versions:
Code:
<BuildingType>
<NumBuildingNeeded>
  • "Inventing" column names
Once again, so far as the game is concerned the net effect of this is the same as Using a Column Name in the Wrong Game Table.

The root cause in this case is different, however, and stems from misunderstanding how the game software works. It is a common mistake made by inexperienced mod-creators to think that the game software is in some way dynamically adaptive to whatever XML code is thrown into a game table. When an inexperienced mod-creator sees a column name such as FaithFromUnimprovedForest within the Traits table, they believe that the Forest portion of the column name is what is adding the Faith, and therefore if they change Forest to Jungle they can get the same effect for jungle tiles as for forest tiles if they use this code as part of a new leader trait:
Code:
<FaithFromUnimprovedJungle>true</FaithFromUnimprovedJungle>
But this does not work for the reasons outlined in the dicussion on Using a Column Name in the Wrong Game Table
  • Re-use of a <ColumnName> within the same <Row>
This will always cause the game to discard the entire file where the mistake occurs. You should look for errors such as this:
Code:
<GameData>
	<Building_YieldChanges>
		<Row>
			<BuildingType>BUILDING_CASTLE</BuildingType>
			[COLOR="red"]<BuildingType>BUILDING_GRANARY</BuildingType>[/COLOR]
			<YieldType>YIELD_GOLD</YieldType>
			<Yield>3</Yield>
		</Row>
		<Row>
			<BuildingType>BUILDING_WALLS</BuildingType>
			<YieldType>YIELD_GOLD</YieldType>
			<Yield>3</Yield>
			[COLOR="red"]<YieldType>YIELD_FOOD</YieldType>
			<Yield>2</Yield>[/COLOR]
		</Row>
	<Building_YieldChanges>
</GameData>
In the first <Row>, an attempt is made to state that both BUILDING_CASTLE and BUILDING_GRANARY should be given a yield of 3 gold per turn. This fails because only one <BuildingType> Column can occur within one set of <Row> -- </Row>. It has to be broken up into two distinct Rows for the game to accept it, as:
Code:
<GameData>
	<Building_YieldChanges>
		<Row>
			<BuildingType>BUILDING_CASTLE</BuildingType>
			<YieldType>YIELD_GOLD</YieldType>
			<Yield>3</Yield>
		</Row>
		<Row>
			<BuildingType>BUILDING_GRANARY</BuildingType>
			<YieldType>YIELD_GOLD</YieldType>
			<Yield>3</Yield>
		</Row>
	<Building_YieldChanges>
</GameData>
In the second erroneous Row shown above, an attempt is made to state that BUILDING_WALLS should be given a yield per turn of both 3 gold and 2 Food. Even if it were stated as this it would be no good because it would be an attempt to state two different <YieldType>s within the same Row:
Code:
<GameData>
	<Building_YieldChanges>
		<Row>
			<BuildingType>BUILDING_WALLS</BuildingType>
			<YieldType>YIELD_GOLD</YieldType>
			[COLOR="Red"]<YieldType>YIELD_FOOD</YieldType>[/COLOR]
			<Yield>3</Yield>
		</Row>
	<Building_YieldChanges>
</GameData>
The only way it can work is for the two Yield Types to be stated in distinct and independant Rows within the table, as in this:
Code:
<GameData>
	<Building_YieldChanges>
		<Row>
			<BuildingType>BUILDING_WALLS</BuildingType>
			<YieldType>YIELD_GOLD</YieldType>
			<Yield>3</Yield>
		</Row>
		<Row>
			<BuildingType>BUILDING_WALLS</BuildingType>
			<YieldType>YIELD_FOOD</YieldType>
			<Yield>2</Yield>
		</Row>
	<Building_YieldChanges>
</GameData>
  • Dangling a column outisde of a table and/or a row.
There are two methods by which this mistake occurs:
  • Outside of a Row but within a Table:
    This is the sort of error made:
    Code:
    <GameData>
    	<Building_YieldChanges>
    		<Row>
    			<BuildingType>BUILDING_WALLS</BuildingType>
    			<YieldType>YIELD_GOLD</YieldType>
    			<Yield>3</Yield>
    		</Row>
    
    			[color="red"]<BuildingType>BUILDING_WALLS</BuildingType>[/color]
    
    	<Building_YieldChanges>
    </GameData>
  • Outside of any table reference whatsoever:
    This is the sort of error made:
    Code:
    <GameData>
    	<Building_YieldChanges>
    		<Row>
    			<BuildingType>BUILDING_WALLS</BuildingType>
    			<YieldType>YIELD_GOLD</YieldType>
    			<Yield>3</Yield>
    		</Row>
    	<Building_YieldChanges>
    
    	[color="red"]<BuildingType>BUILDING_WALLS</BuildingType>[/color]
    
    </GameData>
In both cases the portions shown in red will cause the game to discard the entire file where the error occurs. To fix these errors, which are almost always caused by copy-paste-edit mistakes, simply eliminate the offending code. It should also be noted that these are the types of errors that will show in ModBuddy when the XML file is viewed within the SDK.

Return to top of Post
Return to the list of Internal Navigation Links

(10) Use of Yields in tables where YIELD_X is not usable

Because of the methods used by Firaxis to implement the game software and the XML system, not all yield types are valid for all tables within the game. Use of the wrong yield-type within a game table does not cause fatal failure of the XML file where this mistake occurs, but it does result in unimplemented game effects. An example of this is using YIELD_FAITH or YIELD_CULTURE in any of the tables <Building_YieldModifiers>, <Building_YieldChangesPerPop>, or <Building_GlobalYieldModifiers>. This code will simply be ignored by the game, but will not cause the XML file where it occurs to be discarded:
Code:
<GameData>
	<Building_GlobalYieldModifiers>
		<Row>
			<BuildingType>BUILDING_NEW_BUILDING</BuildingType>
			[COLOR="Red"]<YieldType>YIELD_CULTURE</YieldType>[/COLOR]
			<Yield>15</Yield>
		</Row>
	</Building_GlobalYieldModifiers>
	<Building_YieldModifiers>
		<Row>
			<BuildingType>BUILDING_NEW_BUILDING</BuildingType>
			[COLOR="red"]<YieldType>YIELD_FAITH</YieldType>[/COLOR]
			<Yield>15</Yield>
		</Row>
	</Building_YieldModifiers>
	<Building_YieldChangesPerPop>
		<Row>
			<BuildingType>BUILDING_NEW_BUILDING</BuildingType>
			[COLOR="red"]<YieldType>YIELD_CULTURE</YieldType>[/COLOR]
			<Yield>50</Yield>
		</Row>
	</Building_YieldChangesPerPop>
</GameData>
  • For the <Building_GlobalYieldModifiers> and YIELD_CULTURE, simply use <GlobalCultureRateModifier>15</GlobalCultureRateModifier> directly within the <Buildings> table. But for the other two incorrect usages shown there is no simple direct method that can be used with XML only to achieve the desired effect.
  • There are references available that cover specific issues related to which yields can be used within which tables, but unfortunately there is no one single reference thread, tutorial, or page on the modwiki (so far as I am aware) that both includes all game tables and is up to date. For BNW and buildings/wonders you can refer to the tutorial in the top link of my signature.
  • The members of the CivFanatics community have created a unified yields dll mod that fixes these holes within the game system. This is the Unified Yields DLL Mod Discussion Thread, but I am not sure if it is 100% complete and ready for use. It is a massive undertaking, and may not yet be completed. It should be noted, however, that there can only be one modded DLL file active within the game at any one time.

Return to top of Post
Return to the list of Internal Navigation Links

(11) Use of YIELD_HAPPINESS and YIELD_TOURISM

This cannot be done in any game table. They are not yields as defined by the game. Attempts to jam them into a game table will simply be ignored by the game.​

COMMON SYNTAX ERRORS MADE WITHIN XML FILES will be continued in next post​
 
(COMMON SYNTAX ERRORS THAT OCCUR WITHIN XML FILES continued from previous post)​


(12) SHOWING TABLE DEFINITIONS WITHIN AN XML-FILE

Never include the Firaxis-supplied definitions of game tables in your mods. The game (1st) does not need them, and (2nd) does not want them to be repeated. In fact, including repeats of table definitions will cause the game to discard the entire file where such a table definition occurs. In XML error # 9 I showed the definition of a game table, and I repeat it here so that it will be more clear what I am talking about:
Code:
<Table name="Domains">
	<Column name="ID" type="integer" primarykey="true" autoincrement="true"/>
	<Column name="Type" type="text" notnull="true" unique="true"/>
	<Column name="Description" type="text"/>
</Table>
If your mod has any of these in any of its XML files, eliminate them.

Spoiler note :
If your intention is to add an entirely new game-table to the game, then you can and should have the definition of the new table at the top of one of your XML files. This will instruct the game that it has a new game-table, and will get the game ready to recieve information for that new game-table. However, in order to get anything to happen as a result of you adding a new game table you will need to also have within your mod at the very least an lua file telling the game what to do with this new information, and when. Without the lua file to tell the game what and when to do something with the new game table, all you will be doing is to add worthless clutter to the game's database of XML.

Here's the Important Bit:
If you are referring to this guide for help with mistakes that novice mod-creators often make, I would suggest you are not ready to try adding a new table to the game, nor adding the required lua or dll programming to make the new game table function.​

Return to top of Post
Return to the list of Internal Navigation Links

(13) REPEATING OF LANGUAGE TABLE "TAGS" WITHIN <ROW> COMMANDS

The game just absolutely hates repeats of bits of XML code it already has. This is quadrupled with regard to any of the Tag="TXT_KEY_SOMETHING" commands found in any of the language tables. If you have even one Tag="TXT_KEY_SOMETHING" that is an exact repeat of one the game already has, the game will discard the entire file where it finds this repeat. Any code that loads before your code will cause this failure if it contains an exactly matching Tag="TXT_KEY_SOMETHING".

What is meant by "any code that loads before your mod" ?
  1. All of the code from the base game, for all three expansions.
  2. All of the code from any DLCs.
  3. All of the code from any mod that loads into the game before your mod loads.
What is meant by "Repeat of Tag="TXT_KEY_SOMETHING"" ?

The short-list answer is giving the game a new <Row> with a Tag="TXT_KEY_SOMETHING" that has already occured within the base game or within some other mod, like this:
Code:
<GameData>
	<Language_en_US>
		<Row Tag="TXT_KEY_ENCHILLADAS">
			<Text>Enchilladas</Text>
		</Row>
	</Language_en_US>
</GameData>
This will be fine so long as the base game, all DLC, and all previously loaded mods do not already have a tag called TXT_KEY_ENCHILLADAS. If even one of them does, then not only will my <Row> fail to load, the entire file where my <Row> occurs will be discarded by the game.

What can be done to circumvent this problem ?
  • Make your TXT_KEYS_ more unique. JFD pretty much always adds his initials somewhere within any TXT_KEY name he uses, so instead of TXT_KEY_ENCHILLADAS, he would use TXT_KEY_JFD_ENCHILLADAS. This gives far more assurance that there will not be a repeat TXT_KEY tag name issue.
  • When altering the text to be displayed in-game for a building, unit, policy, etc., that Firaxis provided, do not use <Row>. Use <Update> instead. I will not do this:
    Code:
    <GameData>
    	<Language_en_US>
    		<Row Tag="TXT_KEY_BUILDING_COLOSSUS">
    			<Text>Statue of Colossus</Text>
    		</Row>
    	</Language_en_US>
    </GameData>
    I will do this:
    Code:
    <GameData>
    	<Language_en_US>
    		<Update>
    			<Where Tag="TXT_KEY_BUILDING_COLOSSUS">
    			<Set Text="Statue of Colossus" />
    		</Update>
    	</Language_en_US>
    </GameData>
    • Remember that it is the repeat of the Tag="TXT_KEY_BUILDING_COLOSSUS" that causes the code failure, and not anything within the <Text> wraps.
    • The <Row> method does not work because with <Row> you are telling the game to add a new Tag to its database of Tags. But it cannot add a new Tag if the same Tag name already exists.
    • The <Update> method works because with <Update> you are instructing the game to change an existing Tag. The game is structured to accept such changes to its previously-defined information.

Return to top of Post
Return to the list of Internal Navigation Links

(14) NOT USING <UPDATES> AND INSTEAD RE-STATING THE <ROW> WITH CHANGES


  • Alluded to earlier here.
  • You should never re-state a Row that already exists within a table, and merely give it new values. The following is already part of the base game's XML:
    Code:
    <GameData>
    	<Building_DomainFreeExperiences>
    		<Row>
    			<BuildingType>BUILDING_BARRACKS</BuildingType>
    			<DomainType>DOMAIN_LAND</DomainType>
    			<Experience>15</Experience>
    		</Row>
    	</Building_DomainFreeExperiences>
    </GameData>
    If I wish to change the amount of experience a barracks gives to land units, I do not do the following:
    Code:
    <GameData>
    	<Building_DomainFreeExperiences>
    		<Row>
    			<BuildingType>BUILDING_BARRACKS</BuildingType>
    			<DomainType>DOMAIN_LAND</DomainType>
    			<Experience>25</Experience>
    		</Row>
    	</Building_DomainFreeExperiences>
    </GameData>
    I must do as follows:
    Code:
    <GameData>
    	<Building_DomainFreeExperiences>
    		<Update>
    			<Where BuildingType="BUILDING_BARRACKS" DomainType="DOMAIN_LAND" />
    			<Set Experience="25" />
    		</Update>
    	</Building_DomainFreeExperiences>
    </GameData>

Return to top of Post
Return to the list of Internal Navigation Links[/INDENT]
 
Understanding "Table", Column", "Row"

This is the definition of a "table" called "Yields":
Code:
<Table name="Yields">
	<Column name="ID" type="integer" primarykey="true" autoincrement="true"/>
	<Column name="Type" type="text" notnull="true" unique="true"/>
	<Column name="Description" type="text"/>
	<Column name="IconString" type="text"/>
	<Column name="HillsChange" type="integer" default="0"/>
	<Column name="MountainChange" type="integer" default="0"/>
	<Column name="LakeChange" type="integer" default="0"/>
	<Column name="CityChange" type="integer" default="0"/>
	<Column name="PopulationChangeOffset" type="integer" default="0"/>
	<Column name="PopulationChangeDivisor" type="integer" default="0"/>
	<Column name="MinCity" type="integer"/>
	<Column name="GoldenAgeYield" type="integer" default="0"/>
	<Column name="GoldenAgeYieldThreshold" type="integer" default="0"/>
	<Column name="GoldenAgeYieldMod" type="integer" default="0"/>
	<Column name="AIWeightPercent" type="integer"/>
</Table>
Within it, "Yields" has valid column names called "ID", "Type", "Description", "IconString", "HillsChange", "MountainChange", "LakeChange", "CityChange", "PopulationChangeOffset", "PopulationChangeDivisor", "MinCity", "GoldenAgeYield", "GoldenAgeYieldThreshold", "GoldenAgeYieldMod", and "AIWeightPercent". For the purposes of the novice modder, these are all the columns that can be used within the table "Yields".* Any mod which tried to add a new type of yield would be constrained to using only these column definitions, and to present the names of these columns exactly as shown in the definition of the table. To add a new type of Yield, I would do something very like the following:
Code:
<GameData>
	<Yields>
		<Row>
			<Type>YIELD_MAGIC</Type>
			<Description>TXT_KEY_YIELD_MAGIC</Description>
			<IconString>[ICON_MAGIC]</IconString>
			<MinCity>0</MinCity>
			<AIWeightPercent>100</AIWeightPercent>
		</Row>
	</Yields>
</GameData>
There is still a lot of work I would have to do to get this new yield called "Magic" to work in-game, but so far as the basic definition of it within the "Yields" table is concerned, that's pretty much it.

What does any of this have to do with the difference between <Row>, "Table", and "Column" ?
Look at the very first line of the "Yields" table definition I quoted. It reads:
<Table name="Yields">
Everything related to the definitions of the columns goes into (or under) the definition of the name of the Table, in this case "Yields".
You may be thinking something along the lines of "Well, that stuff under <Table name="Yields"> all starts with verbiage of "Column name=", but it's pretty clear to me that those are all rows under the table named "Yields"." Actually, not so. They are being shown to you in that way so that it is easier to read them, but actually the definition of the Columns could (and probably should) have been done like this:
Code:
<Table name="Yields">	<Column name="ID" type="integer" primarykey="true" autoincrement="true"/>	<Column name="Type" type="text" notnull="true" unique="true"/>	<Column name="Description" type="text"/>	<Column name="IconString" type="text"/>	<Column name="HillsChange" type="integer" default="0"/>	<Column name="MountainChange" type="integer" default="0"/>	<Column name="LakeChange" type="integer" default="0"/>	<Column name="CityChange" type="integer" default="0"/>	<Column name="PopulationChangeOffset" type="integer" default="0"/>	<Column name="PopulationChangeDivisor" type="integer" default="0"/>	<Column name="MinCity" type="integer"/>	<Column name="GoldenAgeYield" type="integer" default="0"/>	<Column name="GoldenAgeYieldThreshold" type="integer" default="0"/>	<Column name="GoldenAgeYieldMod" type="integer" default="0"/>	<Column name="AIWeightPercent" type="integer"/>	</Table>
Similarly, the definition of a new Yield that I presented earlier really ought to be presented more like this:
Code:
<GameData>	<Yields>	<Row>	<Type>YIELD_MAGIC</Type>	<Description>TXT_KEY_YIELD_MAGIC</Description>	<IconString>[ICON_MAGIC]</IconString>	<MinCity>0</MinCity>	<AIWeightPercent>100</AIWeightPercent>	</Row>	</Yields>	</GameData>
But that's nigh on to impossible to read, though so far as the game is concerned there's no difference between the two methods for showing a new <Row> entry in the Yields table.

I can also present the same exact information in the following way:
Code:
<GameData>
	<Yields>
		<Row Type="YIELD_MAGIC" Description="TXT_KEY_YIELD_MAGIC" IconString="[ICON_MAGIC]" MinCity="0" AIWeightPercent="100" />
	</Yields>
</GameData>
Maybe this last example will make the idea of "row" and "column" within a table a bit more clear.


* this is actually a lie to which the experienced modder can attest, but let's not confuse the issue.


Return to the list of Internal Navigation Links

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Specific Mistakes

specific mistakes: (this is just a 'stub' list for now)
  1. add a new type of building but forget to add a new building-class == CTD
  2. reference a building-class within your <Buildings> definition, but forgetting to create the Building-Class within the <BuildingsClasses> table == game lock-up or CTD
    • essentially this is the same mistake as #1
  3. Assigning the same building to two different building-classes == CTD
  4. Incorrect Compression settings when converting an art-file to DDS format == often results in ugly red blob where the image or Icon ought to go
  5. Not checking the "ReloadUnitSystem" checkbox in ModBuddy == your new unit animation shows as a Spearman
  6. Not having at least two uniques (Units, Buildings, or Improvements) successfully registered with a custom civ == start game menu won't scroll through list of leaders
    • if the game discards even one of the files containing these uniques because of code or snytax errors, it is the same as not having them assigned to the civ
    • Units require an entry in the <Civilization_UnitClassOverrides> table to make them unique to a civ
    • Buildings require an entry in the <Civilization_BuildingClassOverrides> table to make them unique to a civ
    • Improvements require the column <CivilizationType> in the <Improvements> table to specify a specific civ for which the improvement will be unique
  7. For G&K and BNW, not having Spy names assigned to a civ == game crash upon entering the Renaissance Era
    • 9 Spy Names are required
  8. Using an incorrect <CombatClass> for a unit.
    • IE, using UNITCOMBAT_NAVALRANGED for a melee naval unit, or vice versa
    • The animation system keys off of the <CombatClass> rather than directly what you state for a unit's <Combat> or <RangedCombat> power.
    • See this thread, particularly Post #4, for an example of this kind of error.
    The usual result will be a CTD (Crash To Desktop) when the new unit first engages in combat.
  9. Having an incorrect reference to an fxsxml file causing 'invisible units' or CTDs or both
    • The name of the fxsxml file must be exact when presented in the 'Model' column of table 'ArtDefine_UnitMemberInfos'
      Code:
      <ArtDefine_UnitMemberInfos>
      	<Row>
      		<Type>ART_DEF_UNIT_MEMBER_KNIGHT_TEMPLAR</Type>
      		<Scale>0.15</Scale>
      		<Model>[color="blue"]Longswordsman_Templar.fxsxml[/color]</Model>
      		<MaterialTypeTag>CLOTH</MaterialTypeTag>
      		<MaterialTypeSoundOverrideTag>FLESH</MaterialTypeSoundOverrideTag>
      	</Row>
      </ArtDefine_UnitMemberInfos>
      Note that in this case the file-extension-type is reguired (.fxsxml) but file folder path within the mod is not required and is not really of much value.
    • As mentioned before, failure to check the "ReloadUnitSystem" checkbox in ModBuddy will cause a new unit to appear as a Spearman, but will not cause the 'invisible unit'.
  10. Getting all TXT_KEY_THIS and TXT_KEY_THAT instead of the correct text put in the file for In-Game Text. You have done one of the following:
    1. Repeated a Tag="TXT_KEY_SOMETHING" that the game already has
    2. Made a fatal syntax typo
    3. Never given your text file an action under the "Actions" tab of "Mod Properties".
  11. Incorrect use of Building-Class when adding a unique replacement building for a particular civilization:
    • Assigning the building to BUILDINGCLASS_X but then using BUILDING_X as the civilization's unique building for BUILDINGCLASS_Y, as in this:
      Spoiler :
      Code:
      <GameData>
      	<BuildingClasses>
      		<Row>
      			<Type>BUILDINGCLASS_[color="red"][b]X[/b][/color]</Type>
      			<DefaultBuilding>BUILDING_[color="red"][b]X[/b][/color]</DefaultBuilding>
      			<Description>TXT_KEY_BUILDING_[color="red"][b]X[/b][/color]</Description>
      		</Row>
      	</BuildingClasses>
      	<Buildings>
      		<Row>
      			<Type>BUILDING_[color="red"][b]X[/b][/color]</Type>
      			<BuildingClass>BUILDINGCLASS_[color="red"][b]X[/b][/color]</BuildingClass>
      			.....<snipped lines>.......
      			<IconAtlas>BW_ATLAS_1</IconAtlas>
      			<PortraitIndex>19</PortraitIndex>
      			<Description>TXT_KEY_BUILDING_[color="red"][b]X[/b][/color]</Description>
      		</Row>
      	</Buildings>
      	<Civilization_BuildingClassOverrides>
      		<Row>
      			<CivilizationType>CIVILIZATION_INDIA</CivilizationType>
      			<BuildingClassType>BUILDINGCLASS_[color="blue"][b]Y[/b][/color]</BuildingClassType>
      			<BuildingType>BUILDING_[color="red"][b]X[/b][/color]</BuildingType>
      		</Row>
      	</Civilization_BuildingClassOverrides>
      </GameData>
      1. The Game does not crash because of this, but it completely breaks the game's Building Class system.
      2. Policies, Beliefs, etc., that are "keyed" to reference back to a Building-Class will not recognize BUILDING_X as belonging to BUILDINGCLASS_Y and will not implement their effects upon BUILDING_X
      3. If BUILDINGCLASS_Y is a one of the Classes that act as prerequisites for other Buildings, such as BUILDINGCLASS_FACTORY, then India in this example would never be able to construct Nuclear Plants, Spaceship Factories, or Solar Plants. If BUILDINGCLASS_Y were actually BUILDINGCLASS_SHRINE, then India would never be able to build Temples or the Grand Temple. This is because the <Building_ClassesNeededInCity> table is specific to BUILDING_A requires BUILDINGCLASS_Y, and the insertion of BUILDING_X as a replacement building for the default building for India for BUILDINGCLASS_Y does not in any way alter the specification of BUILDING_X's original Building-Class. BUILDING_X can never satisfy the requirement for BUILDINGCLASS_Y.
      4. Adding additional rows within the <Building_ClassesNeededInCity> table to state that for example a Temple also can require BUILDINGCLASS_X in addition to BUILDINGCLASS_SHRINE will not work either because <Building_ClassesNeededInCity> acts as a boolean "ANDS" table, and the new requirement would be that in order to build a Temple, all civilizations now need to construct BOTH a BUILDINGCLASS_SHRINE building AND a BUILDINGCLASS_X building: No Civilization would ever be able to satisfy such a condition.
    • Other similar errors I have as yet to document
  12. Mis-spelled Technology names for a unit or building 'PrereqTech' causes the city-view "Choose Production" pop-up menu to fail

Some Common New Civilization Errors:
  1. No setting of <DefaultPlayerColor> in the definition under table <Civilizations>:
    • No Unit Actions Panel:
      Spoiler :
    • Corrupted Game Menu:
      Spoiler :
  2. No setting of <ShortDescription> in the definition under table <Civilizations>:
    • Modded Game Set Up Panel:
      Spoiler :
    • Corrupted Leader Selection Menu: (there is no scrollbar)
      Spoiler :
    • Corrupted Advanced Set-Up Menu: (the selection box for choosing a leader is empty)
      Spoiler :
    • Zoomed-In Corrupted Advanced Set-Up Menu: (the selection box for choosing a leader is empty)
      Spoiler :
    • Corrupted "Terrain and Features" Civilopedia Page:
      Spoiler :
    • Corrupted Leaders and Civilizations Civilopedia Page: (there is no scrollbar)
      Spoiler :


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Quoted from another forum member and thread the references for I need to track down again to give credit where due:

Learn how to look at the DB contents outside of Civ5!

You need SQLite Manager (an add-on to Firefox) or SQLiteSpy (a stand-alone application) or one of many other programs (see Nutty's post below) that will allow you to look at the DB contents. This is important regardless of whether you modify it using SQL or XML. It'll take you a lot less time to figure out what is in the DB by looking at it rather than trying to deduce it in-game or from the logs. The DBs are in the cache folder (same place as the MODS folder). You want the one that has "Debug" in its name ("Core" is the DB before it has been modified by any mods or DLC including expansions).

You don't need to ask. Just use SQLite Manager for Firefox or SQLiteSpy [that's the one that whoward69 uses, Paz]

[...or SQLite Database Browser or SQLite Studio or Sqliteman or SQLiteManager or SQLite Administrator...],

...then open the %userprofile%\Documents\My Games\Sid Meier's Civilization 5\cache\Civ5DebugDatabase.db file, paste your SQL into the appropriate box (the "Execute SQL" tab in SQLite Manager), and see if an error pops up; if not, take a look at the database and see if the changes were made appropriately.

Note you'll actually be making changes to the database, but when you launch CiV, it will re-populate the database. So if you're going to be trying a few things, you might want to keep a backup copy of the db file so you don't have to launch CiV to get it to reset.

EDIT: Note this is mentioned in the "Learn how to look at the DB contents outside of Civ5!" in the original post.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Some Mod Usage Problems:
  1. Having both the DLC (multiplayer) version of the NQMOD (No Quitters) and the SinglePlayer version NoQuittersMod_V7(v7) enabled at the same time has for some people disabled the ability to have Cusom Modded Civilizations in their games.
    • The Multiplayer version of this "mod" is packaged as a DLC and will be found in the player's DLC folder. Like EUI, once this "mod" is placed in the DLC folder, it is always "enabled" and can only be "shut off" by removing it entirely from the DLC folder.
    • The singleplayer version is a true mod, and is enabled or disabled via ticking and unticking the mod in the MODS menu.
    • I am not very familiar with how the multiplayer version of NQMOD works, so having it active in the DLC folder may disallow custom civilizations regardless of whether the SP (singleplayer) version is enabled.
 
If you are looking for the into that used to be here, I have moved it to This Thread, especially starting at Post #3 of that thread. When I originally posted the info here I forgot I had started that other thread some time back.
 
Top Bottom