---> Resistances and immunites are handled in 5e automatically with no extra syntax (uses 5e attributes by default). The string value of the 1 or 2 user-defined damage types (e.g. cold, fire, etc.) dealt by the spell/effect are searched for in their respective attributes (e.g. npc_resistances, npc_vulnerabilities, npc_immunities) and the individual damage component is multiplied by 0.5, 2, or 0 respectively. For non-5e games, the user can specify the attribute to search as well as the damage rule (e.g. minus 10 dam or whatever for PF/3.5) as described in the wiki (sorry for odd formatting here in the forums): Command Parameter(s) Description Default Value Example(s) [ Collapse ] Additional Notes -resistAttr <attrName> If the damageType(s) string is included in the current value of the denoted attribute, then the --resistanceRule will be applied npc_resistances --resistAttr|npc_resistances --resistAttr|npc_resistances, npcd_resistances If multiple attribute names are supplied, the script will check both NOTE : default is npc_resistances if this subcommand is omitted --vulnerableAttr <attrName> If the damageType(s) string is included in the current value of the denoted attribute, then the --vulnerableRule will be applied npc_vulnerabilities --vulnerableAttr|npc_vulnerabilities --vulnerableAttr|npc_vulnerabilities, someOtherAttributeName If multiple attribute names are supplied, the script will check both NOTE : default is npc_vulnerabilities if this subcommand is omitted --immunityAttr <attrName> If the damageType(s) string is included in the current value of the denoted attribute, then the --immunityRule will be applied npc_immunities --immunityAttr|npc_immunities --immunityAttr|npc_immunities, someOtherAttributeName If multiple attribute names are supplied, the script will check both NOTE : default is npc_immunities if this subcommand is omitted --resistanceRule <expression> The math operation (accepts single Operator and Operand) to be applied if target is resistant to damageType(s) *0.5 --resistanceRule|*0.5 --resistanceRule|/2 --resistanceRule|-10 NOTE : default is "*0.5" if this subcommand is omitted --vulnerableRule <expression> The math operation (accepts single Operator and Operand) to be applied if target is vulnerable to damageType(s) *2 --vulnerableRule|*2 --vulnerableRule|+10 NOTE : default is "*2" if this subcommand is omitted --immunityRule <expression> The math operation (accepts single Operator and Operand) to be applied if target is immune to damageType(s) *0 --immunityRule|*0 NOTE : default is *0 if this subcommand is omitted ---> I never thought about rotating squares (my players have never brought it up!), but off the top of my head it is technically possible using the "wall" AoE type rather than "square". A square type is always orthogonal w.r.t the grid. For a wall, you specify the width and height and two control tokens are spawned rather than one. The angle between the two control tokens determines the angle of the rectangle (a square in this case). To determine if you would "count" a partially covered square for a non-orthogonal AoE orientation, the --minGridArea command is used with a value up to 1 (100% coverage required). Here's an example of a 20ft square (instantiated as a "wall" instead of the "square" AoE type) being rotated, and grid squares are only counted in the AoE if at least 25% of the square is "in" the AoE. The percentage of a creatures token that must be in the AoE in order to force a save is also customizable based on GM preferences (useful for large tokens). I tweaked a Wall of Fire spell macro to create the example below. click for gif ---> Cover is currently not taken into account, though interaction with dynamic lighting lines is something I would really like to add in the future. I've done some graphical interaction with DL walls before with my Radar script, so I know it's possible. It's just the implementation is going to be a bear for this script. Someday, hopefully. Of course, even still, DL walls are all or nothing, so not sure any script is going to give satisfying automation for cover without something cute like differently colored lines being different heights or something. If you have a case where cover would modify Dex saving throws, then the two options are either (1) just use the script for targeting purposes and resolve the spell manually or (2) use the script to do all the rolls and auto apply damage, then manually adjust the hp if necessary on the one or two creatures in the area that would have benefitted from the cover. If you have a bunch of mook tokens that made saves that all look alike, you can click the token's icon in the chat and it will ping-pull to their location so you can easily identify which one "only failed by 2", for example.