|
|
| (25 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| | + | {| align="right" |
| | + | | __TOC__ |
| | + | |} |
| | | | |
| − | =Description= | + | =WARNING: THIS IS DEPRECATED= |
| | + | =Deprecated= |
| | | | |
| − | This page describes how to use the Formula Parser Equipment Variables Demo, provided in a sandbox (in Subversion)
| + | The remainders here are saved for archival purposes at the moment (they are a few useful tidbits the code folks don't want to retype from scratch) |
| | | | |
| − | =Location=
| + | Please see [[Setting up the new Formula System]] |
| − | | |
| − | The Demo is in sandbox/EqVarDemo/PCGen and can be checked out from subversion as any other branch of PCGen. Please use build.xml (and ant) to build PCGen, as Gradle support may not be fully enabled in this branch.
| |
| | | | |
| | =General Comments and Limitations= | | =General Comments and Limitations= |
| Line 15: |
Line 17: |
| | * Is not intended to cover unreasonably high numbers | | * Is not intended to cover unreasonably high numbers |
| | * There is at least one UI problem, in that the UI doesn't realize that the PRExxx status of an EqMod can dynamically changes when another EqMod is added. The EqMod in question has to be selected to turn red. | | * There is at least one UI problem, in that the UI doesn't realize that the PRExxx status of an EqMod can dynamically changes when another EqMod is added. The EqMod in question has to be selected to turn red. |
| − | * This system does not support variables across multiple heads (well, to be specific, variables are shared across an entire piece of equipment at the moment, so EqMods that use them to control what can be applied may not work correctly with double-headed weapons)
| |
| − |
| |
| − | Please stick to variables that start with a-z or A-Z and have other characters that are letters or numbers. (They must NOT start with a number). Failure to follow this means bets are off as to behavior. Full checking of names for legality will occur at a later time.
| |
| − |
| |
| − | =New Campaign File Token=
| |
| − |
| |
| − | ==VARIABLE==
| |
| − |
| |
| − | VARIABLE: is a new Campaign file token (for PCC files). It is treated "recursively" like other tokens, e.g. TEMPLATE.
| |
| − |
| |
| − | Limitations: It does not support PRExxx or INCLUDE/EXCLUDE.
| |
| − |
| |
| − | Future Development: It is reasonable to expect PRExxx could be supported, it is unlikely that INCLUDE/EXCLUDE would be supported due to the nature of variables not being traditional objects (too much unique code)
| |
| − |
| |
| − | =New Variable File Tokens=
| |
| − |
| |
| − | ==LOCAL==
| |
| − |
| |
| − | LOCAL: is a token for the Variable files defined by the VARIABLE: PCC token. These have 2 arguments, the scope, and the variable name. For example:
| |
| − | LOCAL:EQUIPMENT|ModCount
| |
| − |
| |
| − | Limitations:
| |
| − | * Only EQUIPMENT is supported.
| |
| − | * By Design: Must appear as the first token on a line
| |
| − |
| |
| − | Known Issues: The variable names are not checked to ensure they are "character legal" (this is a statement about illegal characters like '*' not related to whether they were defined in a Variable LST file).
| |
| − |
| |
| − | Future Development:
| |
| − | * Address Known Issues
| |
| − | * Resolve whether "EQUIPMENT" is actually the item on the line or whether it is "Equipment Variables" (how the code thinks internally). This is eventually a risk of tying closely the code and the data, so this requires consideration of how object types are defined (a much longer discussion than belongs here - please ask on _dev if you are interested)
| |
| − |
| |
| − | ==EXPLANATION==
| |
| − |
| |
| − | EXPLANATION: is a free-text token (no parsing is really done) that is designed to describe why a variable exists
| |
| − |
| |
| − | Limitations:
| |
| − | * By Design: Must not appear as the first token on a line
| |
| − |
| |
| − | Behavior:
| |
| − | * Overwrites (as if someone would use it twice??)
| |
| − |
| |
| − | ==Future Development==
| |
| − |
| |
| − | At least "GLOBAL" would be a future development item (though it would "default" to that, so the following variable file is valid:
| |
| − | MyGlobalVariable
| |
| − | GLOBAL:MyOtherGlobalVariable
| |
| − | LOCAL:EQUIPMENT|MyLocalVar
| |
| − |
| |
| − | =Prerequisites=
| |
| − |
| |
| − | PREEQVARxxx exist as PRE tokens. All valid suffixes (LT, EQ, NEQ, etc.) are supported. Please see the PREVAR documentation if you are not familiar with the legal suffixes.
| |
| − |
| |
| − | Syntax:
| |
| − | PREEQVARxx:y,z
| |
| − |
| |
| − | Limitations:
| |
| − | * Only Numbers (Integer or Decimal) or a single, legal variable name are supported as y and z.
| |
| − |
| |
| − | =Modify Token=
| |
| − |
| |
| − | ==Syntax==
| |
| − |
| |
| − | MODIFY:w|x|y|PRIORITY=z
| |
| − |
| |
| − | w is the variable name as defined in the Variable LST file
| |
| − | x is the modification type. Legal types are shown below.
| |
| − | y is the modification (based on the type, see below)
| |
| − | z is an OPTIONAL priority. If not specified, it is assumed to be zero.
| |
| − |
| |
| − | ==Priority==
| |
| − |
| |
| − | Items are processed in a Natural Priority order. PRIORITY is used to order any modifiers, then a natural ordering is used. So:
| |
| − | MODIFY:Var|ADD|4
| |
| − | MODIFY:Var|MULTIPLY|5
| |
| − |
| |
| − | are applied, the Multiplication will ALWAYS occur first, regardless of token order in the file. If you are unsure of natural order, use PRIORITY to control processing order.
| |
| − |
| |
| − | Priority must be >= 0
| |
| − |
| |
| − | Items are processed from the lowest priority to the highest (highest is applied last, so a SET with a high priority is applied last)
| |
| − |
| |
| − | A clarification on natural ordering: it does NOT replace priority if not defined. The two priority comparisons (user priority and natural priority) are independent. So an item of user priority 1 and natural priority 3 will be processed before user priority 2 and natural priority 2, solely based on the user priority)
| |
| − |
| |
| − | ==Legal Types==
| |
| − |
| |
| − | ===ADD===
| |
| − |
| |
| − | ADD takes a Numeric Argument. Must be a legal Integer or Double, no calculations are allowed.
| |
| − |
| |
| − | The 'natural' priority is 3.
| |
| − |
| |
| − | ===MULTIPLY===
| |
| − |
| |
| − | MULTIPLY takes a Numeric Argument. Must be a legal Integer or Double, no calculations are allowed.
| |
| − |
| |
| − | The 'natural' priority is 2.
| |
| − |
| |
| − | ===MAX===
| |
| − |
| |
| − | MAX takes a Numeric Argument. Must be a legal Integer or Double, no calculations are allowed.
| |
| − |
| |
| − | This sets an upper bound on the value (a maximum that the value can be)
| |
| − |
| |
| − | The 'natural' priority is 4.
| |
| − |
| |
| − | ===MIN===
| |
| − |
| |
| − | MIN takes a Numeric Argument. Must be a legal Integer or Double, no calculations are allowed.
| |
| − |
| |
| − | This sets a lower bound on the value (a minimum that the value can be)
| |
| − |
| |
| − | The 'natural' priority is 5.
| |
| − |
| |
| − | ===SET===
| |
| − |
| |
| − | SET takes a Numeric Argument. Must be a legal Integer or Double, no calculations are allowed.
| |
| − |
| |
| − | This sets the value (any previous value is overwritten/ignored)
| |
| − |
| |
| − | The 'natural' priority is 0.
| |
| − |
| |
| − | ===SOLVE===
| |
| − |
| |
| − | The 'natural' priority is 6.
| |
| − |
| |
| − | This calculates a new value, and equations using other variables are allowed. If you have a value that was previously modified from the default (or you want to enable that based on using a higher PRIORITY= then you should use the value() function to capture the existing value. Thus the following are equivalent:
| |
| − | MODIFY:Foo|ADD|4
| |
| − | MODIFY:Foo|SOLVE|value()+4
| |
| − |
| |
| − | (Note that the ADD is preferred because it is smaller in memory and faster to process, but more complex calculations will obviously require SOLVE)
| |
| | | | |
| − | =Functions Supported= | + | =New Global Modifier Tokens= |
| | | | |
| − | The following functions are supported:
| + | MODIFY: and MODIFYOTHER: (see below for the global tokens) are legal in the Global Modifier file. No other tokens are legal. |
| − | * min
| |
| − | * max
| |
| − | * ceil
| |
| − | * floor
| |
| − | * if
| |
| − | * abs
| |
| − | * round
| |
| | | | |
| − | If you have questions about the behavior, see the existing PCGen docs.
| + | Tokens must appear one per line in the Global Modifier file |
