Token Change Proposals for 5.13 Alpha

• • The following are the philosophies underlying these token change proposals for the 5.13 cycle:**

(1) Elimination of magical values: Values like -1 that represent unlimited should be replaced by "UNLIMITED" or a String otherwise explicitly identifying the meaning of the special value. (2) Elimination of duplicate code by consolidating tokens (3) Completion of Ability Object changes (4) Preparation for CDOM parsing of tokens (5) Performance (in one or two cases) (6) Elimination of complicated, undocumented interactions

• • The following are the definitions of the Reason in the token change proposals:**

Syntax: This is a proposed syntax change to improve clarity and eliminate a magical value that is not clearly identified Consistency: This is a proposed change to improve consistency between tokens Duplicate: This is a proposed change to eliminate an alternate way of achieving an identical result Upgrade: This is a proposed change based on upgrades made to PCGen to keep the application consistent Nonfunctioning: This is a proposed change due to the token not functioning in the current rev of PCGen Unnecessary: This is a token that provides insights, but requires no processing by the code Performance: This is a proposed change that will reducing parsing complexity and thus improve speed Complicated: This is a proposed change that eliminates complicated behavior

You may also wish to see: 5.15 Alpha Token Change Proposals

• • The following are the actual proposed changes to tokens:**

|| **Token LST File** || **Status** || **Token Name** || **Current Syntax** || **Syntax Change** || **Future Syntax** || **Reason** || **Justification for Change** || **Discussion/Approval/FREQ** || || All || SVN 3034 || All Relevant tokens || TOKEN:x|PRExxx|x || Disallow embedded PRE, require PRE at end || TOKEN:x|x|PRExxx || Consistency, Performance || Clarity and error checking || || || Race || SVN 3029 || **INIT** || INIT:x || Deprecate || BONUS:COMBAT|INITIATIVE|x || Nonfunctioning, Duplicate || INIT: does not function in the code || [1696679] || || Race || SVN 3029 || **MFEAT** || MFEAT:x || Deprecate || none || Removed || MFEAT was part of the Default Monster Code || [1613771] || || Race || SVN 3029 || **HITDICE** || HITDICE:x || Deprecate || none || Removed || HITDICE was part of the Default Monster Code || [1613771] || || All || SVN 3029 || **PREDEFAULTMONSTER** || PREDEFAULTMONSTER:x || Deprecate || none || Removed || PREDEFAULTMONSTER was part of the Default Monster Code || [1613771] || || Class || SVN 3029 || **BAB** || BAB:x || Deprecate || BONUS:xxx || Nonfunctioning, Duplicate || BAB: is present in the code but will always fail (not valid today) || || || Global || SVN 3032 || **REMOVE:FEAT** || REMOVE:FEAT(x,x)n || Change to | syntax like ADD || REMOVE:FEAT|[x|]y,y || Consistency || This was not changed for consistency when ADD and AUTO were updated || || || Global || SVN 3029 || **MOVEA** || MOVEA:x || Deprecate || use BONUS:... || Duplicate || This was rated an ancient Token by Tir || [[1]] || || Global || SVN 3033 || KNOWNSPELLS || KNOWNSPELLS:.CLEARx || Put | after .CLEAR || KNOWNSPELLS:.CLEAR|x || Syntax || KNOWNSPELLS:.CLEARLEVEL=0 is just strange || [6293] || || Equipment || SVN 3028 || WT || WT:x || Eliminate Magical Value (*) || WT:x || Syntax || || [7172] || || Equipment || SVN 3027 || RANGE || RANGE:x || Eliminate Magical Value (-) || RANGE:x || Syntax || || [7172] || || EquipmentModifier || SVN 3029 || **ADDPROF** || ADDPROF:X.Y || Deprecate || none || Capability || The implementation of this token in the code makes the assumption that proficiencies are still in the (Exotic) format, which according to [discussion] is no longer valid. || || || Global || SVN 3031/4526 || **PREHD** || PREHD:x-y PREHD:x+ PREHD:x- (undocumented) || Remove Undocumented Feature || PREHD:x-y PREHD:x+ || Consistency, Clarity || An unclosed range should be 4+ not 4- || || || Equipment || SVN 3810 || **CONTAINS** || varies || -1 changes to "UNLIM" || varies || Syntax, Known Error || Fix an issue where one item is capacity 1 and another capacity -1 resulting in total allowed items being zero (can't add anything to the container) Eliminate -1 as a magical value || [[2]] || || Global || SVN up to 4875/4876 || **CHOOSE** || varies || Deprecate || See FREQ || Consistency || Previously approved || [1690306] [[3]] [[4]] || || Global || SVN 3057 || **CHOOSE** || CHOOSE:WEAPONFOCUS || Deprecate || TBD (new syntax of CHOOSE:FEAT=) || Consistency || Previously approved || [1683322] || || Global || SVN up to 4875/4876 || **CHOOSE** || CHOOSE:x (weapon) || Deprecate || CHOOSE:PROFICIENCY || Consistency || Previously approved || [1631983] || || Class || SVN 3344 || **FEATAUTO** || FEATAUTO:x|x FEATAUTO:.CLEAR.x || Remove Cross-Level Interaction || AUTO:FEAT || Complicated || Currently, FEATAUTO can be used on different Class Level lines, and the .CLEAR behavior is expected to (or I shoudl say 'does' - not sure if people expect it) bridge across those different class levels. This is extremely complicated behavior to replicate, and behavior that we do not replicate elsewhere (except in SA, and we may remove that) || [[5]] || || Global || SVN up to 4832 || **SA** || SA:.CLEAR. || Remove Cross-Level Interaction Deprecate .CLEAR behavior (complex, use Ability object) || SAB:x || Complicated || Currently, SA can be used on different Class Level lines, and the .CLEAR behavior is expected to bridge across those different class levels. This is extremely complicated behavior to replicate once Class Levels are separate objects || [[6]] || || Global || SVN 3826 || MOVECLONE || MOVECLONE:x,xn,y,yn || Simplify || MOVECLONE:x,y,yn || Complicated || Fixes order of operations issues in movement || [1707366] [[7]] || || Global || SVN 3814 || PRETYPE || PRETYPE:x || Deprecate || None || Deprecated Usage || Proper replacement is PRERACETYPE or PRERACESUBTYPE || [[8]] || || SubClass || SVN 3812 || CHOICE || CHOICE:x || May indicate School, SubSchool or Descriptor || TBD || Ambiguous || Perhaps clarifications like CHOICE:SCHOOOL=x or perhaps 3 different tokens?? || || || Equipment || SVN 4872 || PROFICIENCY || PROFICIENCY:x || May indicate ArmorProf, ShieldProf or WeaponProf || TBD || Ambiguous || || [[9]] || || Race || SVN 4870 || FAVCLASS || FAVCLASS:x || May indicate Class or SubClass || TBD || Ambiguous || || [[10]] || || Spell || SVN 3969 || KNOWNSPELLS || KNOWNSPELLS:.CLEARTYPE=Cleric || No delimiter after .CLEAR || KNOWNSPELLS:.CLEAR|TYPE=Cleric || Syntax || Cleans up an ugly typo in PCGen || [[11]] || || Class || SVN 4172 || REPEATLEVEL || REPEATLEVEL:... || Attach to Class Level || 1:REPEATLEVEL:... SUBCLASSLEVEL:1:REPEATLEVEL:... || Consistency || This is the only "lookahead" token in PCGen - would valuable in toe code to eliminate that behavior || || || Global || BUG 1791283 || UDAM || || || || Consistency || This token is STRANGE in the current PCGen world - it appends to the list, no matter what, but the list in a PCClass is always based on level... Therefore mods can do weird things that they probably shouldn't be able to do || [[12]] || || Global || || CHOOSE || CHOOSE:COUNT= || Deprecate COUNT= || Replace with individual token SELECT: || Non-Functioning, Complicated || || || || Global || || CHOOSE || CHOOSE:SPELLLEVEL|<blah>.A || Eliminate .A support || No replacement || Complicated || There is no explanation in the code for exactly what the .A was used for, or if it is necessary, and the rule construct is also not well defined... there should be a better way to do this even if it needs to be supported. || ||

Also, there have been various discussions about PRERACETYPE and finishing that cleanup: http://tech.groups.yahoo.com/group/pcgen_experimental/message/6281 The problem is that PRERACETYPE internally references deprecated code (getCritterType()) implying that the structure needs to change. So I need to understand more about whether this can be elimianted in favor of PRERACE:1,RACETYPE= or whether another solution is required.

Additional items for 5.13, issues being worked on, solutions TBD: 1) Retroactivity, much of this issue is discussed in this thread: http://tech.groups.yahoo.com/group/pcgen_experimental/message/6864 2) Prerequisite behavior, this is surfaced starting at this message: http://tech.groups.yahoo.com/group/pcgen_experimental/message/8133 3) A 6.0 compatibility checker (built out of the CDOM branch) must be completed.