Architecture Changes 5.17

From PCGen Wiki
Revision as of 01:17, 24 March 2009 by Tom Parker (talk | contribs) (→‎CHOOSE Rebuild)
Jump to: navigation, search

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

  1. Eliminate PCClass ABB being recognized by LoadContext as source-dependent [1] (DONE - SVN 9734)
  2. Make .COPY in LST-files editor friendly [2] (DONE - SVN 9735)
  3. Make .MOD in LST-files editor friendly [3]
  4. Make PCClassLevel REPEATLEVEL in LST-files editor friendly [4]
  5. Rebuild/rename UDAM token to not "cross-pollute" in PCClassLevel [5]
  6. Make Ability CATEGORY recognized by LoadContext as source-dependent [6]
  7. Make Global KEY recognized by LoadContext as source dependent

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.

  1. Domain's CHOOSE:WEAPONPROF can have [WEAPONPROF], should be AUTO:WEAPONPROF:%LIST [7]
  2. Domain's CHOOSE:WEAPONPROF can have [FEAT=x] should get something like: AUTO:FEAT|x(%LIST) [8]
  3. CHOOSE:SPELLLEVEL can have funky arguments (BONUS), should be separate and use %LIST

(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

  1. PCAlignment fields validForDeity, validForFollower can be in ObjectKey
  2. SizeAdjustment fields abbreviation, isDefaultSize can be in StringKey, ObjectKey
  3. PCStat fields abbreviation, statMod can be in StringKey
  4. PCStat field penaltyVar is useless - eliminate
  5. PCStat fields maxValue, minValue can be in IntegerKey
  6. PCStat field rolled can be in ObjectKey
  7. Kit statList can be in ListKey
  8. Kit tableMap can be in MapKey
  9. Global TEMPLATE supports .REMOVE suffix, should really be of the form REMOVE:TEMPLATE [9]
  10. Campaign isLoaded and isInitted are load-based (not static) and thus should be moved into CampaignLoader vs. stored in the Campaign itself

CHOOSE Rebuild

This is the major token rebuild of CHOOSE, as proposed. Each of these are items that need to be built as "new" CHOOSE tokens:

  1. CHOOSE:SPELLS (syntax remains unchanged)
  2. CHOOSE:PCSTAT
  3. CHOOSE:ARMORPROFICIENCY
  4. CHOOSE:SHIELDPROFICIENCY
  5. CHOOSE:DOMAIN
  6. CHOOSE:DEITY [10]
  7. [[CHOOSE Token Proposal for 6.0#CHOOSE:SKILL|CHOOSE:SKILL]
  8. CHOOSE:FEAT
  9. CHOOSE:ABILITY
  10. CHOOSE:LANGUAGE [11]
  11. CHOOSE:CHECK
  12. CHOOSE:ALIGNMENT
  13. CHOOSE:SIZE
  14. CHOOSE:EQUIPMENT
  15. CHOOSE:RACE
  16. CHOOSE:TEMPLATE
  17. CHOOSE:WEAPONPROFICIENCY
  18. CHOOSE:CLASS
  19. CHOOSE:SCHOOLS
  20. CHOOSE:NUMBER
  21. CHOOSE:TYPE
  22. CHOOSE:STRING
  23. CHOOSE:NOCHOICE
  24. CHOOSE:USERINPUT

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

  1. Eliminate Cloning of PCStat objects (Ability Scores) (DONE - SVN 9690)
  2. Eliminate Cloning of Skill objects (DONE - SVN 9696)
  3. Eliminate Cloning of Race objects (DONE - SVN 9700)
  4. Eliminate Cloning of CompanionMod objects (DONE - SVN 9704)
  5. Eliminate Cloning of Template objects (DONE - SVN 9705)
  6. Eliminate Cloning of Spell objects (DONE - SVN 9707)
  7. Eliminate Cloning of Domain objects (DONE - SVN 9709)
  8. Eliminate Cloning of PCClass objects
  9. Eliminate Cloning of Feat/Ability objects
  10. Eliminate Cloning of EquipmentModifier objects (OUT OF SCOPE)
  11. 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

  1. Eliminate Key/ABB comparison of PCStat objects
  2. Eliminate Key comparison of Skill objects
  3. Eliminate Key comparison of Race objects
  4. Eliminate Key comparison of CompanionMod objects
  5. Eliminate Key comparison of Template objects
  6. Eliminate Key comparison of Spell objects
  7. Eliminate Key comparison of Domain objects
  8. Eliminate Key comparison of PCClass objects
  9. Eliminate Key comparison of SizeAdjustment objects
  10. Eliminate Key comparison of PCAlignment objects
  11. Eliminate Key comparison of Language objects
  12. Eliminate Key comparison of PCClass objects
  13. Eliminate Key comparison of Check (PObject) objects
  14. Eliminate Key comparison of Feat/Ability objects
  15. Eliminate Key comparison of EquipmentModifier objects (OUT OF SCOPE)
  16. Eliminate Key comparison of Equipment objects (OUT OF SCOPE)

Player Character Subsystems

  1. PC Subsystem for PCStat objects
  2. PC Subsystem for Skill objects
  3. PC Subsystem for Race objects
  4. PC Subsystem for CompanionMod objects
  5. PC Subsystem for Template objects
  6. PC Subsystem for Spell objects
  7. PC Subsystem for Domain objects
  8. PC Subsystem for PCClass objects
  9. PC Subsystem for SizeAdjustment objects
  10. PC Subsystem for PCAlignment objects
  11. PC Subsystem for Language objects
  12. PC Subsystem for PCClass/PCClassLevel objects
  13. PC Subsystem for Check (PObject) objects
  14. PC Subsystem for Feat/Ability objects
  15. PC Subsystem for CompanionMod objects
  16. PC Subsystem for Proficiency objects
  17. PC Subsystem for Variables
  18. PC Subsystem for Bonuses
  19. PC Subsystem for XP
  20. PC Subsystem for Levels
  21. PC Subsystem for Pure Facts
  22. PC Subsystem for Movement
  23. PC Subsystem for AC
  24. PC Subsystem for Equipment (OUT OF SCOPE)

Storage

  1. Source-based (CDOM) storage of PCStat objects
  2. Source-based (CDOM) storage of Skill objects
  3. Source-based (CDOM) storage of Race objects
  4. Source-based (CDOM) storage of CompanionMod objects
  5. Source-based (CDOM) storage of Template objects
  6. Source-based (CDOM) storage of Spell objects
  7. Source-based (CDOM) storage of Domain objects
  8. Source-based (CDOM) storage of PCClass objects
  9. Source-based (CDOM) storage of SizeAdjustment objects
  10. Source-based (CDOM) storage of PCAlignment objects
  11. Source-based (CDOM) storage of Language objects
  12. Source-based (CDOM) storage of PCClass objects
  13. Source-based (CDOM) storage of Proficiency objects
  14. Source-based (CDOM) storage of CompanionMod objects
  15. Source-based (CDOM) storage of Check (PObject) objects
  16. Source-based (CDOM) storage of Feat/Ability objects
  17. Eliminate Key comparison of EquipmentModifier objects (OUT OF SCOPE)
  18. 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

  1. CharacterDomain is a useless class - delete
  2. StatList is a useless class - delete
  3. UnconstructedValidator should be an interface, not a class
  4. Qualifier (in cdom.helper) is used in .reference, thus it should be in .reference, not .helper
  5. CDOMObject methods addAdds, removeAdds, checkRemovals, driveChoice cause tangles, and should be in CDOMObjectUtilities not in CDOMObject
  6. LoadContext should be an interface, not a class
  7. PersistentChoiceActor decodeChoice often references the LoadContext, and should be discouraged from using Globals. This method should take the LoadContext as an argument.
  8. Give CDOMObject (or a utility class) a method of consolidating out all of the ListKey-based joins in pcgen.core.spell.Spell.java
  9. Ability.Nature should be in pcgen.cdom.enumeration
  10. Spell Components should be in pcgen.cdom.enumeration
  11. 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

Retrieved from "http://159.203.101.162/w/index.php?title=Architecture_Changes_5.17&oldid=1327"