Difference between revisions of "Major Code Projects"

From PCGen Wiki
Jump to: navigation, search
(New page: The major code subsystems and projects for near term implementation (5.17+): BONUS system This project involves a bunch of refactoring and some thought into how it should be built State...)
 
(Output System)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
  {| align="right"
 +
  | __TOC__
 +
  |}
 +
 
The major code subsystems and projects for near term implementation (5.17+):
 
The major code subsystems and projects for near term implementation (5.17+):
  
BONUS system
+
=BONUS System=
  
 
This project involves a bunch of refactoring and some thought into how it should be built
 
This project involves a bunch of refactoring and some thought into how it should be built
  
State:
+
'''State:'''
  
- The BONUS system is currently is very text based, which results in a lot of processing in order to capture the current bonus value for a particular bonus type.   
+
* The BONUS system is currently is very text based, which results in a lot of processing in order to capture the current bonus value for a particular bonus type.   
- The BONUS system is also deeply integrated in the core (code tangles or circular class dependencies depending on your vocabulary)
+
* The BONUS system is also deeply integrated in the core (code tangles or circular class dependencies depending on your vocabulary)
  
Project Goals:
+
'''Project Goals:'''
  
- Ideally, the BONUS system should be more "random access" than the incrementing that is required in many cases
+
* Ideally, the BONUS system should be more "random access" than the incrementing that is required in many cases
- The BONUS system also has problems with and vs. or logic. One can apply a bonus to all melee weapons, or to all slaphing weapons. However, a BONUS cannot be applied to all weapons that are slashing AND melee (and only slashing AND melee)
+
* The BONUS system also has problems with and vs. or logic. One can apply a bonus to all melee weapons, or to all slaphing weapons. However, a BONUS cannot be applied to all weapons that are slashing AND melee (and only slashing AND melee)
  
  
Output System
+
=Output System=
  
 
This subsystem is primarily composed of our export tokens.
 
This subsystem is primarily composed of our export tokens.
  
State:
+
'''State:'''
 
 
- Output Tokens have a nasty habit of silently consuming errors, and there is very little in the way to validate Output Token Syntax.
 
- Ouptut Tokens are half-plugin-ized, meaning many of them are plugins, but some are too tightly integrated in the core.
 
- We also need a documentation review of Output Tokens, to ensure the documentation is complete and up-to-date.
 
 
 
Project Goals:
 
 
 
- The system needs a new concept of plugin to give export tokens more flexibility to allow them all to be plugins
 
- Review export tokens vs. our documentation
 
- Longer term, it would be nice for export tokens to be able to validate their syntax, as well as import and export tokens from the same file (the plugin).  This gives a clean way to test round-robin behavior, as well as allowing us to deprecate tokens and change them to something else much easier.
 
 
 
 
 
LST Editor
 
 
 
State:
 
 
 
- Currently the editor for LST files built into PCGen is a in need of a rebuild. It has some issues and doesn't expand itself when new tokens are added (because it's hard coded from before there were LST tokens).  It also has problems with certain tokens.
 
  
Project Goals:
+
* Output Tokens have a nasty habit of silently consuming errors, and there is very little in the way to validate Output Token Syntax.
- Any new token would at least give a text field, even if PCGen didn't recognize the token
+
* Ouptut Tokens are half-plugin-ized, meaning many of them are plugins, but some are too tightly integrated in the core.
- Allows edit both during runtime (meaning you can copy existing objects, but can't modify the ones that already exist) and in a "edit in place" mode (allow editing of the LST files in full, as a stand-alone program, vs. embedded in PCGen)
+
* We also need a documentation review of Output Tokens, to ensure the documentation is complete and up-to-date.
  
 +
'''Project Goals:'''
  
----
+
* The system needs a new concept of plugin to give export tokens more flexibility to allow them all to be plugins
[[4e Documentation Review]]
+
* Review export tokens vs. our documentation
 +
* Longer term, it would be nice for export tokens to be able to validate their syntax, as well as import and export tokens from the same file (the plugin).  This gives a clean way to test round-robin behavior, as well as allowing us to deprecate tokens and change them to something else much easier.

Latest revision as of 11:29, 17 December 2009

The major code subsystems and projects for near term implementation (5.17+):

BONUS System

This project involves a bunch of refactoring and some thought into how it should be built

State:

  • The BONUS system is currently is very text based, which results in a lot of processing in order to capture the current bonus value for a particular bonus type.
  • The BONUS system is also deeply integrated in the core (code tangles or circular class dependencies depending on your vocabulary)

Project Goals:

  • Ideally, the BONUS system should be more "random access" than the incrementing that is required in many cases
  • The BONUS system also has problems with and vs. or logic. One can apply a bonus to all melee weapons, or to all slaphing weapons. However, a BONUS cannot be applied to all weapons that are slashing AND melee (and only slashing AND melee)


Output System

This subsystem is primarily composed of our export tokens.

State:

  • Output Tokens have a nasty habit of silently consuming errors, and there is very little in the way to validate Output Token Syntax.
  • Ouptut Tokens are half-plugin-ized, meaning many of them are plugins, but some are too tightly integrated in the core.
  • We also need a documentation review of Output Tokens, to ensure the documentation is complete and up-to-date.

Project Goals:

  • The system needs a new concept of plugin to give export tokens more flexibility to allow them all to be plugins
  • Review export tokens vs. our documentation
  • Longer term, it would be nice for export tokens to be able to validate their syntax, as well as import and export tokens from the same file (the plugin). This gives a clean way to test round-robin behavior, as well as allowing us to deprecate tokens and change them to something else much easier.