Limiting Known Spells from Domains

From PCGen Wiki
Revision as of 18:14, 28 March 2009 by Tom Parker (talk | contribs) (New page: {| 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...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.