Prerequisites and Requirements

The Prerequisite System

Currently our Prerequisite system is one of the more modular systems within PCGen. It is almost entirely in plugins, and those plugins separate the read, test, and write capabilities into separate files. These are found in plugin.prerequisiste.*

There are a few issues with the existing Prerequisite system that we need to address

1. Currently it is ambiguous whether a Prerequisite is designed to limit what selections are allowed vs. what items are enabled on a PC. This was previous called the "PRE/REQ" problem (Prerequisite vs Requirement). The data team is often working around this with a PREMULT that makes it much less clear what the PRExxx is attempting to do. This distinction is improved by replacing with the ALLOW/ENABLE system.
2. Trailing Prerequisites are a huge challenge and the "allow if/prohibit if logic" of using them produces a number of challenges in forcing items to be constantly evaluated. This is especially true since we can't establish dependencies from our Prerequisite objects, so*every* trailing Prerequisite has to be re-evaluated for *every* change to a PC. (Exponentially slow).
3. The current Prerequisites integrate their HTML description if they are not passed. This is a challenge for two reasons.
   1. This does not play well in an internationalized/localized environment.
   2. Many items now are triggered off of a variable requirement, which is meaningless to an end user. (The HTML that appears on the info pane is practically useless). So levels of indirection in the data (necessary to get the right functional behavior) have neutered the value of this capability.
4. The Prerequisite system as currently designed is a simple "counting" system. For complex requests (you need one item from Bucket A and one from Bucket B, but they can't be the same item - a generalization of a requirement from MSRD), PCGen can't currently enforce this.

ALLOW and ENABLE

Things to write about

• Formula system based
• Stand Alone only
• Should be named (need to change the tokens)
• Name can draw upon an INFO/INFOVARS to indicate the text if an ALLOW/ENABLE is not met
  • Name can be reused, it's a pointer, not a key