Home › Not yet covered

Not yet covered: ripe for analysis

The game library contains more than this reference describes. These are the groups of engine classes we have seen in the function index, counted from the symbol build, that have little or no coverage here. They are leads, not results: the descriptions below are guesses from class names and nothing here has been read in detail.

Most of them follow the same pattern as the modifier effects did before they were covered: one class per named type, a small fixed set of functions each, and engine calls that can be followed. If you want to pick one up, see how to read this reference, then open the group's functions on the All functions page; corrections and contributions are welcome.

Details

AI behavior tree nodes

The building blocks of the computer players' decision trees: one class per node type (UseGreatPersonNode, SpyChooseMissionNode, BarbarianSpawnRateNode, ...) plus the tree and factory plumbing.

Why it looks ripe. Node names are the part of AI behaviour a modder can see; what each node reads, decides and calls is undocumented. Each class has a small, regular set of functions, so the method that worked for modifier effects (type name, subject, engine calls) should work here too. Whether the trees and their node parameters can be authored from game data is still to be confirmed.

AI control contracts and operations

How AI subsystems hand work to each other: contracts such as CivicResearchContract, DiplomaticActionContract, UnitRequestContract, and the AI operation, operation team and operation definition classes.

Why it looks ripe. Small groups with descriptive names. They explain how the AI turns a goal into a request, which is useful to anyone changing AI behaviour.

Gossip types

One class per gossip event (Denounced, CityFounded, ReligionFounded, SpyCaptured, ...) and the manager that collects them.

Why it looks ripe. Each type has a name hash and a handler. Listing every type with the code that raises it would show exactly when gossip fires and what it carries.

Historic moments

The ...MomentDispatcher classes that decide when a historic moment is awarded, and the moment manager.

Why it looks ripe. The trigger conditions are in the dispatcher code. A page per moment (trigger, parameters, engine calls) would answer the most common modder question about moments: why did it (not) fire.

Notification types

One class per notification type (BoostTech, ChooseCivic, ChooseArtifactPlayer, ...) and the notification manager and pools.

Why it looks ripe. Which engine events raise which notification, and what each one carries, is readable from the classes.

Diplomacy statements and actions

The diplomatic statements (DeclareFriend, DeclareWar, Denounce, Embassy, Delegation, ...) and the actions that apply their outcome (SetAllied, SetDelegation, RenewAlliance, ...).

Why it looks ripe. Shows what a statement does when accepted and which state changes follow. Matches the AI and Dev CE diplomacy functions already listed.

Quests

The quest logic classes (ClearBarbarianCamp, SendTradeRoute, TrainUnitType, RecruitGreatPersonClass, TriggerCivicBoost, ...).

Why it looks ripe. Nine classes; the conditions that complete a quest and what it rewards are all in code.

Climate events

The climate classes (Drought, Storm, OneOff, ClimateData).

Why it looks ripe. Small, and tied to the Gathering Storm disaster and climate systems, which have few written explanations.

Modifier objects

The kinds of object a modifier can be attached to or can iterate (Improvement, Alliance, ArtifactExtraction, Belief, PlotYields, CombatResults, ...).

Why it looks ripe. It is the data model behind collections and requirements, and explains the arguments they receive.

Covered, but needs verification

These have pages here, but the pages rest on inference. A contributor can add a verified result without starting from scratch.