View source for Limiting Known Spells from Domains

{| align="right"
  | __TOC__
  |}

==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: [http://tech.groups.yahoo.com/group/pcgen_experimental/message/12419 _exp 12419]

There is a Data Bug awaiting this Feature Request: [https://sourceforge.net/tracker/index.php?func=detail&aid=2665792&group_id=25576&atid=750091 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.