Limiting Known Spells from Domains
Introduction
Domains grant x+1 spells per spell-level automatically. This causes an issue in PF, where there aren't domain spells / spell lists, but powers.
The intent is to develop something similar to KNOWNSPELLSFROMSPECIALTY for Domains in a spellcasting class (and PF would use 0). Not only would this allow some functionality for a few PrCs out there, but would cover PF domains.
Background
This conversation originated on pcgen_experimental: _exp 12419
There is a Data Bug awaiting this Feature Request: DATA BUG 2665792
Option #1: Alteration of KNOWNSPELLSFROMSPECIALTY
Compatibility Warning
Option #1 alters backwards compatibility of existing data that may use KNOWNSPELLSFROMSPECIALTY:0 in the data. However, this option is presented as the intent of users of KNOWNSPELLSFROMSPECIALTY:0 could be argued to be exactly what this option proposes (Thus meaning the existing behavior is a BUG, rather than this being a FREQ)
Behavior
Currently KNOWNSPELLSFROMSPECIALTY is tested to determine if it does not equal zero when potential domain spells are added. However, as zero is the default value, there is no difference between KNOWNSPELLSFROMSPECIALTY:0 and no KNOWNSPELLSFROMSPECIALTY token being present in a PCClass.
The relevant code is in pcgen.core.analysis.DomainApplication.applyDomain (search for IntegerKey.KNOWN_SPELLS_FROM_SPECIALTY)
Proposed Change
By altering the LST interpretation, different behavior can be achieved. KNOWNSPELLSFROMSPECIALTY:0 could actually set IntegerKey.KNOWN_SPELLS_FROM_SPECIALTY to zero. Rather than testing IntegerKey.KNOWN_SPELLS_FROM_SPECIALTY against zero, the applyDomain method could test for presence (or lack thereof) of the IntegerKey.KNOWN_SPELLS_FROM_SPECIALTY value. In this way, KNOWNSPELLSFROMSPECIALTY:0 would prohibit the award of bonus spells for Domains, while a class without a KNOWNSPELLSFROMSPECIALTY token would still award the default value of 1 spell for Domains.
Option #1A
No changes to the proposed change above. A .MOD on a class is required to use KNOWNSPELLSFROMSPECIALTY:1 to restore the specialty spell for domains.
Option #1B
Add support for KNOWNSPELLSFROMSPECIALTY:.CLEAR
Thus, a .MOD on a class may use KNOWNSPELLSFROMSPECIALTY:1 or KNOWNSPELLSFROMSPECIALTY:.CLEAR to restore the specialty spell for domains.
Conversion
This change is backwards compatible (and requires no changes) with one exception:
Currently the use of KNOWNSPELLSFROMSPECIALTY:0 results in the default award of one Domain bonus spell. This would change KNOWNSPELLSFROMSPECIALTY:0 to suppress the award of a Domain bonus spell.
The data converter for PCGen 5.17 can be activated to detect the use of KNOWNSPELLSFROMSPECIALTY:0 in order to highlight this issue to users.
Option #2: KNOWNSPELLSFROMDOMAIN
Syntax
KNOWNSPELLSFROMDOMAIN:x
x is a Formula.
The default value for KNOWNSPELLSFROMDOMAIN is determined by: if KNOWNSPELLSFROMSPECIALTY is 0 then the default is 1; otherwise the default is 0
Conversion
Option #2A: Convert KNOWNSPELLSFROMSPECIALTY
Current classes that are SPELLTYPE:DIVINE would be converted from using KNOWNSPELLSFROMSPECIALTY to KNOWNSPELLSFROMDOMAIN.
Option #2B: KNOWNSPELLSFROMDOMAIN is stacking
Current classes that use both KNOWNSPELLSFROMSPECIALTY and KNOWNSPELLSFROMDOMAIN would receive both as bonus spells on Domains
Option #2C: KNOWNSPELLSFROMDOMAIN is exclusive
Current classes that use both KNOWNSPELLSFROMSPECIALTY and KNOWNSPELLSFROMDOMAIN would result in an error on LST load.
