Kelrugem's extensions

[Asgurgolas]

Is this necessary with Kel’s extension? Meaning, if you have the “Effect” Uncanny Dodge on, isn’t it’s sole effect is to prevent getting the flat-footed effect/label in the first place?

Kelrugem's extension's Uncanny Dodge only prevents the automatic flat-footed at the start of combat. Flat-footed still negates your dexterity bonus when applied (and if you're a monk or swordsage or duelist or whatever else, it also removes all those wisdom/intelligence bonuses to AC), thus I made it so it still adds those bonuses (also if the character has dodge bonuses from somewhere else it's adviceable to add'em too, such as "uncanny dodge; IF: flat-footed; AC: [DEX] [WIS]; AC: X (where x stands for your dodge bonus)"-

Especially in 3.5 there are lots of instances in which you can apply flat-footed on people in moments different than combat start (feints, swordsage maneuvers for example). True, if you know a given character has uncanny dodge you can just avoid applying the effect, but when your combat tracker has 6 characters, 2 NPCs and 8 enemies (with players bombarding you with questions) you can easily forget, that's why I set it up to work that way in the case I forget.

[Kelrugem]

Thanks for all the effects, I appreciate it and will look over them Once I added those to the forge page, I will also mention your names as contributors

About uncanny dodge: Indeed, right now it just prevents the automatic flat-footed at the start of the combat; however, the github version already has a fully automated uncanny dodge version Hence, the next release will already and hopefully cater for all situations

(but only uncanny dodge; the special thing coming from improved uncanny dodge not yet. Especially the level comparison of "barbarian" and "rogue" may not come that soon)

[Croddwyn]

(I thought CA was targetable)?

You could totally be right about that. I know that it works as I have it, but that's just copying the pattern I used in the other effects.

[Asgurgolas]

Thanks for all the effects, I appreciate it and will look over them Once I added those to the forge page, I will also mention your names as contributors

About uncanny dodge: Indeed, right now it just prevents the automatic flat-footed at the start of the combat; however, the github version already has a fully automated uncanny dodge version Hence, the next release will already and hopefully cater for all situations

(but only uncanny dodge; the special thing coming from improved uncanny dodge not yet. Especially the level comparison of "barbarian" and "rogue" may not come that soon)

Improved uncanny dodge could easily be done with a chain NIFT, such as setting "Improved Uncanny Dodge; L9 (to say "rogue or barbarian or warblade or whatever class or sum of classes with uncanny dodge up to 9"), then set your say, level 12 rogue with:

Sneak Attack; IF: CUSTOM (flanking); NIFT: CUSTOM (L20); NIFT: CUSTOM (L19); all the way 'till L8, which is the maximum level of improved uncanny dodge a 12th level rogue could sneak attack for, and you can just ignore lower levels); DMG: 6d6 precision"

it's pretty long but you actually just add it on flanking scripts (since improved uncanny dodge only triggers when being sneak-attacked from a flanking position) and forget it there. Then, by using the three effects I mentioned a few posts ago (and modifying the Flanking section with this Lx thing) it pretty much works. What I don't know is how much it could clog FGU's processing though

[chaiwalla]

Not to beat dead horse, but for the purpose of playing around with effects: Another Sneak Attack Damage method, including feint's CA, stealth's CA, flanking and target having conditions that give "nodex" (stunned, etc...).

"Spell" effects:
Flanking; ATK: 2; TURNRE;
REMOVE: Flanking; ATK: 2; TURNRE;
Stealth; NIFT: CUSTOM (Uncanny Dodge); CA; TURNRE;
REMOVE: Stealth; NIFT: CUSTOM (Uncanny Dodge); CA; TURNRE;
Feint; CA; TURNRE;
REMOVE: Feint; CA; TURNRE;

Static:
IF: CUSTOM (Sneak); NIFT: nodex; DMG: 3d6 precision;
IF: CUSTOM (Flanking); Sneak;
IF: CUSTOM (CA); Sneak;
IFT: nodex; DMG: 3d6 precision;

The REMOVE and TURNRE (which ends the effect line at the end of the actors turn) from rhagelstrom's Better Combat Effects) I thought were "needed" as feint and successful stealth attacks are often one-shot deals. Feint gets around Uncanny Dodge, but CA from hiding/being invisible doesn't. Also (N)IFT: nodex; needs to be followed by a modifier, not a label word (i.e.: IFT: nodex; Sneak wasn't giving the label Sneak to trigger the IF: CUSTOM (Sneak).

Attachment 50548

[MostTornBrain]

Hi,

I'm using Pathfinder 1E.

There appears to be a bug when a critical threat occurs during an attack with an ATK effect in place in the combat tracker. When the critconfirm is rolled, the effect is added in (as it should be) however when the final crit result is reported, it adds the effect in again, effectively doubling whatever the effect was. Here is a screenshot showing the issue:

Screen Shot 2022-01-02 at 10.49.00 AM.png

As can be seen there, I added an ATK:1, which is reflected in the initial attack rolls ("EFFECTS+1") which for the die roll of 20, adds a total of +4 (+1 for the effect and +3 for the char's str bonus). Then, the crit confirm roll is made, and a 1 was rolled, and +4 was added (which includes the ATK:1 effect) for a result of 5. Then, the final chat line showing the crit result adds in "EFFECTS +1", changing the result to 6, which is incorrect.

I suspect the issue is related to the code in manager_action_attack.lua", around line 482 where it takes into account any effects for the crit confirm result. Should it really be doing this since the crit confirm roll already did?

If I unload the extension, things behave correctly, as can be seen in this screenshot. The critconfirm roll and the final critconfirm result are the same, as they should be:

Screen Shot 2022-01-02 at 11.06.18 AM.png

EDIT: looking at the two screenshots, there is also a discrepancy in the reporting of the crit confirm roll when the extension is loaded - it adds the effect in (as can be seen by the +4 added to the roll), but doesn't include the text "EFFECTS +1", which might be clue as to why the extension then adds the effect in again in the final crit result reporting line. When the extension is not loaded (as seen in the second screenshot) the "EFFECTS +1" message is added to the critconfirm roll and is not present in the final crit result line.

Cheers,
Brian

[Kelrugem]

Hi,

I'm using Pathfinder 1E.

There appears to be a bug when a critical threat occurs during an attack with an ATK effect in place in the combat tracker. When the critconfirm is rolled, the effect is added in (as it should be) however when the final crit result is reported, it adds the effect in again, effectively doubling whatever the effect was. Here is a screenshot showing the issue:

Screen Shot 2022-01-02 at 10.49.00 AM.png

As can be seen there, I added an ATK:1, which is reflected in the initial attack rolls ("EFFECTS+1") which for the die roll of 20, adds a total of +4 (+1 for the effect and +3 for the char's str bonus). Then, the crit confirm roll is made, and a 1 was rolled, and +4 was added (which includes the ATK:1 effect) for a result of 5. Then, the final chat line showing the crit result adds in "EFFECTS +1", changing the result to 6, which is incorrect.

I suspect the issue is related to the code in manager_action_attack.lua", around line 482 where it takes into account any effects for the crit confirm result. Should it really be doing this since the crit confirm roll already did?

If I unload the extension, things behave correctly, as can be seen in this screenshot. The critconfirm roll and the final critconfirm result are the same, as they should be:

Screen Shot 2022-01-02 at 11.06.18 AM.png

EDIT: looking at the two screenshots, there is also a discrepancy in the reporting of the crit confirm roll when the extension is loaded - it adds the effect in (as can be seen by the +4 added to the roll), but doesn't include the text "EFFECTS +1", which might be clue as to why the extension then adds the effect in again in the final crit result reporting line. When the extension is not loaded (as seen in the second screenshot) the "EFFECTS +1" message is added to the critconfirm roll and is not present in the final crit result line.

Cheers,
Brian

Thanks for the report, I can take a look However, the problem may be that I was still not able yet to update my extension to the new ruleset version, so, it may come from that because my extensions are still for the older ruleset versions It may sadly still take a while until I can look at that

[MostTornBrain]

Thanks for the report, I can take a look However, the problem may be that I was still not able yet to update my extension to the new ruleset version, so, it may come from that because my extensions are still for the older ruleset versions It may sadly still take a while until I can look at that

Comparing the changes introduced by the extension vs. what is in the current 3.5E Lua rule scripts, it appears that lines 480-492 in the extension's version of manager_action_attack.lua are not present in the 3.5E manager_action_attack.lua file nor are they designated by "--KEL" comment tags, so perhaps these are from the old ruleset version and should no longer be present?

As a quick test, I commented out those lines in my local copy of the extension and now crit confirms behave as expected, including adding the "EFFECTS +1" message to crit confirm roll rather than the crit confirm results message.

I used a project diff viewer to try to spot check any other potential significant divergence from the extension's copy of lua scripts vs. the 3.5E files and that was the only one that jumped out at me related to attack roll behavior.

Cheers,
Brian

[Kelrugem]

Comparing the changes introduced by the extension vs. what is in the current 3.5E Lua rule scripts, it appears that lines 480-492 in the extension's version of manager_action_attack.lua are not present in the 3.5E manager_action_attack.lua file nor are they designated by "--KEL" comment tags, so perhaps these are from the old ruleset version and should no longer be present?

As a quick test, I commented out those lines in my local copy of the extension and now crit confirms behave as expected, including adding the "EFFECTS +1" message to crit confirm roll rather than the crit confirm results message.

I used a project diff viewer to try to spot check any other potential significant divergence from the extension's copy of lua scripts vs. the 3.5E files and that was the only one that jumped out at me related to attack roll behavior.

Cheers,
Brian

I recall that there was a change about that code precisely because of such a CC attack bug, so, that was probably fixed with the latest update and I need to include that now

Thanks for the investigation, I try to update (finally) my extension soon

[dogfisc]

Nice work MostTornBrain; I had noticed that during my game Saturday but hadn’t tracked it down yet.