Architecture Changes 5.17
Primary Goals - Token/Loader
Prepare for LST Editor
These items benefit the LST editor system and are required in order to allow the editor system a "clean" round-robin of the data stored in PCC/LST files
Eliminate PCClass ABB being recognized by LoadContext as source-dependentFREQ 2671886 (DONE - SVN 9734)Make .COPY in LST-files editor friendlyFREQ 2700709 (DONE - SVN 9735)Make .MOD in LST-files editor friendlyFREQ 2700750 (DONE - SVN 9778)Make .FORGET editor friendlyFREQ 2715783 (DONE - SVN 9782)- Make PCClassLevel REPEATLEVEL in LST-files editor friendly FREQ 2687293
- Rebuild/rename UDAM token to not "cross-pollute" in PCClassLevel FREQ 2671881
- Make Ability CATEGORY recognized by LoadContext as source-dependent FREQ 2671888
- Make Global KEY recognized by LoadContext as source dependent FREQ 2713303
Major Token Changes
These are major token changes that need to take place to sufficiently clean up the data syntax to avoid strange effects and requirements on the code.
Domain's CHOOSE:WEAPONPROF can have [WEAPONPROF], should be AUTO:WEAPONPROF:%LIST FREQ 1683356Domain's CHOOSE:WEAPONPROF can have [FEAT=x] should get something like: AUTO:FEAT|x(%LIST) FREQ 1683356- CHOOSE:SPELLLEVEL can have funky arguments (BONUS), should be separate and use %LIST FREQ 2713306
(also See UDAM in Editor preparation)
Continue Token/Field Cleanup
These are cleanups similar to the major work that was done in PCGen 5.16. These are generally minor refactoring and cleanup, and most are non-invasive. Few of these are critical for the 5.17 cycle and could be ignored if necessary
- ALL String based tokens (use StringKey) that support .CLEAR do so in a rather "different" way that is potentially not stable long-term. This should be reconsidered as to whether it is appropriate.
PCAlignment fields validForDeity, validForFollower can be in ObjectKeyFREQ 2713314 (DONE - SVN 9784)SizeAdjustment fields abbreviation, isDefaultSize can be in StringKey, ObjectKeyFREQ 2713314 (DONE - SVN 9785)PCStat fields abbreviation, statMod can be in StringKeyFREQ 2713314 (DONE - SVN 9786)PCStat field penaltyVar is useless - eliminateFREQ 2713314 (DONE - SVN 9786)PCStat fields maxValue, minValue can be in IntegerKeyFREQ 2713314 (DONE - SVN 9786)PCStat field rolled can be in ObjectKeyFREQ 2713314 (DONE - SVN 9786)Kit statList can be in ListKeyFREQ 2713314 (DONE - SVN 10116)Kit tableMap can be in MapKeyFREQ 2713314 (DONE - SVN 10116)- Global TEMPLATE supports .REMOVE suffix, should really be of the form REMOVE:TEMPLATE FREQ 1916482
Campaign isLoaded and isInitted are load-based (not static) and thus should be moved into CampaignLoader vs. stored in the Campaign itself FREQ 2713309(DONE - SVN 10126, 10128)
CHOOSE Rebuild
This is the major token rebuild of CHOOSE, as proposed.
There is a significant discussion about separators for CHOOSE Separator Characters
Each of these are items that need to be built as "new" CHOOSE tokens:
CHOOSE:CHECK(DONE - SVN 10027)CHOOSE:SIZE(DONE - SVN 10029)CHOOSE:FEAT(DONE - SVN 11809-13, 11824)CHOOSE:ABILITY-- FREQ 2204717 (DONE - SVN 11828)CHOOSE:EQUIPMENT(DONE - SVN 10085, 11788)CHOOSE:TEMPLATE(DONE - SVN 10018-10021)CHOOSE:ARMORPROFICIENCY(DONE - SVN 10086-87, 11782, 11825)CHOOSE:SHIELDPROFICIENCY(DONE - SVN 10088, 11783, 11825)CHOOSE:DOMAIN(DONE - SVN 11781, 11823)CHOOSE:DEITY -- FREQ 1738608(DONE - SVN 10091, 10094, 10098, 10105)CHOOSE:CLASS(DONE - SVN 11787, 11795)CHOOSE:RACE(DONE - SVN 11794)CHOOSE:SKILL -- FREQ 1001527(DONE - SVN 10092-93, 10108, 11789-92, 11826-7)CHOOSE:ARMORTYPE To be deprecated - see FREQ 2713374(DONE - SVN 10090)CHOOSE:SALIST to be deprecated _exp 7364(DONE - SVN 10089, 11793, 11796)CHOOSE:STRING (syntax remains unchanged)(DONE - SVN 11831)CHOOSE:SCHOOLS(DONE - SVN 11831, 11914, 12003)CHOOSE:HP(Deprecated in favor of CHOOSE:STRING - SVN 11865)ADD FEAT= target primitive (CHOOSE:FEAT=, CHOOSE:WEAPONFOCUS, FREQ 902288)(DONE - SVN 11911, 12003)CHOOSE:SPELLS (syntax remains unchanged)(DONE - SVN 11915)CHOOSE:LANG -- FREQ 2703701(DONE - SVN 10083-4, 10098, 11920)CHOOSE:WEAPONPROFICIENCY -- FREQ 1102455(DONE - SVN 10088, 10098, 11825, 11828, 11865, 11911, 11939)CHOOSE:PCSTAT(SVN 10023-10024, 11786, 12003)CHOOSE:ALIGNMENT(SVN 10081, 12003)CHOOSE:NOCHOICE(SVN 12182)CHOOSE:USERINPUT(SVN 12182)- CHOOSE:SPELLLIST can be deprecated and replaced by CHOOSE:SPELLS
- CHOOSE:FEATSELECTION
- CHOOSE:SPELLLEVEL
Make Choice Selection Actions Type Safe
The following items are forced to convert the result of a CHOOSE from a String into a type safe object. Once the CHOOSE tokens are type safe, these can be converted to be type safe as well:
- Global CSKILL
- Global CCSKILL
- AUTO:ARMORPROF
- AUTO:EQUIP
- AUTO:SHIELDPROF
- AUTO:WEAPONPROF
- Race FAVCLASS
- Template FAVOREDCLASS
- Race MONCSKILL
- AUTO:LANG
Leverage GroupingState
The following tokens use error detection that could consider leveraging the GroupingState system. Note that some of these will not benefit and should probably not be changed.
Global CCSKILL, COMPANIONLIST, CSKILL, KIT, LANGAUTO, QUALIFY(DONE - SVN 10129)Add ABILITY, CLASSSKILLS (both), FEAT, LANGUAGE, SKILL, SPELLCASTER, VFEAT(DONE - SVN 10130)Auto ARMORPROF, SHIELDPROF, WEAPONPROFDeity DEITYWEAP, DOMAINSClass LANGBONUS, SKILLLIST, SPELLLIST, WEAPONBONUS(DONE - SVN 10131)Race CHOOSE:LANGAUTO, FAVCLASS, LANGBONUS, MONCCSKILL, MONCSKILL, WEAPONBONUS(DONE - SVN 10132)Remove FEATSkill CLASSESTemplate CHOOSE:LANGAUTO, FAVOREDCLASS, LANGBONUS, WEAPONBONUS(DONE - SVN 10133)
Primary Goals - Core
Eliminate Cloning
Cloning takes place when a PlayerCharacter uses an object and results in extra memory and a minor performance issue. However, once clones are removed, additional type safety work can be done to vastly improve performance.
Currently, Equipment and EquipmentModifier objects have been scoped out of PCGen 5.17 in order to minimize the required changes to the core
Eliminate Cloning of PCStat objects (Ability Scores)(DONE - SVN 9690)Eliminate Cloning of Skill objects(DONE - SVN 9696)Eliminate Cloning of Race objects(DONE - SVN 9700)Eliminate Cloning of CompanionMod objects(DONE - SVN 9704)Eliminate Cloning of Template objects(DONE - SVN 9705)Eliminate Cloning of Spell objects(DONE - SVN 9707)Eliminate Cloning of Domain objects(DONE - SVN 9709)- Eliminate Cloning of PCClass objects
- Eliminate Cloning of Feat/Ability objects
Eliminate Cloning of EquipmentModifier objects(OUT OF SCOPE)Eliminate Cloning of Equipment objects(OUT OF SCOPE)
Drive Type Safety and Performance
This represents the additional type safety work around performance for these object types. These changes cannot be done at the same time as the changes above, because they are significantly invasive, and must wait for a stable PCGen 5.16.0 where multi-version patching is no longer required.
Currently, Equipment and EquipmentModifier objects have been scoped out of PCGen 5.17 in order to minimize the required changes to the core
Eliminate Key/ABB comparison of PCStat object(DONE - SVN 9884-6, 9888-90, 9893-5, 9897, 9899, 9900)Eliminate Key comparison of Skill objects(DONE - SVN 9991, 9997)Eliminate Key comparison of Race objects(DONE - SVN 9989)- Eliminate Key comparison of CompanionMod objects
Eliminate Key comparison of Template objects(DONE - SVN 9993)Eliminate Key comparison of Spell objects(DONE - SVN 10001)- Eliminate Key comparison of Domain objects
- Eliminate Key comparison of PCClass objects
Eliminate Key comparison of SizeAdjustment objects(DONE - SVN 9990)Eliminate Key comparison of PCAlignment objects(DONE - SVN 9994)Eliminate Key comparison of Language objects(DONE - SVN 9995)Eliminate Key comparison of Check (PObject) objects(DONE - SVN 10006)- Eliminate Key comparison of Feat/Ability objects
Eliminate Key comparison of WeaponProf objects(DONE - SVN 9998, 9999)Eliminate Key comparison of EquipmentModifier objects(OUT OF SCOPE)Eliminate Key comparison of Equipment objects(OUT OF SCOPE)
Player Character Facets
PC facet for PCStat objects(SVN 10328)PC facet for Skill objects(SVN 10329)PC facet for Race objects(SVN 10326)PC facet for CompanionMod objects(SVN 10327)PC facet for Template objects(SVN 10326)- PC facet for PCStat objects (SVN 12177)
- PC facet for Spell objects
PC facet for Domain objects(SVN 10240)PC facet for Deity(SVN 10330, 10391)- PC facet for PCClass/PCClassLevel objects (SVN 10354, 10356, 10359-10361, 10367)
PC facet for SizeAdjustment objects(SVN 10379)PC facet for PCAlignment objects(SVN 10331)- PC facet for Language objects (SVN 10352)
PC facet for Check (PObject) objects(SVN 10353)- PC facet for Feat/Ability objects (SVN 10406)
PC facet for CompanionMod objects(SVN 10327)- PC facet for Campaign objects (SVN 10393)
- PC facet for BioSet objects (SVN 10394)
- PC facet for Equipment (SVN 10396)
PC facet for Kit objects(SVN 10414)PC facet for Armor Profs(SVN 11947)PC facet for Shield Profs(SVN 11947)- PC facet for Weapon Profs
- PC facet for Variables (SVN 12179)
- PC facet for Bonuses
- PC facet for XP (SVN 10415)
- PC facet for Levels (SVN 10357)
- PC facet for Movement
- PC facet for AC
- PC facet for Spell Info (books, etc.) (SVN 12178)
- PC facet for Race Type (SVN 10327)
- PC facet for Race Sub Type (SVN 10327)
- PC facet for Legs (SVN 10327)
- PC facet for Reach (SVN 10390)
- PC facet for Hands (SVN 10327)
- PC facet for Face (SVN 10327)
- PC facet for Region/SubRegion (SVN 10383)
- PC facet for Non Prof Penalty (SVN 10389)
- PC facet for SubRace (SVN 10327)
- PC facet for Gender (SVN 10381) [needs event]
- PC facet for Character Level
- PC facet for Skill Cost
- PC facet for Bonus Starting Languages
- PC facet for Ability Pool
- PC facet for SR (SVN 12160)
- PC facet for CR (SVN 10388)
- PC facet for DR
- PC facet for Vision (SVN 12169)
- PC facet for Load (SVN 12161)
- PC facet for Followers (SVN 12163-4)
- PC facet for Special Abilities
- PC facet for Attack
- PC facet for Initiative (SVN 10389)
- PC facet for Money (SVN 10387) [needs event]
- PC facet for Age
- PC facet for HP
- PC facet for Stat Locking (SVN 12176)
- PC facet for Qualification (SVN 11966)
- PC facet for Height (SVN 10382, 10409) [needs event]
- PC facet for Weight (SVN 10382, 10409) [needs event]
Storage
- Source-based (CDOM) storage of PCStat objects
- Source-based (CDOM) storage of Skill objects
- Source-based (CDOM) storage of Race objects
- Source-based (CDOM) storage of CompanionMod objects
- Source-based (CDOM) storage of Template objects
- Source-based (CDOM) storage of Spell objects
- Source-based (CDOM) storage of Domain objects
- Source-based (CDOM) storage of PCClass objects
- Source-based (CDOM) storage of SizeAdjustment objects
- Source-based (CDOM) storage of PCAlignment objects
- Source-based (CDOM) storage of Language objects
- Source-based (CDOM) storage of PCClass objects
- Source-based (CDOM) storage of Proficiency objects
- Source-based (CDOM) storage of CompanionMod objects
- Source-based (CDOM) storage of Check (PObject) objects
- Source-based (CDOM) storage of Feat/Ability objects
Eliminate Key comparison of EquipmentModifier objects(OUT OF SCOPE)Eliminate Key comparison of Equipment objects(OUT OF SCOPE)
Refactoring
These are architecture refactoring issues that generally involve breaking tangles and other work that is helpful to cleaning up the structure of the code
CharacterDomain is a useless class - delete(DONE - SVN 10000, 10010)StatList is a useless class - delete(DONE - SVN 9996)UnconstructedValidator should be an interface, not a class(DONE - SVN 10187)Qualifier (in cdom.helper) is used in .reference, thus it should be in .reference, not .helper(DONE - SVN 10177)CDOMObject methods addAdds, removeAdds, checkRemovals, driveChoice cause tangles, and should be in CDOMObjectUtilities not in CDOMObject(DONE - SVN 10136)- LoadContext should be an interface, not a class
- PersistentChoiceActor decodeChoice often references the LoadContext, and should be discouraged from using Globals. This method should take the LoadContext as an argument.
Give CDOMObject (or a utility class) a method of consolidating out all of the ListKey-based joins in pcgen.core.spell.Spell.java(DONE - SVN 10181)Ability.Nature should be in pcgen.cdom.enumeration(DONE - SVN 10135)Spell Components should be in pcgen.cdom.enumeration(DONE - SVN 10181, 10183)- StatList getModForNumber(int, int) does a String replacement directly prior to a Formula evaluation, this should be moveable into a JEP variable for SCORE that is specific to stats. Actually, need to have the "SOURCE" field for TermEvaluatorBuilderPCVar COMPLETE_PC_SCORE be able to distinguish between STAT:Foo and BASESTAT:Foo and then this replacement would not be necessary.
Primary Goals - LST Editor
Primary Goals - UI
Other
Unresolved Architectural Issues
Variables under Cloning
Certain items, such as variables that are dependent upon an object's name, are ill defined on cloning. Should the key name be swapped out, or should it remain intact. Behavior is inconsistent across objects. This problem is also apparent if KEY or CATEGORY is used in a .MOD
Languages with matching Key
The MSRD has multiple languages (some TYPE:Spoken, some TYPE:Read.Write) that share an identical key. Eventually this will become a significant problem, and it may need to be addressed during 5.17
Spells with matching Key
Similar to the TYPE issue for Languages above, the SRD has multiple "spells" (typically one Magical and one Psionic) that have the same name. They are distinguished by TYPE (Divine vs. Psionic, for example). This should be changed to something more intelligent than type, restoring KEY as a unique identifier. (One option here is to allow a form of CATEGORY for Spells - although the sharing of Arcane and Divine Types makes this a wee bit more complicated than just using CATEGORY as we know it today in Abilities)
Retroactivity
Much of this issue is discussed in this thread: http://tech.groups.yahoo.com/group/pcgen_experimental/message/6864
Prerequisite behavior
This is surfaced starting at this message: http://tech.groups.yahoo.com/group/pcgen_experimental/message/8133
AllenCohn 21:57, 6 January 2010 (UTC)Allen Cohn 1/6/2010 I hope I'm doing this correctly and in the correct place... I saw Karianna's request for feedback. Concerning prerequisites, I am still, to this day, surprised that prerequisites are implemented as multiple individual keyword statements instead of a single PREREQUISITE(boolean statement) form. The boolean statement could, of course, access any internal variables and use any generally known boolean operators. I can't help but think that this approach would be much more flexible and less confusing.