CDOM

Introduction

From Tom Parker: I've been asked what the major steps are for moving to CDOM, so this is being sent out for those who would like to participate in development of the CDOM branch.

The following items are listed in order of priority/critical path. The items are listed as C1, C2, etc. for later reference. At the beginning of each item is a list (in chronological order, give or take) of the teams that will provide gates to implementation of that task.

Note that items are more specific early in the list and more general later in the list, since the later tasks are not as well defined due to uncertainty in some details of the earlier tasks.

Data Specs which are Gating CDOM Compatibility

(requires _experimental to Code to Data)

Additional 5.14 cleanup (side effects to 6.0 relevant to the compatibility checker)

C1) DATA/CODE/DATA/DOCS/ARCH: Deprecate COUNT=: discussion

C2) DATA/CODE/DATA/DOCS/ARCH: ADD SELECT=: discussion

Items which are critical components of CDOM today

I REALLY REALLY need people to object LIKE RIGHT NOW if they do not approve, because there is code invested in this, and it's only going to get worse

C3) DATA: 6.0 CHOOSE Rebuild Proposal:

Old version is here, need to get a new one out, given the CHOOSE:SPELL discussion and what impact that had discussion

Additional Background/Preparation

C4) ARCH: Additional items are required in the architecture document, specifically dealing with how a PC is built and processed. In particular, the current architecture as defined in the document suffers from a significant design flaw when MULT:YES items are source-traced, and that it is possible with a slight redesign to avoid the duplicate information and ugly design currently shown.

C5) ALL/ARCH: Define how the editor should process certain tokens. Specify this in an "ideal" form. Note that this is things like: "Spell Cast count (e.g. the CAST token) should be input in a Table, and not level-by-level."

C6) ALL(DATA/CODE): Determine exact behavior of PRExxx: tokens within PCGen 5.x. Some of these act as Prerequisites, and others act as requirements. Validate the bahavior of the code to ensure that we can reproduce the current behavior (as we need to support the old PRExxx syntax in 6.0). I believe that the behavior is: PRExxx within the Class LST file is treated as a REQ, and others are treated as PRE, but I haven't proven that.

C7) ARCH(CODE): Define the exact storage method for storing a PlayerCharacter in a file. This is most likely an XML file, since that is the easiest way to export (and subsequently reimport) the Graph information.

Steps in CDOM Implementation

C8) ARCH: Finish up the remaining raw parsing of the Tokens (there are very few tokens left). I think this is probably best left to me, as they are complicated interactions.

C9) CODE: Create the new PRE: and REQ: tokens, deprecating the PRExxx syntax. This FREQ was already approved by _experimental. Requires adding support for Reqs to the code (pretty trivial).

C10) CODE: Complete the token unit test cases. These ensure that each token properly parses LST tags and can also unparse those tags. The unit test cases do not handle .CLEAR interactions. Many unit test cases are done, but also many remain.

C11) CODE: Complete the token integration test cases. These ensure that each token properly parses within LST lines (meaning it tests cases where the token is used more than once [stack vs. replace] as well as .CLEAR and other interactions that can occur in .MODs). A good portion of the integration test cases are done, but also many remain. There are dozens of individual tests that can be done here, and all of them are reasonably independent. This is test writing and likely a bunch of debugging, so it's really good for someone who wants to get familiar with the new code, not great for a stand-alone project. Goal is 99.9% code coverage of the CDOM portion of the tokens after unit tests and integration tests are complete.

C12) ARCH/CODE: Create The "Active PC" system. This involves properly parsing PRE and REQ tokens to ensure that only appropriate items are added and active within a PC. Eventually, this will require a loop detection system, as there are possibilities of striking infinite loops, and we need to detect that behavior.

C13) CODE: Create specific extraction methods for the Graph. Currently, very basic graph traversal methods are available in the base library, but these need to be enhanced in order to do the proper extraction from the PCGenGraph. In particular, these need to extract specific items (e.g. the HANDS: tokens, as the general graph traversal system is complete).

C14) CODE: Ensure that all Prerequisite items are properly processing CDOM graph conditions.

C15) CODE: Attach the new extraction methods to the UI and to the output (export, etc.) system.

C16) CODE: Redo the Player Character importer to load the graph rather than the old character structure. Also write the new import/export system for PCs (to XML files)

C17) CODE: Build new PC test cases

C18) CODE: Create GUI editor tokens. My vision here (which hasn't seen large distribution, so I'm happy to refine these thoughts) is to have two items: (a) An editor that literally can take in any LstToken and be capable of "editing" in [will perform validation by parsing text and ensuring it returns true]. (b) individual plugins (separate .java files) for each LstToken that actually creates a UI interface for that token (e.g. a check-box for a boolean token, some form of table for CAST:, etc.). This is very splittable among multiple people, just select different LST files to work on. These .java files override the default (stupid text box) UI provided by [a] above. This may actually be a good stand-alone project, if the programmer is familiar with Swing.

Potential CDOM side effects

C19) ARCH/CODE: Rebuild the Size system (see the [[1]] on _experimental of Tiny and Colossal+ sizes).

C20) Rebuild BioSet from the ground up (redefining game mode tokens if necessary) in order to get it type-safe and understandable. [may also need to be FREQed]. Note there is a much larger issue behind the scenes here with respect to Game Mode tokens, parsing, and getting those up to the same quality as the LST Tokens, but that may not happen in 6.0

Technically non CDOM, but potentially beneficial Activities

A1) CODE: Rebuild the Encumbrance system (semi-independent of CDOM). This is very hardcoded and needs to be torn out and rearchitected.

A2) CODE: Rebuild the BONUS system (independent of CDOM). [Note this probably needs a FREQ since it didn't get one last year] Generally, take Stefan's problem from PCGD some time ago ([PCGD] Looking for input on expanded BONUS functionality, Dec 2006) and reverse the method of fetching BONUSES from an iteration based on Strings to a Get based on keys. To be done /properly/ this requires someone willing to think through some hash/map theory in order to make this flexible, compact, and efficient (if it's even tractable to do in that way)

Related to CDOM Activities

• Rebuild the Size system (see the recent discussion on _experimental of Tiny and Colossal+ sizes)

• Rebuild BioSet from the ground up (redefining game mode tokens if necessary) in order to get it type-safe and understandable. [may also need to be FREQed]. Note there is a much larger issue behind the scenes here with respect to Game Mode tokens, parsing, and getting those up to the same quality as the LST Tokens.

Non CDOM Activities

(A) Rebuild the Encumbrance system (semi-independent of CDOM). This is very hardcoded and needs to be torn out and rearchitected.

(B) Rebuild the BONUS system (independent of CDOM). [Note this probably needs a FREQ since it didn't get one last year] Generally, take Stefan's problem from PCGD some time ago ([PCGD] Looking for input on expanded BONUS functionality, Dec 2006) and reverse the method of fetching BONUSES from an iteration based on Strings to a Get based on keys. To be done /properly/ this requires someone willing to think through some hash/map theory in order to make this flexible, compact, and efficient (if it's even tractable to do in that way)

Some visible, but future projects

(gated by the items above)

(AA) Start putting the Graph awareness/extraction into the PRETESTER items. This is probably gated by significant work on [4] above.

(BB) Start rebuilding PlayerCharacter to use the Graph (also gated by [4])

(CC) Start rebuilding the Export tokens to use the new PlayerCharacter methods (if necessary) (gated by [4] then [BB])

(DD) Start rebuilding the PlayerCharacter reader to write into the Graph. While not technically gated by other items, it would be best to wait for (1) (2) and (4) to complete to ensure Graph stability.