Difference between revisions of "Token Change Proposals for 5.13 Alpha"

From PCGen Wiki
Jump to: navigation, search
Line 24: Line 24:
 
'''The following are the actual proposed changes to tokens:'''
 
'''The following are the actual proposed changes to tokens:'''
  
{| border="1"
+
{| border="1" width="100%"
 
! Token LST File !! Status !! Token Name !! Current Syntax !! Syntax Change !! Future Syntax !! Reason !! Justification for Change !! Discussion/Approval/FREQ
 
! Token LST File !! Status !! Token Name !! Current Syntax !! Syntax Change !! Future Syntax !! Reason !! Justification for Change !! Discussion/Approval/FREQ
 
|-  
 
|-  

Revision as of 12:44, 23 July 2008

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 PRExxx|x Disallow embedded PRE, require PRE at end x|PRExxx Consistency, Performance Clarity and error checking
Race SVN 3029 **INIT** INIT:x Deprecate 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 syntax like ADD [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 after .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** 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 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 <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.