|
|
| (One intermediate revision by the same user not shown) |
| Line 174: |
Line 174: |
| | =Actual Proposals= | | =Actual Proposals= |
| | | | |
| − | ==CHOOSE:PCSTAT==
| + | [[Type Safe Constant Proposals]] |
| | | | |
| − | SUBTOKEN: PCSTAT (new)<br>
| + | [[Simple CDOMObject Proposals]] |
| − | SUBTOKEN: STAT (deprecated by this proposal)<br>
| |
| | | | |
| − | Reason for deprecation: The Challenge with the existing CHOOSE:STAT is that it is negative. Meaning, CHOOSE:STAT|STR means to allow a choice of any STAT except STR. This seems a bit weird, and I would like to get away from this.
| + | [[Qualified CDOMObject Proposals]] |
| | | | |
| − | ===Syntax===
| + | [[Unique Primitive CDOMObject Proposals]] |
| | | | |
| − | CHOOSE:PCSTAT|x|x
| + | [[Complex CDOMObject Proposals]] |
| − | | |
| − | x is a PRIMITIVE
| |
| − | | |
| − | A PRIMITIVE is an identifier of objects, and may include any number of specifications.
| |
| − | | |
| − | In the case of PCStat objects, the only valid PRIMITIVES are the four global PRIMITIVES:
| |
| − | | |
| − | x = a Stat abbreviation (STR, INT, etc.)<br>
| |
| − | x = TYPE=w (w is a TYPE identifier for a Stat) - note that none of our STATs actually use TYPE: but this works anyway :)<br>
| |
| − | x = !TYPE=w (w is a TYPE identifier for a Stat that would be prohibited)<br>
| |
| − | x = ALL (allow the choice of any STAT)<br>
| |
| − | | |
| − | Since we can easily add other things later (at least a lot easier than the old CHOOSE system), I would like to start simple on this one. :)
| |
| − | | |
| − | ===Conversion===
| |
| − | | |
| − | CHOOSE:STAT<br>
| |
| − | becomes<br>
| |
| − | CHOOSE:PCSTAT|ALL
| |
| − | | |
| − | CHOOSE:STAT|STR<br>
| |
| − | becomes<br>
| |
| − | CHOOSE:PCSTAT|INT|WIS|DEX|CON|CHA
| |
| − | | |
| − | Note that this latter replacement is "deterministic" as the Stats can only be defined in the Game Mode.
| |
| − | | |
| − | ==CHOOSE:ARMORPROFICIENCY==
| |
| − | | |
| − | SUBTOKEN: ARMORPROFICIENCY (new)<br>
| |
| − | SUBTOKEN: ARMORPROF (deprecated by this proposal)<br>
| |
| − | | |
| − | Reason for deprecation: The Challenge with the existing CHOOSE:ARMORPROF is that it is based on equipment. Meaning, CHOOSE:ARMORPROF|TYPE=Foo means to allow a choice of any ArmorProf that is used in a PROFICIENCY:ARMOR|x token on a piece of Equipment of TYPE=Foo. This is counter to the long-term plan for CHOOSE tokens, and I would like to get away from this.
| |
| − | | |
| − | ===Syntax===
| |
| − | | |
| − | CHOOSE:ARMORPROFICIENCY|x|y|y[z]|y[z,z]|x,y,y[z],y[z,z]
| |
| − | | |
| − | x is an ArmorProf PRIMITIVE
| |
| − | | |
| − | A PRIMITIVE is an identifier of objects, and may include any number of specifications. In the case of ArmorProf objects, the only valid PRIMITIVES are the four global PRIMITIVES:
| |
| − | | |
| − | x = an ArmorProf (specified by key)<br>
| |
| − | x = TYPE=w (w is a TYPE identifier for an ArmorProf ) - note that none of our ArmorProfs actually use TYPE: but this works anyway :)<br>
| |
| − | x = !TYPE=w (w is a TYPE identifier for an ArmorProf that would be prohibited)<br>
| |
| − | x = ALL (allow the choice of any ArmorProf)<br>
| |
| − | | |
| − | y is a QUALIFIER
| |
| − | | |
| − | A QUALIFIER is a special keyword that identifies a subset of objects that should be returned. Valid qualifiers for ArmorProf objects are the global qualifiers:
| |
| − | | |
| − | ANY: This means any item in the brackets should be returned (this is implied, so that CHOOSE:ARMORPROFICIENCY|Foo,TYPE=Bar is equivalent to CHOOSE:ARMORPROFICIENCY|ANY[Foo,TYPE=Bar]
| |
| − | | |
| − | PC: This means any ArmorProf which has been granted to the PC by AUTO:ARMORPROF. If the AUTO:ARMORPROF token has an ARMORTYPE= argument, then that *will* be resolved to include ArmorProf objects of that type. In other words if AND ONLY IF the PC has AUTO:ARMORPROF|ARMORTYPE=Foo ... then CHOOSE:ARMORPROFICIENCY|PC[ALL] is equivalent to CHOOSE:ARMORPROFICIENCY|EQUIPMENT[TYPE=Foo]
| |
| − | | |
| − | !PC: This means any ArmorProf which has NOT been granted to the PC by AUTO:ARMORPROF. If the AUTO:ARMORPROF token has an ARMORTYPE= argument, then that *will* be resolved to include ArmorProf objects of that type.
| |
| − | | |
| − | QUALIFIED: This means any ArmorProf for which the PC qualifies. (Generally since our ArmorProf objects don't have PRExxx associated with them, this is a useless qualifier)
| |
| − | | |
| − | in the above cases, z is an ArmorProf PRIMITIVE (see above)
| |
| − | | |
| − | An additional "local" QUALIFIER specific to ArmorProf objects is also available:
| |
| − | | |
| − | EQUIPMENT: If this is used then the parameters in z are evaluated. Once the equipment identified by the z parameters is summarized, the equipment is queried to determine the ArmorProf objects as identified by their PROFICIENCY:ARMOR tokens. These ArmorProf objects are then added to the items that can be selected.
| |
| − | | |
| − | In this case, z is an Equipment PRIMITIVE
| |
| − | | |
| − | A PRIMITIVE is an identifier of objects, and may include any number of specifications. In the case of Equipment objects, there only valid PRIMITIVES are the three global primitives:
| |
| − | | |
| − | z = a piece of Equipment (specified by key)<br>
| |
| − | z = TYPE=w (w is a TYPE identifier for a piece of Equipment)<br>
| |
| − | z = !TYPE=w (w is a TYPE identifier for a piece of Equipment that would be prohibited)<br>
| |
| − | z = ALL (use any Equipment)<br>
| |
| − | | |
| − | Note that for a QUALIFIER, ALL is the implied PRIMITIVE, so:
| |
| − | | |
| − | CHOOSE:ARMORPROFICIENCY|EQUIPMENT[ALL]<br>
| |
| − | is equivalent to <br>
| |
| − | CHOOSE:ARMORPROFICIENCY|EQUIPMENT
| |
| − | | |
| − | | |
| − | A comma represents "AND", meaning multiple items are evaluated independently and then any item that appears in ALL of the items is added to the list.
| |
| − | | |
| − | CHOOSE:ARMORPROF|Chainmail,Field Plate<br>
| |
| − | will result in NO choices because no ArmorProf is both Chainmail and Field Plate.
| |
| − | | |
| − | CHOOSE:ARMORPROF|TYPE=Foo,EQUIPMENT[TYPE=Bar]<br>
| |
| − | would test for any ArmorProf that has the Foo type (as defined in the ArmorProf LST file) which is ALSO the proficiency for an Equipment that has the TYPE Bar (as defined in the Equipment LST file)
| |
| − | | |
| − | A pipe represents "OR", meaning multiple items are evaluated independently and then any item that appears in any of the items is added to the list:
| |
| − | | |
| − | CHOOSE:ARMORPROF|Chainmail|Field Plate<br>
| |
| − | will result in a choice between ArmorProf Chainmail and ArmorProf Field Plate
| |
| − | | |
| − | All commas (ANDs) are evaluated before pipes (ORs), so something like:
| |
| − | | |
| − | CHOOSE:ARMORPROF|Chainmail|TYPE=Foo,EQUIPMENT[TYPE=Bar]<br>
| |
| − | would include Chainmail unconditionally, in addition to any ArmorProf that has the Foo type (as defined in the ArmorProf LST file) which is ALSO the proficiency for an Equipment that has the TYPE Bar (as defined in the Equipment LST file)
| |
| − | | |
| − | ===Conversion===
| |
| − | | |
| − | CHOOSE:ARMORPROF|Chainmail<br>
| |
| − | becomes<br>
| |
| − | CHOOSE:ARMORPROFICIENCY|EQUIPMENT[Chainmail]
| |
| − | | |
| − | CHOOSE:ARMORPROF|ALL<br>
| |
| − | becomes<br>
| |
| − | CHOOSE:ARMORPROFICIENCY|EQUIPMENT[ALL]
| |
| − | | |
| − | ==CHOOSE:SHIELDPROFICIENCY==
| |
| − | | |
| − | SUBTOKEN: SHIELDPROFICIENCY (new)<br>
| |
| − | SUBTOKEN: SHIELDPROF (deprecated by this proposal)<br>
| |
| − | | |
| − | Reason for deprecation: The Challenge with the existing CHOOSE:SHIELDPROF is that it is based on equipment. Meaning, CHOOSE:SHIELDPROF|TYPE=Foo means to allow a choice of any ShieldProf that is used in a PROFICIENCY:SHIELD|x token on a piece of Equipment of TYPE=Foo. This is counter to the long-term plan for CHOOSE tokens, and I would like to get away from this.
| |
| − | | |
| − | ===Syntax===
| |
| − | | |
| − | CHOOSE:SHIELDPROFICIENCY|x|y|y[z]|y[z,z]|x,y,y[z],y[z,z]
| |
| − | | |
| − | x is an ShieldProf PRIMITIVE
| |
| − | | |
| − | A PRIMITIVE is an identifier of objects, and may include any number of specifications. In the case of ShieldProf objects, the only valid PRIMITIVES are the four global PRIMITIVES:
| |
| − | | |
| − | x = a ShieldProf (specified by key)<br>
| |
| − | x = TYPE=w (w is a TYPE identifier for a ShieldProf ) - note that none of our ShieldProfs actually use TYPE: but this works anyway :)<br>
| |
| − | x = !TYPE=w (w is a TYPE identifier for a ShieldProf that would be prohibited)<br>
| |
| − | x = ALL (allow the choice of any ShieldProf)<br>
| |
| − | | |
| − | y is a QUALIFIER
| |
| − | | |
| − | A QUALIFIER is a special keyword that identifies a subset of objects that should be returned. Valid qualifiers for ShieldProf objects are the global qualifiers:
| |
| − | | |
| − | ANY: This means any item in the brackets should be returned (this is implied, so that CHOOSE:SHIELDPROFICIENCY|Foo,TYPE=Bar is equivalent to CHOOSE:SHIELDPROFICIENCY|ANY[Foo,TYPE=Bar]
| |
| − | | |
| − | PC: This means any ShieldProf which has been granted to the PC by AUTO:SHIELDPROF. If the AUTO:SHIELDPROF token has an SHIELDTYPE= argument, then that *will* be resolved to include ShieldProf objects of that type. In other words if AND ONLY IF the PC has AUTO:SHIELDPROF|SHIELDTYPE=Foo ... then CHOOSE:SHIELDPROFICIENCY|PC[ALL] is equivalent to CHOOSE:SHIELDPROFICIENCY|EQUIPMENT[TYPE=Foo]
| |
| − | | |
| − | !PC: This means any ShieldProf which has NOT been granted to the PC by AUTO:SHIELDPROF. If the AUTO:SHIELDPROF token has an SHIELDTYPE= argument, then that *will* be resolved to include ShieldProf objects of that type.
| |
| − | | |
| − | QUALIFIED: This means any ShieldProf for which the PC qualifies. (Generally since our ShieldProf objects don't have PRExxx associated with them, this is a useless qualifier)
| |
| − | | |
| − | in the above cases, z is an ShieldProf PRIMITIVE (see above)
| |
| − | | |
| − | An additional "local" QUALIFIER specific to ShieldProf objects is also available:
| |
| − | | |
| − | EQUIPMENT: If this is used then the parameters in z are evaluated. Once the equipment identified by the z parameters is summarized, the equipment is queried to determine the ShieldProf objects as identified by their PROFICIENCY:SHIELD tokens. These ShieldProf objects are then added to the items that can be selected.
| |
| − | | |
| − | In this case, z is an Equipment PRIMITIVE
| |
| − | | |
| − | A PRIMITIVE is an identifier of objects, and may include any number of specifications. In the case of Equipment objects, there only valid PRIMITIVES are the three global primitives:
| |
| − | | |
| − | z = a piece of Equipment (specified by key)<br>
| |
| − | z = TYPE=w (w is a TYPE identifier for a piece of Equipment)<br>
| |
| − | z = !TYPE=w (w is a TYPE identifier for a piece of Equipment that would be prohibited)<br>
| |
| − | z = ALL (use any Equipment)<br>
| |
| − | | |
| − | Note that for a QUALIFIER, ALL is the implied PRIMITIVE, so:
| |
| − | | |
| − | CHOOSE:SHIELDPROFICIENCY|EQUIPMENT[ALL]<br>
| |
| − | is equivalent to <br>
| |
| − | CHOOSE:SHIELDPROFICIENCY|EQUIPMENT
| |
| − | | |
| − | | |
| − | A comma represents "AND", meaning multiple items are evaluated independently and then any item that appears in ALL of the items is added to the list.
| |
| − | | |
| − | CHOOSE:SHIELDPROF|Buckler,Tower Shield<br>
| |
| − | will result in NO choices because no ShieldProf is both Buckler and Tower Shield.
| |
| − | | |
| − | CHOOSE:SHIELDPROF|TYPE=Foo,EQUIPMENT[TYPE=Bar]<br>
| |
| − | would test for any ShieldProf that has the Foo type (as defined in the ShieldProf LST file) which is ALSO the proficiency for an Equipment that has the TYPE Bar (as defined in the Equipment LST file)
| |
| − | | |
| − | A pipe represents "OR", meaning multiple items are evaluated independently and then any item that appears in any of the items is added to the list:
| |
| − | | |
| − | CHOOSE:SHIELDPROF|Buckler|Tower Shield<br>
| |
| − | will result in a choice between ShieldProf Buckler and ShieldProf Tower Shield
| |
| − | | |
| − | All commas (ANDs) are evaluated before pipes (ORs), so something like:
| |
| − | | |
| − | CHOOSE:SHIELDPROF|Buckler|TYPE=Foo,EQUIPMENT[TYPE=Bar]<br>
| |
| − | would include Bucklerunconditionally, in addition to any ShieldProf that has the Foo type (as defined in the ShieldProf LST file) which is ALSO the proficiency for an Equipment that has the TYPE Bar (as defined in the Equipment LST file)
| |
| − | | |
| − | | |
| − | ===Conversion===
| |
| − | | |
| − | CHOOSE:SHIELDPROF|Buckler<br>
| |
| − | becomes<br>
| |
| − | CHOOSE:SHIELDPROFICIENCY|EQUIPMENT[Buckler]
| |
| − | | |
| − | CHOOSE:SHIELDPROF|ALL<br>
| |
| − | becomes<br>
| |
| − | CHOOSE:SHIELDPROFICIENCY|EQUIPMENT[ALL]
| |
| − | | |
| − | ==CHOOSE:DOMAIN==
| |
| − | | |
| − | SUBTOKEN: DOMAIN (unchanged)
| |
| − | | |
| − | ===Syntax===
| |
| − | | |
| − | CHOOSE:DOMAIN|x|y|y[z]|y[z,z]|x,y,y[z],y[z,z]
| |
| − | | |
| − | x is an Domain PRIMITIVE
| |
| − | | |
| − | A PRIMITIVE is an identifier of objects, and may include any number of specifications. In the case of Domain objects, there are are the four global PRIMITIVES:
| |
| − | | |
| − | x = a Domain (specified by key)<br>
| |
| − | x = TYPE=w (w is a TYPE identifier for a Domain )<br>
| |
| − | x = !TYPE=w (w is a TYPE identifier for a Domain that would be prohibited)<br>
| |
| − | x = ALL (allow the choice of any Domain)<br>
| |
| − | | |
| − | There is also one Domain specific PRIMITIVE:
| |
| − | | |
| − | DEITY = Domains allowed by the Deity
| |
| − | | |
| − | y is a QUALIFIER
| |
| − | | |
| − | A QUALIFIER is a special keyword that identifies a subset of objects that should be returned. Valid qualifiers for Domain objects are the global qualifiers:
| |
| − | | |
| − | ANY: This means any item in the brackets should be returned (this is implied, so that CHOOSE:DOMAIN|Foo,TYPE=Bar is equivalent to CHOOSE:DOMAIN|ANY[Foo,TYPE=Bar]
| |
| − | | |
| − | PC: This means any Domain which has already been taken by the PlayerCharacter.
| |
| − | | |
| − | !PC: This means any Domain which has NOT already been taken by the PlayerCharacter.
| |
| − | | |
| − | QUALIFIED: This means any Domain for which the PC qualifies (meets the PRExxx on the Domain or has QUALIFY:DOMAIN|x for that Domain)
| |
| − | | |
| − | Note that for a QUALIFIER, ALL is the implied PRIMITIVE, so:
| |
| − | | |
| − | CHOOSE:DOMAIN|PC[ALL]<br>
| |
| − | is equivalent to <br>
| |
| − | CHOOSE:DOMAIN|PC
| |
| − | | |
| − | | |
| − | | |
| − | A comma represents "AND", meaning multiple items are evaluated independently and then any item that appears in ALL of the items is added to the list.
| |
| − | | |
| − | CHOOSE:DOMAIN|Fire,War
| |
| − | | |
| − | will result in NO choices because no Domain is both Fire and War.
| |
| − | | |
| − | CHOOSE:DOMAIN|TYPE=Foo,PC<br>
| |
| − | would test for any Domain that has the Foo type (as defined in the Domain LST file) which is ALSO already selected by the PlayerCharacter
| |
| − | | |
| − | This could also be written (probably more clearly):<br>
| |
| − | CHOOSE:DOMAIN|PC[TYPE=Foo]
| |
| − | | |
| − | | |
| − | A pipe represents "OR", meaning multiple items are evaluated independently and then any item that appears in any of the items is added to the list:
| |
| − | | |
| − | CHOOSE:DOMAIN|Fire|War<br>
| |
| − | will result in a choice between Domain Fire and Domain War
| |
| − | | |
| − | All commas (ANDs) are evaluated before pipes (ORs), so something like:
| |
| − | | |
| − | CHOOSE:DOMAIN|War|TYPE=Foo,PC<br>
| |
| − | would include War unconditionally, in addition to any Domain that has the Foo type (as defined in the Domain LST file) which is ALSO already selected by the PlayerCharacter
| |
| − | | |
| − | ===Specific Case===
| |
| − | | |
| − | ARGUMENT: QUALIFY
| |
| − | | |
| − | This is the only situation where the existing syntax of CHOOSE:DOMAIN will change. QUALIFY currently is a compound behavior, which is performing two tests:
| |
| − | - Is the PC qualified for the Domain (equivalent of the QUALIFIER QUALIFIED)
| |
| − | - Has the PC taken this Domain (equivalent of the QUALIFIER !PC)
| |
| − | | |
| − | QUALIFY is therefore named in a way that may not be completely clear, and can easily be replaced by two qualifiers joined with a comma (AND):
| |
| − | | |
| − | QUALIFIED,!PC
| |
| − | | |
| − | ===Conversion===
| |
| − | | |
| − | CHOOSE:DOMAIN|War|Fire<br>
| |
| − | remains unchanged
| |
| − | | |
| − | CHOOSE:DOMAIN|QUALIFY (this currently provides any Domain which the PC is qualified for and hasn't yet taken)<br>
| |
| − | becomes<br>
| |
| − | CHOOSE:DOMAIN|QUALIFIED,!PC
| |
| − | | |
| − | ==CHOOSE:DEITY==
| |
| − | | |
| − | SUBTOKEN: DEITY (new)
| |
| − | | |
| − | ===Syntax===
| |
| − | | |
| − | CHOOSE:DEITY|x|y|y[z]|y[z,z]|x,y,y[z],y[z,z]
| |
| − | | |
| − | | |
| − | x is a Deity PRIMITIVE
| |
| − | | |
| − | A PRIMITIVE is an identifier of objects, and may include any number of specifications. In the case of Deity objects, there are are the three global PRIMITIVES:
| |
| − | | |
| − | x = an Deity (specified by key)<br>
| |
| − | x = TYPE=w (w is a TYPE identifier for a Deity)<br>
| |
| − | x = !TYPE=w (w is a TYPE identifier for a Deity that would be prohibited)<br>
| |
| − | x = ALL (allow the choice of any Deity)<br>
| |
| − | | |
| − | There are also two Deity specific PRIMITIVES:
| |
| − | | |
| − | ALIGN=w selects deities with Deity Alignment as specified in the w argument (w must be an alignment abbreviation, e.g. "LG")
| |
| − | PANTHEON=w selects deities with Deity Pantheon as specified in the w argument
| |
| − | | |
| − | y is a QUALIFIER
| |
| − | | |
| − | A QUALIFIER is a special keyword that identifies a subset of objects that should be returned. Valid qualifiers for Deity objects are the global QUALIFIERS:
| |
| − | | |
| − | ANY: This means any item in the brackets should be returned (this is implied, so that CHOOSE:DEITY|Foo,TYPE=Bar is equivalent to CHOOSE:DEITY|ANY[Foo,TYPE=Bar]
| |
| − | | |
| − | PC: This means any Deity which has already been taken by the PlayerCharacter.
| |
| − | | |
| − | !PC: This means any Deity which has NOT already been taken by the PlayerCharacter.
| |
| − | | |
| − | QUALIFIED: This means any Deity for which the PC qualifies (meets the PRExxx on the Deity or has QUALIFY:DEITY|x for that Deity)
| |
| − | | |
| − | Note that for a QUALIFIER, ALL is the implied PRIMITIVE, so:
| |
| − | | |
| − | CHOOSE:DEITY|PC[ALL]<br>
| |
| − | is equivalent to <br>
| |
| − | CHOOSE:DEITY|PC
| |
| − | | |
| − | | |
| − | | |
| − | A comma represents "AND", meaning multiple items are evaluated independently and then any item that appears in ALL of the items is added to the list.
| |
| − | | |
| − | CHOOSE:DEITY|Ra,Set
| |
| − | | |
| − | will result in NO choices because no Deity is both Ra and Set.
| |
| − | | |
| − | CHOOSE:DEITY|TYPE=Foo,PC<br>
| |
| − | would test for any Deity that has the Foo type (as defined in the Deity LST file) which is ALSO already selected by the PlayerCharacter
| |
| − | | |
| − | This could also be written (probably more clearly):<br>
| |
| − | CHOOSE:DEITY|PC[TYPE=Foo]
| |
| − | | |
| − | | |
| − | A pipe represents "OR", meaning multiple items are evaluated independently and then any item that appears in any of the items is added to the list:
| |
| − | | |
| − | CHOOSE:DEITY|Ra|Set
| |
| − | | |
| − | will result in a choice between Deities Ra and Set.
| |
| − | | |
| − | All commas (ANDs) are evaluated before pipes (ORs), so something like:
| |
| − | | |
| − | CHOOSE:DEITY|Ra|TYPE=Foo,PC<br>
| |
| − | would include Ra unconditionally, in addition to any Deity that has the Foo type (as defined in the Deity LST file) which is ALSO already selected by the PlayerCharacter
| |
| − | | |
| − | ===Conversion===
| |
| − | | |
| − | None, DEITY is a new Subtoken for CHOOSE
| |
| − | | |
| − | ==CHOOSE:SKILL==
| |
| − | | |
| − | SUBTOKEN: CSKILLS (deprecated)<br>
| |
| − | SUBTOKEN: NONCLASSSKILLLIST (deprecated)<br>
| |
| − | SUBTOKEN: SKILLSNAMED (deprecated)<br>
| |
| − | SUBTOKEN: SKILLSNAMEDTOCSKILL (deprecated)<br>
| |
| − | SUBTOKEN: SKILLSNAMEDTOCCSKILL (deprecated)<br>
| |
| − | SUBTOKEN: SKILLS (deprecated)<br>
| |
| − | SUBTOKEN: SKILL (new)
| |
| − | | |
| − | ===Syntax===
| |
| − | | |
| − | CHOOSE:SKILL|x|y|y[z]|y[z,z]|x,y,y[z],y[z,z]
| |
| − | | |
| − | | |
| − | x is a Skill PRIMITIVE
| |
| − | | |
| − | A PRIMITIVE is an identifier of objects, and may include any number of specifications. In the case of Skill objects, there are are the four global PRIMITIVES:
| |
| − | | |
| − | x = an Skill (specified by key)<br>
| |
| − | x = TYPE=w (w is a TYPE identifier for a Skill )<br>
| |
| − | x = !TYPE=w (w is a TYPE identifier for a Skill that would be prohibited)<br>
| |
| − | x = ALL (allow the choice of any Skill)<br>
| |
| − | | |
| − | There are also Skill specific PRIMITIVES:
| |
| − | | |
| − | ALIGN=w selects deities with Skill Alignment as specified in the w argument (w must be an alignment abbreviation, e.g. "LG")<br>
| |
| − | PANTHEON=w selects deities with Skill Pantheon as specified in the w argument<br>
| |
| − | x% = a pattern match for a Skill (specified for skill keys)
| |
| − | | |
| − | y is a QUALIFIER
| |
| − | | |
| − | A QUALIFIER is a special keyword that identifies a subset of objects that should be returned. Valid qualifiers for Skill objects are the global QUALIFIERS:
| |
| − | | |
| − | ANY: This means any item in the brackets should be returned (this is implied, so that CHOOSE:SKILL|Foo,TYPE=Bar is equivalent to CHOOSE:SKILL|ANY[Foo,TYPE=Bar]
| |
| − | | |
| − | PC: This means any Skill which has already been taken by the PlayerCharacter.
| |
| − | | |
| − | !PC: This means any Skill which has NOT already been taken by the PlayerCharacter.
| |
| − | | |
| − | QUALIFIED: This means any Skill for which the PC qualifies (meets the PRExxx on the Skill or has QUALIFY:SKILL|x for that Skill)
| |
| − | | |
| − | Note that for a QUALIFIER, ALL is the implied PRIMITIVE, so:
| |
| − | | |
| − | CHOOSE:SKILL|PC[ALL]<br>
| |
| − | is equivalent to <br>
| |
| − | CHOOSE:SKILL|PC
| |
| − | | |
| − | There are also many Skill specific QUALIFIERS:
| |
| − | | |
| − | CLASS Displays all class skills for the PC<br>
| |
| − | !CLASS Displays all skills that are NOT class skills for the PC<br>
| |
| − | CROSSCLASS Displays all crossclass skills for the PC<br>
| |
| − | !CROSSCLASS Displays all skills that are NOT crossclass skills for the PC<br>
| |
| − | EXCLUSIVE Displays all exclusive skills for the PC<br>
| |
| − | !EXCLUSIVE Displays all skills that are not exclusive skills for the PC<br>
| |
| − | NORANK Displays all skills in which the PC has no rank<br>
| |
| − | RANK=n Displays all skills in which the PC has n or more ranks<br>
| |
| − | | |
| − | | |
| − | A comma represents "AND", meaning multiple items are evaluated independently and then any item that appears in ALL of the items is added to the list.
| |
| − | | |
| − | CHOOSE:SKILL|Search,Spot
| |
| − | | |
| − | will result in NO choices because no Skill is both Search and Spot.
| |
| − | | |
| − | CHOOSE:SKILL|TYPE=Foo,PC<br>
| |
| − | would test for any Skill that has the Foo type (as defined in the Skill LST file) which is ALSO already selected by the PlayerCharacter
| |
| − | | |
| − | This could also be written (probably more clearly):<br>
| |
| − | CHOOSE:SKILL|PC[TYPE=Foo]
| |
| − | | |
| − | | |
| − | A pipe represents "OR", meaning multiple items are evaluated independently and then any item that appears in any of the items is added to the list:
| |
| − | | |
| − | CHOOSE:SKILL|Search|Spot
| |
| − | | |
| − | will result in a choice between Deities Search and Spot.
| |
| − | | |
| − | All commas (ANDs) are evaluated before pipes (ORs), so something like:
| |
| − | | |
| − | CHOOSE:SKILL|Search|TYPE=Foo,PC<br>
| |
| − | would include Search unconditionally, in addition to any Skill that has the Foo type (as defined in the Skill LST file) which is ALSO already selected by the PlayerCharacter
| |
| − | | |
| − | ===Special Case===
| |
| − | | |
| − | CHOOSE:NONCLASSSKILLLIST had an argument LIST which queried for CROSSCLASS skills on the PC, thus LIST is equivalent to CROSSCLASS in the new syntax
| |
| − | | |
| − | Note that the SKILLSNAMED, SKILLSNAMEDTOCSKILL, and SKILLSNAMEDTOCCSKILL subtokens have syntax that does not change (even relative to the complex behavior available in those tokens)
| |
| − | | |
| − | ===Conversion===
| |
| − | | |
| − | CHOOSE:CSKILLS
| |
| − | becomes
| |
| − | CHOOSE:SKILL|CLASS
| |
| − | | |
| − | CHOOSE:SKILLS
| |
| − | becomes
| |
| − | CHOOSE:SKILL|PC
| |
| − | | |
| − | CHOOSE:SKILLSNAMED|...
| |
| − | becomes
| |
| − | CHOOSE:SKILL|...
| |
| − | | |
| − | CHOOSE:SKILLSNAMEDTOCSKILL|...
| |
| − | becomes
| |
| − | CHOOSE:SKILL|...
| |
| − | CSKILL:LIST
| |
| − | | |
| − | CHOOSE:SKILLSNAMEDTOCCSKILL|...
| |
| − | becomes
| |
| − | CHOOSE:SKILL|...
| |
| − | CCSKILL:LIST
| |
| − | | |
| − | CHOOSE:NONCLASSSKILLLIST|LIST
| |
| − | becomes
| |
| − | CHOOSE:SKILL|CROSSCLASS
| |
| − | | |
| − | CHOOSE:NONCLASSSKILLLIST|LIST|Spot,Search
| |
| − | becomes
| |
| − | CHOOSE:SKILL|CROSSCLASS|Spot|Search
| |
| − | | |
| − | ==CHOOSE:CLASS==
| |
| − | | |
| − | SUBTOKEN: CLASS (unchanged)
| |
| − | SUBTOKEN: SPELLCASTER (deprecated)
| |
| − | | |
| − | ===Syntax===
| |
| − | | |
| − | CHOOSE:CLASS|x|y|y[z]|y[z,z]|x,y,y[z],y[z,z]
| |
| − | | |
| − | x is an PCClass PRIMITIVE
| |
| − | | |
| − | A PRIMITIVE is an identifier of objects, and may include any number of specifications. In the case of PCClass objects, there are are the four global PRIMITIVES:
| |
| − | | |
| − | x = a PCClass (specified by key)<br>
| |
| − | x = TYPE=w (w is a TYPE identifier for a PCClass )<br>
| |
| − | x = !TYPE=w (w is a TYPE identifier for a PCClass that would be prohibited)<br>
| |
| − | x = ALL (allow the choice of any PCClass)<br>
| |
| − | | |
| − | | |
| − | Note that a KEY for a PCClass whcih contains SubClasses can be a (just the key, indicating the parent class and all subclasses), a.a (indicating just the parent class if ALLOWBASECLASS is YES or indicates just the subclass a if ALLOWBASECLASS if NO), and a.b (indicating just the specific SubClass b
| |
| − | | |
| − | There are also PCClass specific PRIMITIVES:
| |
| − | | |
| − | SPELLCASTER = PCClasses that can cast spells (as defined by the use of the SPELLSTAT: token in the PCClass)
| |
| − | | |
| − | y is a QUALIFIER
| |
| − | | |
| − | A QUALIFIER is a special keyword that identifies a subset of objects that should be returned. Valid qualifiers for PCClass objects are the global qualifiers:
| |
| − | | |
| − | ANY: This means any item in the brackets should be returned (this is implied, so that CHOOSE:CLASS|Foo,TYPE=Bar is equivalent to CHOOSE:CLASS|ANY[Foo,TYPE=Bar]
| |
| − | | |
| − | PC: This means any PCClass which has already been taken by the PlayerCharacter.
| |
| − | | |
| − | !PC: This means any PCClass which has NOT already been taken by the PlayerCharacter.
| |
| − | | |
| − | QUALIFIED: This means any PCClass for which the PC qualifies (meets the PRExxx on the PCClass or has QUALIFY:CLASS|x for that PCClass)
| |
| − | | |
| − | Note that for a QUALIFIER, ALL is the implied PRIMITIVE, so:
| |
| − | | |
| − | CHOOSE:CLASS|PC[ALL]<br>
| |
| − | is equivalent to <br>
| |
| − | CHOOSE:CLASS|PC
| |
| − | | |
| − | | |
| − | | |
| − | A comma represents "AND", meaning multiple items are evaluated independently and then any item that appears in ALL of the items is added to the list.
| |
| − | | |
| − | CHOOSE:CLASS|Wizard,Fighter
| |
| − | | |
| − | will result in NO choices because no PCClass is both Wizard and Fighter.
| |
| − | | |
| − | CHOOSE:CLASS|TYPE=Foo,PC<br>
| |
| − | would test for any PCClass that has the Foo type (as defined in the PCClass LST file) which is ALSO already selected by the PlayerCharacter
| |
| − | | |
| − | This could also be written (probably more clearly):<br>
| |
| − | CHOOSE:CLASS|PC[TYPE=Foo]
| |
| − | | |
| − | | |
| − | A pipe represents "OR", meaning multiple items are evaluated independently and then any item that appears in any of the items is added to the list:
| |
| − | | |
| − | CHOOSE:CLASS|Wizard|Fighter<br>
| |
| − | will result in a choice between PCClass Wizard and PCClass Fighter
| |
| − | | |
| − | All commas (ANDs) are evaluated before pipes (ORs), so something like:
| |
| − | | |
| − | CHOOSE:CLASS|Fighter|TYPE=Foo,PC<br>
| |
| − | would include Fighter unconditionally, in addition to any PCClass that has the Foo type (as defined in the PCClass LST file) which is ALSO already selected by the PlayerCharacter
| |
| − | | |
| − | ===Conversion===
| |
| − | | |
| − | CHOOSE:SPELLCLASSES
| |
| − | becomes
| |
| − | CHOOSE:CLASS|SPELLCASTER
| |
| − | | |
| − | CHOOSE:CLASS|Fighter|Wizard<br>
| |
| − | remains unchanged
| |
| − | | |
| − | ==CHOOSE:CHECK==
| |
| − | | |
| − | SUBTOKEN: CHECK (new)
| |
| − | | |
| − | ===Syntax===
| |
| − | | |
| − | CHOOSE:CHECK|x|x
| |
| − | | |
| − | x is a Check PRIMITIVE
| |
| − | | |
| − | A PRIMITIVE is an identifier of objects, and may include any number of specifications. In the case of Check objects, there are are the three global PRIMITIVES:
| |
| − | | |
| − | x = an Check (specified by key)<br>
| |
| − | x = TYPE=w (w is a TYPE identifier for a Check) - note that none of our Checks have TYPE today, but this will still work in theory<br>
| |
| − | x = !TYPE=w (w is a TYPE identifier for a Check that would be prohibited)<br>
| |
| − | x = ALL (allow the choice of any Check)<br>
| |
| − | | |
| − | | |
| − | A comma represents "AND", meaning multiple items are evaluated independently and then any item that appears in ALL of the items is added to the list.
| |
| − | | |
| − | CHOOSE:CHECK|Will,Fortitude
| |
| − | | |
| − | will result in NO choices because no Check is both Will and Fortitude.
| |
| − | | |
| − | | |
| − | A pipe represents "OR", meaning multiple items are evaluated independently and then any item that appears in any of the items is added to the list:
| |
| − | | |
| − | CHOOSE:CHECK|Will|Fortitude
| |
| − | | |
| − | will result in a choice between Check Will and Check Fortitude.
| |
| − | | |
| − | ===Conversion===
| |
| − | | |
| − | None, CHECK is a new Subtoken for CHOOSE\
| |
Background
The current CHOOSE system has a few challenges that I would like to eliminate for PCGen 6.0. In particular:
- It is inconsistent. "PC" is occasionally used for what is granted to a PC, other items use "LIST" for the same meaning. This makes it impossible to share code and still be able to "unparse" the choose back to the LST format.
- It is incomplete. There are base objects that cannot be chosen (such as CHOOSE:DEITY, CHOOSE:CLASS)
- It is even more incomplete. There are combinations (ANY, Granted, Unique, Qualified) that are possible in some tokens, but not others
- It is not type safe (everything is stored as a String)
Thus, in order to head off a ton of additional CHOOSE function being required through coding, I would like to propose a complete rebuild of the CHOOSE system for PCGen 6.0 into a standardized format.
Here are the goals:
- Any primitive PObject must be able to be chosen
- Any type safe constants must be able to be chosen
- Any primitive PObject must be selectable if it (1) exists, (2) is granted to the PC (3) The PC is qualified for it OR (4) If the PC is qualified and doesn't already have it
Proposed format for CHOOSE in PCGen 6.0
CHOOSE will have two sets of syntax: One set will be for those items that do NOT require clarification to establish identity. For example, Classes. The second will be for those that DO require clarification to establish identify. For example, Ability (which requires CATEGORY). In all of the examples below, there will be a GROUPING item, but that is ONLY required for a small subset of CHOOSE items (to be explained later).
Note also in this syntax that <primitive> refers to a direct name, such as "Fighter" for a Class.
The general structure of CHOOSE will be:
CHOOSE:[NUMCHOICES=m|]SUBTOKEN|GROUPING|LIST
I'm going to leave out the NUMCHOICES to keep the syntax below simple, but they are legal on all PObject CHOOSERs
PObject CHOOSERS
These are valid calls for CHOOSE for all PObject CHOOSE SUBTOKENs (ABILITY, FEAT, DEITY, DOMAIN, EQUIPMENT, EQMOD, CLASS, RACE, SKILL, SPELL, TEMPLATE, STAT, WEAPONPROF, ARMORPROF, SHIELDPROF)
CHOOSE:SUBTOKEN|GROUPING|ALL
CHOOSE:SUBTOKEN|GROUPING|PC
CHOOSE:SUBTOKEN|GROUPING|QUALIFIED
CHOOSE:SUBTOKEN|GROUPING|UNIQUE
CHOOSE:SUBTOKEN|GROUPING|TYPE=x.x
CHOOSE:SUBTOKEN|GROUPING|<primitive>
CHOOSE:SUBTOKEN|GROUPING|POBJECT=<primitive>
Note: The last syntax POBJECT=<primitive> does not actually use "POBJECT", instead it is replaced by a POBJECT identifier, such as "FEAT".
These can be combined, given typical restrictions on not combining items with "ALL" (because that doesn't make sense)
In addition, each of these items can be additionally qualified (since it is beneficial to select items of TYPE=x that are granted to the PC). This is done by placing the restriction to the qualifier in brackets. !TYPE is legal, e.g.:
CHOOSE:SUBTOKEN|GROUPING|ALL[!TYPE=x.x]
CHOOSE:SUBTOKEN|GROUPING|PC[TYPE=x|<primitive>]
CHOOSE:SUBTOKEN|GROUPING|QUALIFIED[TYPE=x|<primitive>]
CHOOSE:SUBTOKEN|GROUPING|UNIQUE[TYPE=x|<primitive>]
In addition , is used as AND and | as or in the brackets, so
CHOOSE:SUBTOKEN|GROUPING|PC[TYPE=x,!TYPE=y]
Would choose from the items granted to the PC that ARE type x AND are NOT type y
By combining these, one can presumably create very flexible choosers, e.g.:
CHOOSE:SUBTOKEN|GROUPING|PC[TYPE=x|<primitive1>|<primitive2>|<primitive3>]|QUALIFIED[!TYPE=y,TYPE=z|<primitive4>]
(To the code monkeys, yes this sucks to parse because | can appear inside the brackets - I think the flexibility is worth it, though I'm open to other syntax... e.g. is ; useful at all??? )
GROUPING CHOOSEers
There is only one PObject tokens that requires a GROUPING: Ability. All other PObject choosers do not have a GROUPING (To clarify, if the GROUPING is not requried, then there is only one | that separates SUBTOKEN from the list items, see the examples below if you are confused)
For Ability, the GROUPING is [using regular expressions]:
CATEGORY=(ANY|x[,x]*)[;NATURE=y[,y]*]
This says:
- CATEGORY is requried, nature is optional.
- Nature muse be specific (NATURE=ALL is the default if NATURE is not specified).
- More than one CATEGORY or NATURE can be specified, comma separated.
Thus, the following are legal GROUPINGs for Abilities:
CATEGORY=ANY
CATEGORY=x,x
CATEGORY=ANY;NATURE=x,x
CATEGORY=x;NATURE=y
Presumably, we should to RANK<n, RANK<=n, RANK>n and RANK>=n (with the understanding that today's RANK=n actually means RANK>=n)
Additional LIST items
Some CHOOSE tokens demand additional list items to maintain current function. The following are valid LIST items
- Domain: Allows DEITY=x ... as a primitive (like TYPE=x or y) [can be placed in [] after an a qualifier like PC or UNIQUE]
- Deity: Allows PANTHEON=x ... as a primitive (like TYPE=x or y) [can be placed in [] after an a qualifier like PC or UNIQUE]
- Deity: Allows ALIGNMENT=x ... as a primitive (like TYPE=x or y) [can be placed in [] after an a qualifier like PC or UNIQUE] (refers to the Deity's Alignment)
- Spell: Allows CLASSLIST=x or DOMAINLIST=x
//DO NOT ASK ME TO SHORTEN THIS TO CLASS= or LIST=//. There is GOOD reason for this choice that echoes to other parts of CDOM/6.0
Additional LIST items for Skills:
There are few additional qualifiers here (these are items in addition to PC, QUALIFIED, etc):
CLASS
!CLASS
CROSSCLASS
!CROSSCLASS
EXCLUSIVE
!EXCLUSIVE
NORANK
RANK=n
Additional LIST items for Proficiecy items
This includes ARMORPROF, SHIELDPROF, WEAPONPROF
Allows EQUIPMENT as a qualifier in addition to PC, UNIQUE, etc.
Allows WIELD=x as a primitive ONLY inside of the EQUIPMENT qualifier (in addition to TYPE=x or <primitive>, still valid inside of EQUIPMENT)
Examples
So here are a few examples of how CHOOSE changes:
CHOOSE:ARMORTYPE --> CHOOSE:ARMORPROF|PC
CHOOSE:CCSKILLLIST --> CHOOSE:SKILL|CROSSCLASS
CHOOSE:CCSKILLLIST|x,x --> CHOOSE:SKILL|CROSSCLASS[x,x]
CHOOSE:CSKILLS --> CHOOSE:SKILL|CLASS
CHOOSE:DOMAIN|DEITY=x --> CHOOSE:DOMAIN|DEITY=x
CHOOSE:EQUIPTYPE|x --> CHOOSE:EQUIPMENT|TYPE=x
CHOOSE:NONCLASSSKILLLIST|LIST --> CHOOSE:SKILL|!CLASS|PC
CHOOSE:PROFICIENCY|ARMOR|PC|x --> CHOOSE:ARMORPROF|PC[x]
CHOOSE:SKILLLIST|LIST --> CHOOSE:SKILL|ALL
CHOOSE:FEAT=Weapon Focus --> CHOOSE:WEAPONPROF|FEAT=WeaponFocus
CHOOSE:STAT|STR --> CHOOSE:PCSTAT|INW|WIS|DEX|CON|CHA
Non-PObject CHOOSERS
There are a few choosers (in particular CHOOSE:SCHOOLS) that are NOT PObject choosers. Therefore:
CHOOSE:NUMBER remains unchanged.
CHOOSE:STRING (to be put into 5.14) remains unchanged.
CHOOSE:USERINPUT remains unchanged
Many Type Safe constants can be chosen, using the syntax:
CHOOSE:SUBTOKEN
CHOOSE:SUBTOKEN|REMOVE[x,x]
Examples
CHOOSE:SCHOOLS --> CHOOSE:SPELLSCHOOL
Examples of New Stuff:
CHOOSE:SPELLDESCRIPTOR
CHOOSE:REGION
CHOOSE:ABILITYCATEGORY
CHOOSE:ABILITYNATURE
CHOOSE:GENDER
Situations not handled
There are two situations that I know are not handled by this syntax change, both are in CHOOSE:WEAPONPROFS
These are Spellcaster.x and Size.x
While SPELLCASTER.x actually is present in our datasets, it refers to a WEAPONPROF that does not exist, and therefore is a Data bug and should be removed.
SIZE.x does not appear in our data.
I have a solution for these, but it is a bit complicated. I *can* convert from the 5.x syntax, so I am *not* dropping function, I just would prefer to wait for another day to explain the exact details of how it works (pretty complicated in an of itself)...
Actual Proposals
Type Safe Constant Proposals
Simple CDOMObject Proposals
Qualified CDOMObject Proposals
Unique Primitive CDOMObject Proposals
Complex CDOMObject Proposals
