Hard-coded table IDs and Type strings in dll (reference under construction...)

Hard-coded table items used in the dll play hell with modders that do a lot of table changes, particularly total conversion modders. Knowing what is and isn't hard-coded is important whether you are a dll or non-dll modder.

Many items are hard-coded as enums in the dll. But in most cases these enums are never used so it is safe to change corresponding table items (just remember to use, for example, GameInfoTypes.IMPROVEMENT_FARM rather than ImprovementTypes.IMPROVEMENT_FARM if you modify the Improvements table). When these enums are used in dll, then it is important that your table IDs match the corresponding enum integer used in dll.

In other cases, the dll doesn't use an enum but instead uses the actual type string (e.g., "UNIT_WORKER"). In these cases, table ID doesn't matter but you do need the exact matching type string for the dll to recognize it.

I've listed hard-coding cases below and which situation (above) applies. This is not guarantied to be complete. Please post if you know of items that should be added.

Hard-coded in dll by table ID integer mad: The worst kind because you won't find in dll source by text search)
Builds
14 (BUILD_REMOVE_JUNGLE) --these 4 in CvUnitMission:ushMission, look for "// todo: future proof this"
15 (BUILD_REMOVE_FOREST) --you have to recode dll or else avoid changing these 4 table IDs
16 (BUILD_REMOVE_MARSH)
17 (BUILD_SCRUB_FALLOUT)

Hard-coded enums actually used in dll (Your table ID must match base to work properly. Don't delete and don't change IDs!)
FEATURE_<ICE thru FALLOUT> (ID 0-6) --these are hard-coded in many places (including the graphics engine)
YIELD_ ...
TERRAIN_ ...
PLOT_ ...
ROUTE_ ...
DOMAIN_ ...
UNITAI_ ...
MINOR_CIV_TRAIT_ ... --note name inconsistency with table: MINOR_CIV_TRAIT_RELIGIOUS vs. MINOR_TRAIT_RELIGIOUS

Notes: Many more enums are defined in dll and passed to Lua, but can be safely ignored as long as you always use GameInfoTypes rather than the type-specific identifiers (e.g., BeliefTypes, ImprovementTypes, etc.). For enums that are used in dll, don't screw up corresponding table IDs by deleting! However, you can in some cases add to these tables. For example, I add several new minor civ traits that have effects only on the Lua side. The dll only checks for the types that it knows when applying trait effects, and safely skips over new ones.

Hard-coded by table Type string (Table ID doesn't matter, but exact Type string does. Most of these can be deleted, but their presence in this table should worry you enough to investigate further.)
Buildings
"BUILDING_WRITERS_GUILD" --next 3 in CvEconomicAI
"BUILDING_ARTISTS_GUILD"
"BUILDING_MUSICIANS_GUILD"
"BUILDING_BROADCAST_TOWER" --in CvCultureClasses
Features (note: also above so that section's more restrictive warnings apply)
"FEATURE_JUNGLE" --same CvUnitMission:ushMission code that used Builds IDs above
"FEATURE_FOREST"
"FEATURE_MARSH"
"FEATURE_FALLOUT"
Units
"UNIT_WORKER" --many references in AI code (note: renamed worker units mostly do work; but some AI logic missing)
"UNIT_WRITER" -- next 3 in CvPlayerTraits::ChooseMayaBoost only (safe to remove if you don't use Maya trait)
"UNIT_MUSICIAN"
"UNIT_GREAT_ADMIRAL"
"UNIT_ENGINEER" -- next 4 in ChooseMayaBoost and also in CvPlayerAI
"UNIT_GREAT_GENERAL"
"UNIT_ARTIST"
"UNIT_MERCHANT"
"UNIT_SCIENTIST"
"UNIT_PROPHET" -- in ChooseMayaBoost and in CvReligionClasses
"UNIT_INQUISITOR" -- next 2 in CvReligionClasses
"UNIT_MISSIONARY" --(note from personal experience: will CTD if you don't have this unit and enhance a religion!)
"UNIT_CARAVAN" --these 2 in CvTradeClasses
"UNIT_CARGO_SHIP"
"UNIT_JAPANESE_SAMURAI" --in CvUnit
"UNIT_ARCHAEOLOGIST" --in CvEconomicAI
Others used in many instances
"AICITYSTRATEGY_ ..."
"ECONOMICAISTRATEGY_ ..."
"MILITARYAISTRATEGY_ ..."

Note: I'm skipping all references that are used only for achievements.

List above is for BNW dll. Note that four features are listed in both section 2 and 3. That means that if you change IDs for these, parts of the dll will be OK with the ID change (section 3) but other parts will be screwed up (section 2). In other words, it will be screwed up.


This is really just a starting point in figuring out if you can safely delete a unit, or supply a different unit that is supposed to have some base functionality (e.g., worker). For example, it's perfectly safe to delete UNIT_JAPANESE_SAMURAI. On the other hand, if you delete UNIT_MISSIONARY, then you will get a CTD if/when you use Lua to enhance a religion. My own mod has >1 worker units ("workers" and "slaves" for 3 fantasy races) and these mostly work in unmodded dll despite references. But some AI logic (like scrapping) is missing, so proper implementation requires some dll re-coding. Non-dll modders have to carefully step around these issues.

My DLL "corrects" all the references to Unit/Building types to classes - search for "CLASS_NOT_" and you get the following list (ignoring those in achievements)

CvUnit
UNIT_JAPANESE_SAMURAI

CvTraitClasses (CvPlayerTraits::ChooseMayaBoost)
UNIT_PROPHET
UNIT_ENGINEER
UNIT_SCIENTIST
UNIT_ARTIST
UNIT_MERCHANT
UNIT_GREAT_GENERAL
UNIT_WRITER
UNIT_MUSICIAN
UNIT_GREAT_ADMIRAL

CvTradeClasses
UNIT_CARAVAN
UNIT_CARGO_SHIP

CvReligionClasses
UNIT_PROPHET
UNIT_MISSIONARY
UNIT_INQUISITOR

CvPlayerAI
UNIT_ENGINEER
UNIT_GREAT_GENERAL
UNIT_ARTIST
UNIT_MERCHANT
UNIT_SCIENTIST

CvMinorCivAI
UNIT_WORKER

CvGame
UNIT_WORKER

CvEconomicAI
UNIT_ARCHAEOLOGIST
UNIT_WORKER
BUILDING_WRITERS_GUILD
BUILDING_ARTISTS_GUILD
BUILDING_MUSICIANS_GUILD

CvCultureClasses
BUILDING_BROADCAST_TOWER

The other enums used in the DLL in lots of places, that modders may consider deleting/adding the database tables, are

TERRAIN_
PLOT_
ROUTE_
DOMAIN_
UNITAI_

Is it not possible (for non-graphical stuff anyways) to create a new enum of our own and remap entries from the old one to the new one? So for instance if we wanted new UnitAIs we could create a CvModdersUnitAI enum, and replace references to UNITAI_SOMETHING with MODDERSUNITAI_SOMETHING?

ls612 said:

Is it not possible (for non-graphical stuff anyways) to create a new enum of our own and remap entries from the old one to the new one? So for instance if we wanted new UnitAIs we could create a CvModdersUnitAI enum, and replace references to UNITAI_SOMETHING with MODDERSUNITAI_SOMETHING?

Click to expand...

That's probably a good solution (for us) in some cases. But we can't solve "UNIT_WORKER" that way because we have 6 different worker units (a "worker" and "slave" for each of 3 races). I think the only solution there is a new table tag in Units: "IsWorker" and recoding dll to use that (added as new item in To Do list).

[moot]

If you're looking to add a new yield, the NUM_YIELD_TYPES enum value is used to initialize a lot of arrays DLL-side (and reading them when saving/loading), so added yields will either not be recorded (best case), crash every time, or crash *just some of the time* depending on some yield-related code not being properly guarded (fun case). As a part of my mod I've changed it so there's a GC.GetNumYieldInfos() (like there is for every other info) but haven't switched over all enum usages (yet).

Added YIELD_ ... to list. IIRC, they are all referenced somewhere (can't check now but I'm 90% sure that's true).