Full Load Order Detail

This is a more complete explanation of load processing beyond the simple literal Loader and Token processing. This assumes that the GameModes have been loaded, and that a campaign is undergoing load. That front-end process is described in the Rules Persistence System and the Load Commit Subsystem.

This deals with the full (and right now necessary) order of operations for loading that occurs after the persistence files are fully loaded from disk. This describes what is happening in pcgen.persistence.SourceFileLoader.

1. An internal Ability Object to handle the Bonus Languages is constructed. This is used internally to help provide a foundation for the CHOOSE and other items necessary to support making the Bonus Language choices and granting those choices to the PC.
2. Deferred Objects are constructed, if necessary. These are items that are implied by the data, but where we have no specific construct in the data to force their construction (and forcing their construction at every reference would be hazardous). Currently this is limited to CompanionList objects.
3. Derived Objects are constructed. This includes many of the skill and spell lists, which are implied by the existance of a PCClass, but for which no specific construct in the data forces their construction. Note that we cannot do these "Live" with the Class construction, because a "KEY:" token which renamed the identifier of the PCClass would mean the identifier of the Derived Objects should be changed as well. So it is currently only safe to derive these after load is complete (and it's actually easier this way).
4. We ensure that all Ability Categories that are created are in some way used.
5. Deferred Tokens are run. Deferred Tokens are those that intend to process information on an object, but it needs to ensure that all items are loaded before the test or analysis is done. Often this is some form of error checking, such as a FACT token that is REQUIRED:YES for a given FACT ensuring that all objects of a given Format have that FACT defined. Deferred Tokens implement the DeferredToken interface.
6. Any unresolved references are identified and UnconstrutedReference errors are thrown, if necessary.
7. Any Post-Validation Tokens are run. This includes items that implement PostValidationToken, and are items run across MULTIPLE OBJECTs. These tokens are provided all objects of a given type. This can validate things like "Is there only one SIZE with "DEFAULTSIZE:YES" which are impossible to answer looking one object at a time.
8. Any Post-Deferred Tokens are run. These tokens implement the PostDeferredToken interface, and require a fully validated dataset where CDOMReference objects are resolved before they are run. This will do cross-token checks (such as MULT:YES and CHOOSE: travel together), but are only processing one object at a time. As a note, if it is possible, the DeferredToken interface is preferable to the PostDeferredToken interface.
9. We validate that the new formula system has a full set of defaults that can be resolved without external dependencies. This has to be done post-resolution since a default (ALIGNMENT is None) might be an object, and we need that reference to have been filled before we test that the default can be properly processed without external dependencies. (Meaning it needs to not have external dependencies AT RUNTIME, it is welcome to have a dependency on a part of the data which will be static at runtime).
10. We validate that any reference where a choice was included (e.g. an Exotic Weapon Proficiency FEAT chooses a Weapon Proficiency)... this will detect if someone attempted to grant a CHOOSE including ability without a choice (or provided a choice to an Ability that didn't have a CHOOSE).
11. Choices on EquipmentModifiers are processed to ensure they are correctly applied.
12. We validate that all weapons have either TYPE:Melee or TYPE:Ranged
13. We Auto Generate Equipment (if enabled)
14. We initialize any Data Set Facets with required information about the loaded data.