Critical Thinking - Altering how we do things

From PCGen Wiki
Revision as of 21:47, 12 August 2014 by LegacyKing (talk | contribs) (Shieldbash idea)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This is a scratch pad for critical thinking to review how we do things, why we do things, and the final question, do we still need to do things in that manner?


PROHIBITSPELL

Issue - we use 'ALIGNMENT' which has no corresponding tag in spells. This is actually a "Magic" tag that takes a DESCRIPTOR and assigned an internal PRERULE to it from the hard-coded preference house rule.

Solution:

  1. Change the 'ALIGNMENT' to 'DESCRIPTOR'
  2. Add PRERULE:1,x to the tag
  3. Change the Preference House Rule to an actual Soft-Coded rule
  4. Deprecate/Remove the Hard-coded rule (Removes another Hardcoded reliance)

Example of new LST syntax: 

   PROHIBITSPELL:DESCRIPTOR.Good|PREMULT:1,[PREALIGN:LE,NE,CE],[PREDEITYALIGN:LE,NE,CE]|PRERULE:1,Spell_Alignment_Restriction


UI Clutter

ISSUE: Hard-coded d20 reliance - Our displays should be a bit more dynamic to not display empty fields.

Example: Spells Tab - If a Spell has no SAVEINFO, then the UI should not display a blank Save Info.

Similar Names

FAVCLASS vs. FAVOREDCLASS

This should be a no-no. This has the exact same function and one should be replaced by the other. We should avoid FILE specific tags with similar functions. This only serves to create frustration and confusion to new users and experienced monkeys alike.

Armor / Speed Calculations

Issue: Armor with "Medium" or "Heavy" types are hard-coded to alter the "MOVE" of the creature. In some cases we may want to remove the penalty due to a talent.

Why is this an issue? We run into odd problems when trying to deal with undesirable outcomes - example:

  • Mithral has a special tag to alter the designated type of Armor from Heavy to Medium or Medium to Light. This alteration in code makes the armor proficiency type change from the previous type to the new type.

Solution:

  1. Remove the Movement hard-code from the TYPEs
  2. Use a Var to designate Armor Movement Penalty - normally I would avoid this, but you can only wear one piece of armor suit.
  3. Movement penalty should be moved to Gamemode.

SOLVED Solution to the bug presented by Mithral. Change the Proficiency on Armor Types from Light, Medium and Heavy to ArmorProfLight, ArmorProfMedium, ArmorProfHeavy for proficiency. This should have a minimal impact as Armor types are not altered often.

  • Giving this serious thought to fix open bug in Pathfinder. (IMPLEMENTED). Proficiency is now a separate type.

BONUS:WEAPONPROF

Issue: BONUS:WEAPONPROF=x has issues of stacking

PER TOM: The New Variable/MODIFY system can completely handle this, and there are multiple methods of doing it, and we no longer require (and no longer ALLOW) TYPE to trigger overlapping rules... the data team owns it in how they define variables.

One example of implementing this is: 

   BONUS:WEAPONPROF=Unarmed Strike|WEAPONBAB|MonkLVL-BAB|TYPE=Enhancement
   becomes:
   MODIFYOTHER:EQUIPMENT|GROUP=UnarmedStrike|WeaponBabEnhancement|SOLVE|MonkLVL-BAB

   BONUS:WEAPONPROF=TYPE.Monk|WEAPONBAB|MonkLVL-BAB|TYPE=Enhancement
    becomes:
   MODIFYOTHER:EQUIPMENT|GROUP=Monk|WeaponBabEnhancement|SOLVE|MonkLVL-BAB

Because both SOLVEs do not include value(), they are both effectively performing a SET, so they will overwrite, not add.

Then in Global Modifiers, WeaponBabEnhancement is set to modify the WeaponBAB... 

   MODIFYOTHER:EQUIPMENT.PART|ALL|WeaponBAB|SOLVE|value()+WeaponBabEnhancement

Movement Discrepancy

NOTE: Both raised issues should be solved by the upcoming formula parser proposed by Tom.

Issue 1: HasMove is not activated unless a Race has one Movement Mode listed by setting a MOVE:x,y tag.

Issue 2: Tag syntax uses the same separator for multiple functions. MOVE:Walk,60,Fly,40,Swim,20 - if the Formula Parser wasn't planned to handle this I would propose that we follow a more consistent syntax of MOVE:x=y,x=y or MOVE:x=y|x=y

Solution: We should allow MOVE to set a movement mode without relying on a pre-existing movement being set. (Defeats the purpose of build-able races, when we need to set a MOVE tag first).

NOTE: As stated above, I believe the new Formula Parser proposed by Tom is supposed to take over the MOVE tag functions which would fix these issues.


Languages are not true objects

Issue 1: User required to .MOD races or originating object to remove Languages. No easy way to alter default languages.

Issue 2: No easy method to add new languages on the fly.

Conversation: Is this the best method to handle Languages?

Thoughts: Should Languages be given their own category to be drawn from, or removed?

NOTE: Home brew solution to this issue was handled in this manner: 

   Language Name <> CATEGORY:Language <> AUTO:LANG|Language Name

In the race or ability: 

   Object Name <> ABILITY:Language|AUTOMATIC|Language Name|PREVAREQ:RemoveLangName,0


Then using a trigger to kill the call to the language, like we do for Archetypes, they can designate a single language to remove if desired. This user also did a broad remove category.

I like this approach as you aren't reliant on .MODs or loading alternative campaign files. It definitely has merit on solving the issue.

NOTE: We came across this issue with the Kitsune race having different starting languages if set in the default setting or a specific campaign setting. We also had this request on the mailing list 'LST File Help'.

Issue 2 solution: Determine a method to add languages. ASPECT or DESC can accept %LIST from a CHOOSE - CHOOSE has USERINPUT which would meet the desired outcome.

Shields as Weapons

This has caused multiple issues, and requires some insight. The present options:

  • Make the "Shieldbash" a weapon (Done and causes issues)
  • Make the Shield a weapon

The reason people want the Shield to work as both shield and weapon is simple. They do not want to have to create a second item.

Issues that surround this particular scenario:

  • Proficiency - A Shield has Shield Proficiency, but is also treated as a Martial Weapon.
    • PROFICIENCY is crucial to both items - Shield it is towards the ACCHECK.

Ideas: We need to know how to trigger ACCHECK

  • ACCHECK is the penalty assigned to Strength and Dexterity based skills all the time. However, if you are not proficient with your equipment (Shield or Armor), then that penalty extends to your Attack Value.

Brainstorming:

  • The variable 'ACCHECK' is the value from the ACCHECK from shield and armor. This means we can simply use VAR to alter it.
  • The issue is triggering the ACCHECK penalty if the Shield is not proficient. (HACK work around - place a penalty trigger to apply the penalty if shield is a) equipped, and b) no shield prof)
  • With that in mind, we move from 'Shield' as a TYPE, and move it to Weapon Prof. Allowing it to be equipped. Since it's still a Protection Item - it should be listed properly.


   Shield (Light/Wooden)	OUTPUTNAME:Shield, Light Wooden	PROFICIENCY:SHIELD|Shield (Light)	TYPE:Shield.Light.Standard.Close.Weapon.Resizable.Melee.ShieldBash
   COST:3	WT:5				ACCHECK:-1		CRITMULT:x2			CRITRANGE:1			DAMAGE:1d3	EQMOD:WOOD
   WIELD:Light					SIZE:M	SOURCEPAGE:p.152	SPELLFAILURE:5	
   BONUS:COMBAT|AC|1|TYPE=Shield		BONUS:WEAPON|TOHIT|4|PREWEAPONPROF:1,Shieldbash

to 

    Shield (Light/Wooden)	OUTPUTNAME:Shield, Light Wooden	PROFICIENCY:Weapon|Shieldbash	TYPE:ShieldProf.Light.Standard.Close.Weapon.Resizable.Melee.ShieldBash			
    COST:3	WT:5				BONUS:VAR|ACCHECK:-1		CRITMULT:x2			CRITRANGE:1			DAMAGE:1d3	
    EQMOD:WOOD					WIELD:Light					SIZE:M	SOURCEPAGE:p.152	SPELLFAILURE:5	
    BONUS:COMBAT|AC|1|TYPE=Shield


And then 

   ABILITY:Internal|AUTOMATIC|Check Penalty for Armor and Shield|PREEQUIP:1,TYPE.ShieldProf|!PREPROFWITHSHIELD:1,Shield (Light),Shield (Heavy)



   Check Penalty for Armor and Shield
   CATEGORY:Internal
   BONUS:COMBAT|TOHIT|-ACCHECK

Gamemode File Syntax

LOAD.lst

Issue: Has calculations that require expertise to understand the functions. Double pipe used.

  • Issue 2: DEFINE using improper spelling "ENCUMBERANCE"

Consideration: Cleaning up the syntax to more "Human readable" format (Will be required for divesting from d20 hard-coding)

Consider this syntax alternative 

  ENCUMBRANCE:Light|BASELOAD*1/3|PENALTYVAR=None
  ENCUMBRANCE:Medium|BASELOAD*2/3|PENALTYVAR=MediumPenalty
  ENCUMBRANCE:Heavy|BASELOAD|PENALTYVAR=HeavyPenalty
  ENCUMBRANCE:Lift Overhead|BASELOAD

  ENCUMBRANCE:x|y|z
  x = Name of Encumbrance
  y = Formula or number 
  z = Var Name activated to apply penalty


This allows Vars to control the penalty, if any. It also explains its purpose in more understandable terms instead of being automatic.

NOTE: Not all systems use an encumbrance system, so disabling these values should be possible.

FINESSE TYPO

ISSUE: Finessable is a proper word - FINESSABLE:Yes but the correlating "TYPE" is 'Finesseable' we should correct this typo.

Solution: Switch to proper word.


Code Support Required

  • Issue 1: Ranged Weapons with different Damage values (example: Shotgun in Deadlands - Decreasing damage after certain range)
  • Issue 2: Dynamically changing damage dice (example: Unarmed Strike - d20, Spirit Weapon - eclipse, Natural Weapons - fantasy craft)
  • Issue 3: "Additional" damage '+xdy' (example: Flaming weapon adds +1d6 damage)
  • Issue 4: d20 Multiple Iterations with non-standard progressions (example: 3e and PF unarmed strike, Second attacks with Natural weapons)

Solution #1: Needs proposal

Solution #2: BONUS:WEAPON / WEAPONPROF |DAMAGEDICE| and |DAMAGEDIESIZE|

  • DAMAGEDICE increase or decrease number of dice for weapon
  • DAMAGEDIESIZE increases or decreases the size of the die

Example: Spirit Weapon allows a 1d12 to either 2d10 or 1d20.

Solution #3: BONUS:WEAPON / WEAPONPROF |ADDITIONALDAMAGE|

  • ADDITIONALDAMAGE can be xdy format or x format

Solution #4: Already have Iterative Proposal in JIRA.


OS Improvements

Range Increments

  • d20 3e/35e/PF based systems use a 5, 6, 10, or 11 Range Increment Model. (6 and 11 factoring the Shortrange distance)
  • Several Systems have Close and Long range

To support newer or alternative systems:

  1. Method to set Range Loops (Increments)
  2. Method to set alternate Range Distance(s)

Solution: New Formula Parser proposed by Tom Parker seems to answer the needs of this two-prong request.

How:

  • RangeIncrement can be a value of 2 to 11 (Figure most systems uses the initial range and then a number divisible by the base number)
  • RangeDistanceSet can be a value of 2 to 11 (Would force only a display of the designated number for the increment. D&D 5th edition has this need)
Retrieved from "http://159.203.101.162/w/index.php?title=Critical_Thinking_-_Altering_how_we_do_things&oldid=3717"