phylll / mychs-macro-magic

A simple, sane, and friendly little scripting language for your Roll20 macros.
MIT License
0 stars 0 forks source link

Implement automatic restrictions on use of parry weapons and shields #21

Closed phylll closed 2 years ago

phylll commented 2 years ago

Exchange of attack data between attack and defense scripts (#19) allows for automating the check if the complicated rules for using parry weapons or shields are met or not, something we've asked the players so far.

Rules are in Kodex, p. 70.

phylll commented 2 years ago

Requires finally handling all weapon categories comprehensively as per the list in Kodex:42-43. Validating weapon types and executing various rules as in parrying (this type of parry weapon works only against those seven types of attack weapons etc.) won't be fun without a simple way of checking list membership (something like if item in list or if contains(list, item) == true).

phylll commented 2 years ago

Commit 574ee7ef1c829a5ebc428f1666b3f868bb902ee0 finally implements the last missing rules in detail except for the restrictions based on a defending token's direction vis-à-vis the attacker.

According to the Kodex (p. 70), any kind of staff as a defensive weapon works against attacks from the front and both sides, and shields and specialized parry weapons only help with defense if the attack comes from the side on which the shield/parry weapon is held. Implementing this would require introducing a new attribute such as Waffenarm := (links, rechts) based on which the defense script could surmise that the parry weapon or shield must be held in the other hand. Based on this information, it could check if the attacker's direction, seen from the defending token, falls into a sensible range consistent with how Midgard understands the "front and left sides" of a token in combat, probably a 225° arc from -135° on the token's far left side to +90° delineating the end of what is "in front" of it. For staffs, we would expand this arc further to the 270° that are not squarely behind the token. Still, is it worth adding another attribute that needs to be consistently managed for all characters and NPCs?