An "ability" is a named entry in an Ability file. Technically, they are actually stored on the EquipmentHead objects, since the modifiers like +1 (or whatever) are technically attached to the Head, and not to the entire piece of Equipment.Ībility Selections and Ability Life Cycle Since Equipment is still cloned between instances, EquipmentModifiers are stored on the Equipment. When an EquipmentModifier is added through the EQMOD tokens on Equipment, then the result of the selection is provided in brackets in the token, e.g. When an EquipmentModifier is interactively added to a piece of Equipment (in the Equipment Builder), the user is forced to make a choice, if necessary. From a code perspective, it is effectively a Map or Map (although the actual location of the association is in a Facet, e.g. When a selection is made, the result is stored as an association to the Race or Template. This is a race condition we do not intend to fix, as in many cases, the question tryign to be answered cannot be rationally answered at that point in the code. Note also with CHOOSE: on Race that certain information may not yet exist in the PC in order to make certain choices available. Note that there is some inherent danger in this design: If the system is trying to add a Race or a Template to a PC in a moment when it is not interactive with the user, then the result is not defined, and may result in a crash. (Meaning you can't do TEMPLATE:MyTemplate(ChooseResult) and expect it to make the ChooseResult selection from the CHOOSE: token. It is currently not possible to assign the result of a CHOOSE: to a Race or Template when applying the Race or Template in a non-interactive fashion. If it does, a chooser is fired, and the user is forced to make a selection. When a Template or Race is added to the PC, it is checked to determine if it has a CHOOSE: token. Equipment Modifiers also can use a different set of CHOOSE: tokens. Templates and Races use CHOOSE: (no MULT: allowed). Abilities, for example, use a CHOOSE: token and MULT:YES to indicate this situation. Spells are not granted, they have a different life cycle, which involves known and memorized.Ĭertain types of objects may need a choice to be made as they are added to a PC. Items like stats (PCStat objects) are universally granted Skills are granted if they have at least one rank other objects like Race are granted directly. When an object is attached enough to the Player Character in order to change that PC, we refer to that as "granting" the object to the PC. Things can also be prohibited with items like Prerequisites and Requirements. This is possible with things like the list of Bonus Languages, Class Skill Lists, and Class Spell Lists. In the process of adding items to a Player Character, an Object (like a Language) can be in a number of possible states.įirst, it can be "Available". 3.3.5 A Countercase to using CHOOSE:ABILITY.3.3.4.1 An Example showing the subtlety.3.3 Ability Selections and Ability Life Cycle.
0 Comments
Leave a Reply. |