Difference between revisions of "Spell Improvements"

From PCGen Wiki
Jump to: navigation, search
(New page: == Introduction == Since the existing LST syntax of spell tags has proven to be too limiting for many purposes that have been introduced by game designers in the recent past, the follow...)
 
m (Mention the Bonus Domain Spells FREQ in the requirements)
 
(5 intermediate revisions by one other user not shown)
Line 1: Line 1:
 
 
== Introduction ==
 
== Introduction ==
  
Line 8: Line 7:
 
== NEW TAGS for Spells ==
 
== NEW TAGS for Spells ==
  
DAMAGE: standard xdx notation can use CASTERLEVEL variable, needs to be insertable into the DESC tag
+
'''DAMAGE:''' standard xdx notation can use CASTERLEVEL variable, needs to be insertable into the DESC tag
  
DAMAGETYPE: Type of damage done e.g. Fire Slashing etc., needs to be insertable into the DESC tag
+
'''DAMAGETYPE:''' Type of damage done e.g. Fire Slashing etc., needs to be insertable into the DESC tag
  
ATTACKTYPE: Touch, Ranged Touch, Ranged, Melee others?
+
'''ATTACKTYPE:''' Touch, Ranged Touch, Ranged, Melee others?
 
 
XPCOST: number of XP that need to be spent for the spell
 
  
 +
'''XPCOST:''' number of XP that need to be spent for the spell
  
 
== TYPE Modification ==
 
== TYPE Modification ==
Line 38: Line 36:
 
Unclear to me: Will each Class require that the SpellList be added? Meaning, Will the Cleric Class require SPELLLIST:Cleric? If we are redefining how the CLASSES and DOMAINS Tags work in the Spell LST (to build SpellLists) then we need some way to associate those SpellLists to the Classes.
 
Unclear to me: Will each Class require that the SpellList be added? Meaning, Will the Cleric Class require SPELLLIST:Cleric? If we are redefining how the CLASSES and DOMAINS Tags work in the Spell LST (to build SpellLists) then we need some way to associate those SpellLists to the Classes.
  
    * Tom's opinion: I don't like magical association because it shares a name or key - that sounds like a recipe for a problem if something gets changed. I would much rather require direct association, even if it is slightly more verbose.
+
::* Tom's opinion: I don't like magical association because it shares a name or key - that sounds like a recipe for a problem if something gets changed. I would much rather require direct association, even if it is slightly more verbose.
  
 +
Example: If you want to have a class that used the "Ranger" list but added a few special spells a SPELLLIST:Ranger tag in the casting line for the class and SPELLLEVEL:CLASSRanger tags to add to it for just the new class.
  
Example: If you want to have a class that used the "Ranger" list but added a few special spells a SPELLLIST:Ranger tag in the casting line for the class and SPELLLEVEL:CLASSRanger tags to add to it for just the new class.
+
By using the SpellList to decouple spells from classes, the code can be simplified as there would no longer need to be a distinction between the CLASSES and DOMAINS tokens. A SpellList is a SpellList, regardless of whether a PC is granted the list via class or domain.
  
 +
In addition, the SPELLLIST tag should be a global tag as well as a class level line to allow TEMPLATEs and ABILITYs to grant additional spell lists, as well as to support source material that grants extra domain or class spell lists as the PC levels up as mentioned in [[Bonus_domain_spells]].
  
 
== Create a new File Type SPELLMOD ==
 
== Create a new File Type SPELLMOD ==
Line 58: Line 58:
 
TYPE: still needs discussion. This will depend on what we decide to do with the current TYPE in spells. If we move away from using the spell's type to create spell lists, we might begin utilizing that tag for a similar behaviour as the EQMODs use the equipment's type to assign where they are eligible.
 
TYPE: still needs discussion. This will depend on what we decide to do with the current TYPE in spells. If we move away from using the spell's type to create spell lists, we might begin utilizing that tag for a similar behaviour as the EQMODs use the equipment's type to assign where they are eligible.
  
The follwing from the NEW FEAT tags section that was in the previous version of this spec still needs to be ported over:
+
The following from the NEW FEAT tags section that was in the previous version of this spec still needs to be ported over:
  
 
AUGMENTS:SPELL|COMPONENTV
 
AUGMENTS:SPELL|COMPONENTV
Line 110: Line 110:
 
== MODIFY FEAT tags ==
 
== MODIFY FEAT tags ==
  
DESC should be able to take output token substitution for any spell tag as well as the CASTERLEVEL variable.
+
'''DESC''' should be able to take output token substitution for any spell tag as well as the CASTERLEVEL variable.
  
  
=NEW SPELL OUTPUT TOKENS
+
'''NEW SPELL OUTPUT TOKENS'''<br>
DAMAGE, DAMAGETYPE, ATTACKTYPE, TOHIT**
+
DAMAGE, DAMAGETYPE, ATTACKTYPE, TOHIT
  
The output sheet for character spells could have the following after the spell name, |%SPELLATTACK.spell| (|SPELLMEM.TOHIT| some token for ranged or melee touch or not) |%|
+
The output sheet for character spells could have the following after the spell name, |%SPELLATTACK.spell| (|SPELLMEM.TOHIT| some token for ranged or melee touch or not) |%|<br>
So the spell list could look like:
+
So the spell list could look like:<br>
 
2nd (X/day)--ghoul touch (+X melee touch, DC X),scorching ray (+X ranged touch)
 
2nd (X/day)--ghoul touch (+X melee touch, DC X),scorching ray (+X ranged touch)
  
ToDo
+
== ToDo ==
 
 
    * a new Spell Chooser that will be able to deal with these advancements needs to be fleshed out. This needs the capability of bringing up modified spells for selection, but only those that are wanted. Wanted could be none, only those feats a character has, all existing modifications, and partial selections from the last two possibilities (like only metamagic feats, etc.), plus the same for the augmentations in the spells (powers)
 
  
 +
::* a new Spell Chooser that will be able to deal with these advancements needs to be fleshed out. This needs the capability of bringing up modified spells for selection, but only those that are wanted. Wanted could be none, only those feats a character has, all existing modifications, and partial selections from the last two possibilities (like only metamagic feats, etc.), plus the same for the augmentations in the spells (powers)
  
    * a spell customizer that allows building modified spells using those feats and augmentations. This customizer should be accessible from the Equipment Customizer, so equipment can be built that incorporates these modified spells. A second place where the customizer comes into play is the spells tab, where it should allow the user to add modified spells to their prepared spells list / spellbooks.
+
::* a spell customizer that allows building modified spells using those feats and augmentations. This customizer should be accessible from the Equipment Customizer, so equipment can be built that incorporates these modified spells. A second place where the customizer comes into play is the spells tab, where it should allow the user to add modified spells to their prepared spells list / spellbooks.

Latest revision as of 06:18, 14 September 2009

Introduction

Since the existing LST syntax of spell tags has proven to be too limiting for many purposes that have been introduced by game designers in the recent past, the following changes should be taken:


NEW TAGS for Spells

DAMAGE: standard xdx notation can use CASTERLEVEL variable, needs to be insertable into the DESC tag

DAMAGETYPE: Type of damage done e.g. Fire Slashing etc., needs to be insertable into the DESC tag

ATTACKTYPE: Touch, Ranged Touch, Ranged, Melee others?

XPCOST: number of XP that need to be spent for the spell

TYPE Modification

TYPE should be removed from the SPELL LST file. Each assignment of a Spell should provide the type of Spell (Arcane, Divine, Psionic) in the grant of a Spell. In the case of a Class (like a Cleric) the Class may already have a SPELLTYPE Tag that defines the types of Spells granted by the Class. For other Tags (Such as BONUS:SPELLKNOWN) the Spells must either be added to a Class that has a SPELLTYPE or the Type must be defined in the Tag.

I think the SPELLS Tag will require an updated syntax to add a Type?

Does the fact that EQMOD:SPL_CHRG.... not specify a Type matter? (since the args are really only used to calculate the cost)?


SPELLLIST Object

The Tags CLASSES and DOMAIN should no longer be placed into the SPELL PObject, but rather used to associate Spells to a SpellList. They will remain in the Spell LST file. A SpellList will be a new java Class (perhaps a PObject, but no guarantee). Thus, CLASSES:Cleric1 in the Spell LST file will add the Spell to the Cleric SpellList at Spell Level 1.

Also, the SPELLLEVEL Tag will add to a SpellList, not a Class. Therefore, we should probably alter the Syntax, since the current syntax is SPELLLEVEL:CLASS|x|y,y|x|y,y ... and perhaps we want that to be SPELLLEVEL:SPELLLIST|x|y,y|x|y,y or just SPELLLEVEL:x|y,y|x|y,y

The SPELLLEVEL Tag will modify the SpellList... meaning it is possible to have multiple SPELLLEVEL Tags within a given Class. This is expected to increase clarity (vs. having it "set" rather than "add" and only allowing it once - the once limit would also be hard as it can't be a pure reset, as CLASSES and DOMAINS remain in the Spell LST file)

Unclear to me: Will each Class require that the SpellList be added? Meaning, Will the Cleric Class require SPELLLIST:Cleric? If we are redefining how the CLASSES and DOMAINS Tags work in the Spell LST (to build SpellLists) then we need some way to associate those SpellLists to the Classes.

  • Tom's opinion: I don't like magical association because it shares a name or key - that sounds like a recipe for a problem if something gets changed. I would much rather require direct association, even if it is slightly more verbose.

Example: If you want to have a class that used the "Ranger" list but added a few special spells a SPELLLIST:Ranger tag in the casting line for the class and SPELLLEVEL:CLASSRanger tags to add to it for just the new class.

By using the SpellList to decouple spells from classes, the code can be simplified as there would no longer need to be a distinction between the CLASSES and DOMAINS tokens. A SpellList is a SpellList, regardless of whether a PC is granted the list via class or domain.

In addition, the SPELLLIST tag should be a global tag as well as a class level line to allow TEMPLATEs and ABILITYs to grant additional spell lists, as well as to support source material that grants extra domain or class spell lists as the PC levels up as mentioned in Bonus_domain_spells.

Create a new File Type SPELLMOD

To handle Augmented Powers and similar working spells we create a new LST file type called SPELLMOD, which will be an equivalent for spells to what EQMOD does for equipment. Applying these to the power or spell in question will be handled by the spell customizer, which should be accessible by right clicking a spell/power on the spells tab, much like the equipment customizer on the Equipment tab. Metamagic Feats can be supported by this as well by putting PREFEAT tags into the SPELLMOD, which will make it appear in the customizer only if the character has the feat in question.

This will require new tags to be created: In PCC a new tag SPELLMOD: is needed that will add the new file type to the dataset.

In the new SPELLMOD object we are going to need the following tags: <name> the name of the spell modifier, used for output and as identifier if no KEY should be present

KEY: used as identifier for the object, as usual

TYPE: still needs discussion. This will depend on what we decide to do with the current TYPE in spells. If we move away from using the spell's type to create spell lists, we might begin utilizing that tag for a similar behaviour as the EQMODs use the equipment's type to assign where they are eligible.

The following from the NEW FEAT tags section that was in the previous version of this spec still needs to be ported over:

AUGMENTS:SPELL|COMPONENTV this would allow this feat to modify any spell that has a V component (this is currently only an example, it still needs to be looked at which objects of a spell other than components need to be included to make a spell eligible to be modified by a feat)

  • we probably will need to do that with a new PRExxx tag that can be applied to a SPELLMOD

SPELLMOD:COMPS|-V or SPELLMOD:DAMAGETYPE|Any|Fire (change the damage type of the spell from any type to fire). This tag is meant to allow modifying the non-numeric fields of a spell, the numeric ones are covered by the above Bonus tag

  • this can probably be done by setting up the existing tags from the spell in SPELLMOD now, to allow them modifying the ones in a spell? So with the given example we'd just have COMPS:-V or DAMAGETYPE:Any|Fire.

Question: The NEW BONUS category below was created with the former implementation in mind. Should we move these to tags in the SPELLMOD file, instead of creating bonuses as well?

=NEW BONUS category BONUS:SPELL - modifies the properties of the spell it is applied to. options: LEVEL, DAMAGE, RANGE, TARGETAREA, DURATION, CASTTIME (by step?), COST, and XPCOST

The LEVEL tag in this bonus would be used to set the effective spell level for dispel etc. as per the Heighten Spell feat.

The DAMAGE tag in this bonus could take the following forms: - BONUS:X|X|+/-Xd - Add or subtract a number of dice of the current die type for the field. This would do nothing if the die type is heterogenous. - BONUS:X|X|+/-dX - Adds "two sides" to the current die sides used by this dice expression - BONUS:X|X|XdX|TYPE<DamageType>.MERGE - Adds specified dice expression to the current dice expresison. If MERGE is specified the dice expressions will try and be combined if not they won't be.

  • Presumably we need a BONUS:X:Y:+/-Z here as well for adding just a few points?
  • Aaron make the point that we probably need damage per die (presumably in addition to the direct point add): BONUS:SPELLDESCRIPTOR.Cold|DAMAGEPERDIE|1

The RANGE tag in this bonus will do nothing if the system can't make the existing field a numeric range (as the Extend Spell feat).

The TARGETAREA, DURATION and CASTTIME tags in this bonus are a little more complicated but as long as we have a format we can parse it and figure it out. We could also allow for parsing clues for those fields to help find the numeric parts. Something like "[20]-ft.-radius burst".

The COST and XPCOST tags in this bonus should be self-explanatory.


Example 1: Empower Spell BONUS:SPELL|DAMAGE|DICE*1.5

Example 2: Heighten Spell CHOOSE:SPELLLEVEL|1|%CASTERCLASS|%SPELLLEVEL|MAXLEVEL BONUS:SPELL|LEVEL|%CHOICE

Example 3: Widen Spell.MOD<tab>BONUS:SPELL|TARGETAREA|TARGETAREA*2 As per the description it would double the numeric component of a burst, emanation, line or spread spell.

Example 4: Acid Fog.MOD <tab> DAMAGE:2d6 <tab> DAMAGETYPE:Acid

Example 5: Acid Splash.MOD <tab> DAMAGE:1d3 <tab> DAMAGETYPE:Acid<tab> ATTACKTYPE:Ranged.Touch


MODIFY FEAT tags

DESC should be able to take output token substitution for any spell tag as well as the CASTERLEVEL variable.


NEW SPELL OUTPUT TOKENS
DAMAGE, DAMAGETYPE, ATTACKTYPE, TOHIT

The output sheet for character spells could have the following after the spell name, |%SPELLATTACK.spell| (|SPELLMEM.TOHIT| some token for ranged or melee touch or not) |%|
So the spell list could look like:
2nd (X/day)--ghoul touch (+X melee touch, DC X),scorching ray (+X ranged touch)

ToDo

  • a new Spell Chooser that will be able to deal with these advancements needs to be fleshed out. This needs the capability of bringing up modified spells for selection, but only those that are wanted. Wanted could be none, only those feats a character has, all existing modifications, and partial selections from the last two possibilities (like only metamagic feats, etc.), plus the same for the augmentations in the spells (powers)
  • a spell customizer that allows building modified spells using those feats and augmentations. This customizer should be accessible from the Equipment Customizer, so equipment can be built that incorporates these modified spells. A second place where the customizer comes into play is the spells tab, where it should allow the user to add modified spells to their prepared spells list / spellbooks.