Kelrugem's extensions

Quote:

---

Originally Posted by Kelrugem

But the effects support a duration after which the expire automatically? (I believe I misread your posts somewhere :D) What I wanted to add at some point is stuff which already exists in the FG ruleset of 4e, like expiring after a successful save with the option that an effect gets replaced with another effect depending on whether the save was a success or failure (the operators FAIL and AFTER) :) Did you maybe mean stuff like that? But I have to write my thesis at the moment (particle physics and gauge theory etc.), so, I have nearly no time, thence, when I can't find an immediate solution of implying such things when I update to 3.3.11 then I am always happy when someone else wants to add such things to the code :)

---

I'll take a look. :D
I'll give it one more shot to explain, too: One effect, part of which expires before the rest.

Quote:

---

Originally Posted by bmos

I'll take a look. :D
I'll give it one more shot to explain, too: One effect, part of which expires before the rest.

---

aaah, okay, now I understood, thanks :) So basically combining effects in one line but treating separate strings differently for expiration etc. :) Yeah, that is somehow similar to the operators FAIL and AFTER (but not completely, it goes into a similar direction) :) Yeah, that should be certainly possible :) I am happy when you can offer some code for that, or I try it while adding these other operators when I find time :)

Quote:

---

Originally Posted by Kelrugem

Hehe, I am happy about every proposal, even if it is a fake https://www.fantasygrounds.com/forum...es/biggrin.png

Finally, with the release of 3.3.11 in one or two weeks I try to make my extensions compatible with the new extensions which were released by others in the last weeks, that is

- Compatibility with Rmilmine's advanced effects extension (since it turns off the IFTAG code and maybe more)
- Compatibility with Bmos's spell failure roll
- Including Phixation's damage types for overcoming things like resistance
- Including an ACCC effect (AC against criticals; though I am not sure if I will be able to implement that since I need to beware compatibility with existing effects with respect to stacking); that was a user request of someone who added that already in their own campaign
- Raust has observed an FGU error for strainInjury. But that may be related to 3.3.11 since FGU is running on 3.3.11, even on the live servers. So, it might be fixed by updating to 3.3.11
- Compatibility of the height label with hex grids
- Anything extra when time is left like the extra parsing tags requested in the save versus tags thread (the tag disbelief when I remember it correctly)

I can't promise that I succeed with everything though 3.3.11 compatibility has highest priority such that you can update without issues https://www.fantasygrounds.com/forum...lies/smile.png

Did I miss something? Then please let me know https://www.fantasygrounds.com/forum...lies/smile.png

---

Another feature I try to do: Adding automatic parsing for custom modules :)

Quote:

---

Originally Posted by Kelrugem

Another feature I try to do: Adding automatic parsing for custom modules :)

---

If you could also set an extension to brew coffee whenever the DM is getting tired.... :°D

Quote:

---

Originally Posted by Asgurgolas

If you could also set an extension to brew coffee whenever the DM is getting tired.... :°D

---

:D that's a good idea :D

Just a warning: 3.3.11 got releases today :) I need to update now, but it can take a while :) In some hours I am hopefully done

*waiting impatiently*

Quote:

---

Originally Posted by Asgurgolas

*waiting impatiently*

---

:P

I just finished it, in the next minutes I am uploading it and will present the new shiny features! :D

I have updated to 3.3.11:

AoO
Advanced 3.5e and Pathfinder
Save versus tags
StrainInjury
Height
(Dis) advantage (included in save vs tags)

and every package where these are contained (so, nearly everything :D) The cheat sheet got updated, too :) Please let me know of any problem etc., it is likely that I may have done some mistake, sat around 13 hours on all of that, really need sleep now :D

See here for more infos: https://www.fantasygrounds.com/forum...l=1#post528289 and https://www.fantasygrounds.com/forum...l=1#post528291

I was checking the updates there, and in the save versus tag I just noticed you talk about a "ROLLON" effect... I think I totally missed it so far: what does it do?
"

Quote:

---

Originally Posted by Asgurgolas

I was checking the updates there, and in the save versus tag I just noticed you talk about a "ROLLON" effect... I think I totally missed it so far: what does it do?
"

---

It automatically rolls on a table at the beginning of someone's turn :)

So, e.g. when you have the effect ROLLON: confusion and some table with the name confusion, then it will automatically roll on that table at the beginning of that person's turn :) (it has the same options as the /rollon macro :) )

Awesome :O

I need to do some survey:

Would it be okay when I would just offer the FullOverlay Package (plus a version for StrainInury and StrainInury with the Overlays) instead of separate versions for just Save versus Tags and advanced 3.5e/PF1 and their packages/combinations? I would add an option in the FullOverlay extension with which you can define whether you get overlays or not (maybe with some granularity whether just wounds overlays, or just save overlays, or both for example) :)

The reason why I am asking is that maintaining the extensions is immense already and that is probably due to all the packages. Either I need to ask an IT professional how they do such things or I just offer the "product with everything" for reducing the time for maintenance :) (The extensions reached a complexity which makes it impossible to just "copy&paste" into the packages :D For example, advanced 3.5e/PF1 completely rewrites the damage script as you probably know, and that I can't simply copy&paste into StrainInjury for example due to the different hitpoint system there :) ) I have seen that when someone uses my extensions, then at least save versus tags and the advanced 3.5e/PF1 and not just one of both. But not everyone wants to have the overlays, which is the reason why I would add an option in the overlay extension then :)

I would keep the subthreads for listing the features but it may be easier for me that I only need to change two/three extensions when I add new features :) (antimagic, height etc. still stay separate, they are simple enough in that regard)

When I would do this then in some months probably, e.g. when 3.3.12 is released. I just do some brainstorming about how to treat my extensions (and then it is probably also easier for users to see what they need to download)

I'd be in for the whole package with the possibly to toggle the overlay parts :P
that full overlay package became my staple extension by now :°D

Sounds good to me. We use the full overlay + height extensions.

Same, although the if checks to disable that part should hopefully be placed in such a way to maximize compatibility.
I think the overlays part has more conflicts with other extensions?

I've been meaning to switch to FullOverlays anyway and just haven't had time to vet it for compatibility.

Thanks for the answers :)

Quote:

---

Originally Posted by bmos

Same, although the if checks to disable that part should hopefully be placed in such a way to maximize compatibility.
I think the overlays part has more conflicts with other extensions?

I've been meaning to switch to FullOverlays anyway and just haven't had time to vet it for compatibility.

---

Yeah, the overlay part is completely in ManagerToken2 :) But I do not need to overwrite that on a second sight. So, I will probably create a new ManagerToken3 for better compatibility and then there will be the if-check part whether the overlays are used :) That should be the best compatibility option :) (of course, the function to call and change the overlay depending on the result of a save etc. has to be in the corresponding script, that can in general cause incompatibilities; but these scripts are normally already overwritten by my extensions without the overlays :D)

I also intend to add every feature and its description into the cheat sheet. All the threads already become very unreadable such that the cheat sheet as a manual might be a good separate option :)

In my game on Sunday, I had an NPC with this ability:

Unusual Anatomy (Ex)
A denizen’s internal anatomy varies from individual to individual, and has a 50% chance to treat any critical hit or sneak attack against it as a normal hit.

For which I applied the "FORTIF: 50 all" effect. But it seemed to be applied incorrectly in this case, perhaps you can tell me why:

Code:

---

Raevik Sinnethar: [CAST] Mind Thrust VI [at Weiralai]
Weiralai: [SAVE] Will [SPELL] [DIVINATION] [EFFECTS -6] [DISADV] [1d20+11 = 14]
Save [14][vs. DC 24] -> [for Weiralai] [vs Raevik Sinnethar] [FAILURE]
Raevik Sinnethar: [CL CHECK] Mind Thrust VI [at Weiralai] [SUCCESS] [1d20+17 = 36]
Effect ['Exhausted; Stunned'] -> [to Weiralai] [by Raevik Sinnethar]
Raevik Sinnethar: [DAMAGE] Mind Thrust VI [TYPE: spell (13d8+13=66)] [13d8+13 = 66]
Raevik Sinnethar: [FORTIFICATION CHANCE 50][vs. spell][to Weiralai][ZERO DMG] [1d100 = 29]
Damage [0] -> [to Weiralai] [RESISTED]

---

Weiralai is a Denizen of Leng with some Cleric levels for reference.

Quote:

---

Originally Posted by darrenan

In my game on Sunday, I had an NPC with this ability:

Unusual Anatomy (Ex)
A denizen’s internal anatomy varies from individual to individual, and has a 50% chance to treat any critical hit or sneak attack against it as a normal hit.

For which I applied the "FORTIF: 50 all" effect. But it seemed to be applied incorrectly in this case, perhaps you can tell me why:

Code:

---

Raevik Sinnethar: [CAST] Mind Thrust VI [at Weiralai]
Weiralai: [SAVE] Will [SPELL] [DIVINATION] [EFFECTS -6] [DISADV] [1d20+11 = 14]
Save [14][vs. DC 24] -> [for Weiralai] [vs Raevik Sinnethar] [FAILURE]
Raevik Sinnethar: [CL CHECK] Mind Thrust VI [at Weiralai] [SUCCESS] [1d20+17 = 36]
Effect ['Exhausted; Stunned'] -> [to Weiralai] [by Raevik Sinnethar]
Raevik Sinnethar: [DAMAGE] Mind Thrust VI [TYPE: spell (13d8+13=66)] [13d8+13 = 66]
Raevik Sinnethar: [FORTIFICATION CHANCE 50][vs. spell][to Weiralai][ZERO DMG] [1d100 = 29]
Damage [0] -> [to Weiralai] [RESISTED]

---

Weiralai is a Denizen of Leng with some Cleric levels for reference.

---

The fortification effect is very universally coded, that means that it technically allows every damage type :) So, the all-descriptor would tell FG that it does test fortification for every damage type and explains what you are seeing; the effect you need is: FORTIF: 50 critical; FORTIF: 50 precision :) Then it applies only to sneak and critical hits :) I didn't restrict the amount of available damage types for this effect because there was no need to, one can cover the standard definition of fortification, but one can define its usage to other damage types if one wants but it is optional of course (and if I remember correctly, some people needed something similar for weapon damage types) :)

Oh ok. I thought sneak attack and so forth were built into FORTIF. Where is the definitive documentation on that effect? In this thread at the top?

There is another case that can't be handled because there isn't a 'sneak attack' damage type that is separate from precision. There are some abilities, such as the Investigator's Studied Combat, that deal precision damage, but only for the purpose of not multiplying on a crit, they are otherwise not treated as sneak attacks and so should not be subject to the fortification effect of the ability above.

Can arbitrary damage types be used? For instance, could I use FORTIF: 50 sneak; FORTIF: 50 critical

Quote:

---

Originally Posted by darrenan

Oh ok. I thought sneak attack and so forth were built into FORTIF. Where is the definitive documentation on that effect? In this thread at the top?

---

Ah, I see :) It works like RESIST etc., so, one needs to specifiy the specific damage type (but yes, in that case one could have a built-in integration of critical and precision when just following the standard rules). Yes, the documentation is either in the thread of advanced 3.5e and PF1, https://www.fantasygrounds.com/forum...finder-effects, there I wrote (I shortly edited it, there was some strange not finished sentence seemingly :D)

Quote:

---

1. To apply fortification use: 'FORTIF: (N) [damage type]' or 'FORTIF: (N) all' :) (N) is some arbitrary number describing the percentage and damage type is as usual. E.g. when you want light fortification, then your effect is 'FORTIF: 25 critical; FORTIF: 25 precision'. But you can use any other number and any other damage type if you have any house rules for different fortification rules :) When fortification is executed you will see a message in the chat showing you the roll result(s) and if it was a success or failure :) The applied damage is modified accordingly. Any combination of damage types should works as expected when one "naturally extends" the rules.

---

I also have a pdf here, https://www.fantasygrounds.com/forum...l=1#post452700 (the bottom), there I list all my effects etc. as in the wiki, at least I try :) There it is on page 2:

FORTIF

(N)

[damage type], all

(T), fortification with percentage N against a specific damage type

I think the latter contains all informations of the effect :)

Will FORTIF respect damage types that aren't in the 'official' list i.e. arbitrary damage type strings? Or does it check against the damage types collection data_common.lua?

Quote:

---

Originally Posted by darrenan

Will FORTIF respect damage types that aren't in the 'official' list i.e. arbitrary damage type strings? Or does it check against the damage types collection data_common.lua?

---

Only the ones in data_common.lua :) you need it against arbitrary strings?

Hi :)

There was some small hotfix today for 3.5e/PF1 (see https://www.fantasygrounds.com/forum...176#post530176), and I needed to update everything containing save versus tags, please redownload packages with save versus tags (and/or save versus tags itself) :) But it is a small fix for some edge case of custom DCs, so, you do not necessarily need this. Also no worries about bad things going on, when you do not have that hotfix immediately :)

Switched to FullOverlays. Awesome stuff. Should have been using it sooner.

Thanks as always.

Quote:

---

Originally Posted by bmos

Switched to FullOverlays. Awesome stuff. Should have been using it sooner.

Thanks as always.

---

Thanks :)

I just noticed that additional tags in spells are getting populated with a missing delimiter. I'm pretty sure that logic is in your extensions right? Anyway, here's a screenshot of what I'm talking about:

Attachment 38431

Notice the missing semi-colon between mind-affecting and one. This is a spell I dragged from the "PFRPG - Spellbook" module. Please tell me I don't need to go back through all the NPCs I've prepped recently and fix them?

Quote:

---

Originally Posted by darrenan

I just noticed that additional tags in spells are getting populated with a missing delimiter. I'm pretty sure that logic is in your extensions right? Anyway, here's a screenshot of what I'm talking about:

Attachment 38431

Notice the missing semi-colon between mind-affecting and one. This is a spell I dragged from the "PFRPG - Spellbook" module. Please tell me I don't need to go back through all the NPCs I've prepped recently and fix them?

---

No worries, that is fine :) You do not need a semi-colon, that was legacy of an old code where this was needed, but now a space for separating tags is fine, too :) This is due to the last update after which it is now possible that tags are also parsed when it is a custom spell with custom actions. (For some reason: An if-clause for checking, whether or not a semicolon should be added, did not work, therefore I decided to simply use a space :) But that is just something visual, it is still working as usual :) )

In the last update I also wrote it:

Quote:

---

Possible new tags will then be added at the end of all the tags, separated with a space (the semicolon approach looked strange in general); that is just something visual, separating with a space is also okay when it is about automation. The semicolon was just legacy

---

It may be not visually appealing, but it works as expected :) (I just tested, tags separated by spaces are recognized as different tags, too :) )

ok, cool, thanks

Please redownload both Full OverlayPackages :) (when you use the StrainInjury version, then you do not need to redownload your version :) )

For whatever reason, these extensions were not always registrating the custom damage types. I zipped the extension again, and it still didn't work completely. Then I made a copy and zipped again, now it works... :D I literally just did a copy, I changed nothing, so, please do not ask me why this works, please let us all simply accept that this fixed it xD

Quote:

---

Originally Posted by Kelrugem

Please redownload both Full OverlayPackages :) (when you use the StrainInjury version, then you do not need to redownload your version :) )

For whatever reason, these extensions were not always registrating the custom damage types. I zipped the extension again, and it still didn't work completely. Then I made a copy and zipped again, now it works... :D I literally just did a copy, I changed nothing, so, please do not ask me why this works, please let us all simply accept that this fixed it xD

---

Well, can't argue with results. Works perfectly now. Thanks!

Quote:

---

Originally Posted by mozmonar

Well, can't argue with results. Works perfectly now. Thanks!

---

cool, that is good that you can confirm it :) Not sure what was going wrong there before :)

I've got another resulthandler compatibility patch for you :)

Code:

---

if DiseaseTracker then
        ActionsManager.registerResultHandler("disease", ActionDiseaseSave.onRoll);
        ActionsManager.registerResultHandler("diseasetimeroll", ActionDiseaseTimeRoll.onRoll);
end

---

EDIT: I added another handler that I now use in the disease extension also.

Quote:

---

Originally Posted by bmos

I've got another resulthandler compatibility patch for you :)

Code:

---

if DiseaseTracker then
    ActionsManager.registerResultHandler("disease", ActionDiseaseSave.onRoll);
end

---

---

Ah, thanks :) Where it should be placed in the best way? (to avoid that I need to update all of them? :) ) Sounds like save versus tags may be the best? :) (I mean its incompatibility is with save versus tags and not the advanced one, isn't it? :) )

Quote:

---

Originally Posted by Kelrugem

Ah, thanks :) Where it should be placed in the best way? (to avoid that I need to update all of them? :) ) Sounds like save versus tags may be the best? :) (I mean its incompatibility is with save versus tags and not the advanced one, isn't it? :) )

---

I think it's advanced effects. It's the same issue as Spell Failure and Mirror Image (where your list of resulthandlers overrides any other extension's resulthandlers -- likely as a result of replacing ActionsManager).

Probably any that modify manager_action_attack.lua (where the patch I posted should be inserted).

Quote:

---

Originally Posted by bmos

I think it's advanced effects. It's the same issue as Spell Failure and Mirror Image (where your list of resulthandlers overrides any other extension's resulthandlers -- likely as a result of replacing ActionsManager).

Probably any that modify manager_action_attack.lua

---

Ah, okay, thanks, I try that :) (still a strange issue overall :D)

The Full OverlayPackage is reuploaded :) I accidentally uploaded my backup extension where some old graphics were still stored which should not be contained anymore :)

I made the extensions now compatible with bmos's extensions :) Please redownload all extensions containing AoO and/or advanced 3.5e/PF1 :)

Gladly I waited until today such that I also added your other handler, @bmos :D By the way, I also thought about maybe changing the offset of the wound boxes etc.; do I still need to do that? When your loadorder is higher than mine then you probably already overwrote that part maybe? :) (just delete the script part and do not use merge=replace but merge=join :) then it will still use my script but your offset when both loaded, I think :) )

Quote:

---

Originally Posted by Kelrugem

I made the extensions now compatible with bmos's extensions :) Please redownload all extensions containing AoO and/or advanced 3.5e/PF1 :)

Gladly I waited until today such that I also added your other handler, @bmos :D By the way, I also thought about maybe changing the offset of the wound boxes etc.; do I still need to do that? When your loadorder is higher than mine then you probably already overwrote that part maybe? :) (just delete the script part and do not use merge=replace but merge=join :) then it will still use my script but your offset when both loaded, I think :) )

---

I switched my load order back to how it was, so the boxes would still be an improvement (in my opinion at least).
Nice timing on the update. It looks like I got very lucky; I had been planning to wait to release 1.7 until next week, but was really hoping that I could sneak in that final handler before you found time :D

If any users of Disease Tracker get errors on load, ensure that you have the latest versions of both that and whichever Kelrugem ext you use.