Reply to thread

Message: <blockquote data-quote="thpr" data-source="post: 3439752" data-attributes="member: 48911">The BoD recognizes that it needs to address the roadmap, and that will happen in a future meeting.  It was deferred until we went beta in the 5.11/5.12 cycle in order to avoid distraction; however, I do not believe a date has been set for that discussion.While there is no official roadmap, let me address my **personal opinion** on next steps and specifically the editors.I believe in heavily tested code.  While the unit tests are not publicly available, my RPG-MapGen code has approximately 95% unit test code coverage. (though why I keep plugging a half-dead, half-completed project is beyond me).  Thus, with respect to PCGen, I believe that a robust editor is a demonstration of a robust I/O system.  This is because the non-UI code that supports the editor can be used as part of a test strategy of the application (specifically the I/O subsystem).For those who are familiar with how PCGen imports files, there are Text (LST) files that contain Tokens that define the different objects (e.g. "SA:Monkey Hold" is an "SA" token that will add a Special Ability called "Monkey Hold" to the item defined on the line in which the token appears).To me, part of ensuring a token is correctly parsed is the ability to do a "round robin" test to ensure that one can perform:LST file -> internal structure -> LST file copy -> internal structure copy...in order to ensure that the import from LST and output to LST are internally consistent (by testing equality of the copies to the originals).  "Proving" correct behavior is much easier if one can assume the behavior is internally consistent.Toward this end, for anyone who has looked at the PCGen CDOM code branch, you'll note that most of the tokens have an unparse() method that allows them to be converted from the internal data structure back out to an LST Token.  Those that do not yet have an unparse() method are incomplete - those are future development efforts.  Many of those that are complete already possess near complete unit test code coverage for what can be achieved with parse() and unparse() alone.This isn't a complete solution; a quick counter-example to solely using uparse() to recreate LST files are the following two lines; which could be in two separate Feat.lst files:FeatFoo <tab> SA:Monkey HoldFeatFoo.MOD <tab> SA:.CLEARThis should make one realize that another layer on top of unparse needs to be tracking the source and deltas between two LST files.  This has not yet been built.  I believe the design of this is in the CDOM architecture proposal document; however, I need to double check that and may have to release a new version in order to capture that design.So to spell out what I consider to be the relevant steps of the token changes to build a new I/O system and editor:(0) Prerequisite work: Complete conversion of CHOOSE to the new token format as part of the 5.13 Alpha cycle, as a prerequisite to properly parsing CHOOSE tokens.  Also find any other token conversions and drive inclusion in the 5.13 cycle.(1) Demonstrate round-robin testing of ALL tokens (this guarantees some level of integrity, and since it also creates a baseline of token parsing, allows early testing of CDOM compatibility for anyone who wants it).  This is approximately 60% done today (since much of this can be done independently of (0) above.(2) Demonstrate round-robin testing of entire PCC/LST file sets (this guarantees integrity across .CLEARs, .MODs, etc. and actually completes most of the non-UI portion of an editor)(3a) Build a GUI for the editor.  I haven't gone too far down this path of thought, but it at least can be done independently of the core changes (which would be a steps 3b and on... not defined here).Someday.  I'm not even in a position to define a schedule for the editor (above), which are steps 1-3 of 6 or 7 steps required to complete conversion to a new core... which isn't even officially on the roadmap.  While there is code in a branch, it is officially a proposal.  Given the tremendous amounts of uncertainty involved, I don't believe a reliable statement can be made on this issue.</blockquote>

Verification