Incompatible Change List v6

From PCGen Wiki
Jump to: navigation, search

Introduction

Note: This is a WORKING COPY. It is not exhaustive, and will be expanded as more items are discovered

The following items are changes proposed to simplify input and make it easier to process items through the core

Types

The following general reasons for changes exist:

Magical Value

These are items that have a value which has a "special meaning" - often one that is game mode specific.

Compound Behavior

These are items that do more than one thing. Generally these result in behavior that is very specific to certain rules constructs, and thus we should consider unwinding them into 2 or more items.

Self Awareness

These are items that have some form of self-awareness that makes them resistant to problems with .COPY, but as a result transfers responsibility for this awareness into the core. (This may also have a future issue around localization)

Not Editor Friendly

These are items that are very hard for an editor to handle, in that they require unique processing

Formula Risk

These are items that can be converted, but have a risk with the resulting variable name coming in conflict with an existing variable name or term

Shortcut

These are items that try to save a few characters for the data team, but this results in having them in a standardized form produces a challenge. It therefore prevents more generic behavior in the code (forces unique code)

Confusing

These are items that are either identical in behavior to something of a different name, identical in name to something with a different behavior or just otherwise confusing

Proposed in 6.3

Bonus Token

BONUS PPCOST

Associated with unusable Spell Point system. Remove, no replacement at this time.

BONUS SPELLPOINTCOST

Associated with unusable Spell Point system. Remove, no replacement at this time.

Spell Tokens

PPCOST

Associated with unusable Spell Point system. Remove, no replacement at this time.

Note: by implication the output token SPELLMEM will also lose the PPCOST and BASEPPCOST arguments

SPELLPOINTCOST

Associated with unusable Spell Point system. Remove, no replacement at this time.

Note: by implication the output token SPELLMEM will also lose the SPELLPOINTCOST arguments

Stat Tokens

ROLLED

Ununsed behavior. Remove

Impact: None to PCGen Data

Template Tokens

REGION

Magical Value: YES

Compound Behavior, as it can hold both "YES" and a specific region name, so it must load 2 internal values

Self Awareness: YES refers to the object name

Solution: Remove "YES" as a legal value

Impact: Low, but manual conversion recommended. Search for "REGION:YES" will find issues. Data will have to use the actual template name in the token and be aware if those items are .COPY=ed

SUBRACE

Magical Value: YES

Compound Behavior, as it can hold both "YES" and a specific subrace name, so it must load 2 internal values

Self Awareness: YES refers to the object name

Solution: Remove "YES" as a legal value

Impact: Low, but manual conversion recommended. Search for "SUBRACE:YES" will find issues. Data will have to use the actual template name in the token and be aware if those items are .COPY=ed


SUBREGION

Magical Value: YES

Compound Behavior, as it can hold both "YES" and a specific subregion name, so it must load 2 internal values

Self Awareness: YES refers to the object name

Solution: Remove "YES" as a legal value

Impact: Low, but manual conversion recommended. Search for "SUBREGION:YES" will find issues. Data will have to use the actual template name in the token and be aware if those items are .COPY=ed


Short Term Proposed Changes

Race Tokens

FACE

Shortcut: A Face can be a single number, when in "reality" a Face is actually an "Area" (dimension in X and Y)

For example:

FACE:5

which is a shortcut for:

FACE:5,5

Solution: Eliminate the Shortcut

Impact: Little. Can be automatically converted, would have 2 comma-separated values

Template Tokens

FACE

Shortcut: A Face can be a single number, when in "reality" a Face is actually an "Area" (dimension in X and Y)

For example:

FACE:5

which is a shortcut for:

FACE:5,5

Solution: Eliminate the Shortcut

Impact: Little. Can be automatically converted, would have 2 comma-separated values

REPEATLEVEL

Compound Behavior: These items require a "virtual template" to be built, resulting in a lot of internal complication for the core to detect and track these implied templates

Not Editor Friendly: The implied templates don't have usual names, as they are not in data, making tracking what is identical, what is changed, etc. an interesting challenge.

Solution: Remove without replacement

Impact: None. Not used in PCGen data


Formula Related Proposed Changes

Global Tokens

MOVE

Magical Value: MOVE:x implies "Walk", otherwise is type|value

Magical Value: "Walk" is a "special" movement type that automatically claims the "default" movement

Magical Value: Usage in a Race vs. non-Race triggers different behavior (Race is used as the default)

Magical Value: Presence of MOVE: in a Race triggers "has movement" for the creature

Shortcut: Set and Modify are both in MOVE, but are poorly distinguished, uses *value and /value to modify movement when a spelled out version of modification would be much more clear

Impact: Moderate. Probably needs formula system revamp. MOVEBASE term will go away and need to be handled properly, as no magical calculation of base will be available


Race Tokens

LEGS

See Template LEGS


REACH

See Template REACH


Template Tokens

LEGS

Formula Risk: Would be converted to a variable (e.g. LEGS) which matches an existing term that calculates the value

(In reality, there is basically no risk here, as the situation to produce a problem requires such convoluted data I'd be convinced no one could find it even on a bet)

Impact: Little in practice, but manual conversion recommended.


NONPP

Formula Risk: Would be converted to a variable (e.g. NONPP) which may be defined as a var already in data

Impact: Low, but manual conversion recommended. Variable Report will already show data team if they are using "Reach" as a variable name

Note to self: Relationship to Game Mode: WEAPONNONPROFPENALTY

REACH

Formula Risk: Would be converted to a variable (e.g. REACH) which may be defined as a var already in data

Impact: Low, but manual conversion recommended. Variable Report will already show data team if they are using "Reach" as a variable name



Other Incompatible Proposed Changes

Alignment Tokens

ABB

Compound Behavior: Serves as both an abbreviation as well as a Key.

Solution: Remove dual behavior. ABB serves as abbreviation. KEY serves as Key.

Impact: Low. Requires data to add KEY entries to each Alignment

Stat Tokens

ABB

Compound Behavior: Serves as both an abbreviation as well as a Key. (Also serves as formula terms - ACK!)

Solution: Remove dual behavior. ABB serves as abbreviation. KEY serves as Key. Define new function as replacement for the term

Impact: Moderate. Requires new formula system to detect usages of variables.


Size Adjustment Tokens

ABB

Compound Behavior: Serves as both an abbreviation as well as a Key.

Solution: Remove dual behavior. ABB serves as abbreviation. KEY serves as Key.

Impact: Low. Requires data to add KEY entries to each Size


Problem issues without a proposed change=

Global Tokens

PRERACETYPE

Magical Value: Has some magical values based on "critter type", and in certain cases, "Humanoid" is assumed

Solution: Remove magical processing, refer users to PRERACE:RACETYPE=x

WARNING: Solution is not sufficient. PRERACE:RACETYPE=x correctly replaces and queries the character for the acting RACETYPE on the PC. PRERACETYPE accumulates ALL possible RACETYPE objects on the PC (effectively ignoring the fact that only one RACETYPE should be active). The net underlying issue here is that RACETYPE is being used two ways, so it is a compound behavior and needs cleanup.

Impact: Moderate. Search can identify uses of the token. Needs manual conversion by data team due to magical behaviors and needs code work due to warning above


Class Tokens

LANGBONUS

See Template LANGBONUS

WEAPONBONUS

See Template WEAPONBONUS

Race Tokens

CHOOSE LANGAUTO

See Template CHOOSE LANGAUTO

LANGBONUS

See Template LANGBONUS

WEAPONBONUS

See Template WEAPONBONUS

Template Tokens

CHOOSE LANGAUTO

Compound Behavior: This both defines a list and triggers a selection from that list

Confusing: This isn't REALLY a CHOOSE, it behaves like an ADD

Need to have "deep dive" on how selections should work to determine appropriate course of action

CRMOD

Potential Formula Risk: Depending on implementation, would be converted to a variable (e.g. CRMOD) which may be defined as a var already in data

Impact: Low, but manual conversion recommended. Variable Report will already show data team if they are using "CrMod" as a variable name

Note: It is not convincing that this is actually an integer, versus modifying a "Challenge Rating"

FEAT

Compound Behavior: This both defines a list and triggers a selection from that list

Confusing: different behavior than Domain FEAT or Race FEAT which are not selections

Need to have "deep dive" on how selections should work to determine appropriate course of action

LANGBONUS

Compound Behavior: This both defines a list and triggers a selection from that list

Need to have "deep dive" on how selections should work to determine appropriate course of action

RACESUBTYPE

Compound Behavior: Both Additional and removal

Shortcut: uses .REMOVE. (unique behavior)

Need to have a discussion on the data to determine if removal is strictly necessary or whether it is based on data architecture


WEAPONBONUS

Compound Behavior: This both defines a list and triggers a selection from that list

Need to have "deep dive" on how selections should work to determine appropriate course of action

WeaponProf Tokens

HANDS

Magical Value: 1IFLARGERTHANWEAPON

Compound behavior, as it is effectively a formula of sorts