Major Code Projects - Revision history

Karianna: /* Output System */

2009-12-17T11:29:27Z

‎Output System

Karianna: /* LST Editor */

2009-12-10T14:16:35Z

‎LST Editor

Maredudd at 04:22, 15 October 2008

2008-10-15T04:22:57Z

Maredudd at 04:06, 15 October 2008

2008-10-15T04:06:39Z

LegacyKing: 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...

2008-10-14T23:25:33Z

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...

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:

- 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.

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:
- Any new token would at least give a text field, even if PCGen didn't recognize the token
- 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)

----
[[4e Documentation Review]]

← Older revision		Revision as of 11:29, 17 December 2009
Line 35:		Line 35:
	* Review export tokens vs. our documentation		* 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.		* 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.
−
−
−	~~----~~
−	~~[[4e Documentation Review]]~~

@@ Line 35: / Line 35: @@
 * 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.
 ----
 [[4e Documentation Review]]

@@ Line 9: / Line 9: @@
 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)
@@ Line 24: / Line 24: @@
 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.
+* 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.
+* 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.
+* We also need a documentation review of Output Tokens, to ensure the documentation is complete and up-to-date.
-Project Goals:
+'''Project Goals:'''
-- The system needs a new concept of plugin to give export tokens more flexibility to allow them all to be plugins
+* 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
+* 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.
+* 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:
+'''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.
+* 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:
+'''Project Goals:'''
-- Any new token would at least give a text field, even if PCGen didn't recognize the token
+* Any new token would at least give a text field, even if PCGen didn't recognize the token
-- 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)
+* 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)
 ----
 [[4e Documentation Review]]

@@ Line 1: / Line 1: @@
 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
@@ Line 16: / Line 20: @@
-Output System
+=Output System=
 This subsystem is primarily composed of our export tokens.
@@ Line 33: / Line 37: @@
-LST Editor
+=LST Editor=
 State: