1. #1
    Kelrugem's Avatar
    Join Date
    Sep 2018
    Location
    Geneva, Switzerland, and Lyon, France
    Posts
    606

    (Prototype) Extension for (dis)advantage

    Hi

    I wrote some little extension to apply advantage and disadvantage to the next roll made/forced, simply give the PC or NPC the effect keladvantage and keldisadvantage, respectively The reason for the prefix "kel-" is simply that the effect will be automatically removed after the roll is made by searching for the pattern "keladvantage" and "keldisadvantage", respectively (to avoid that your informational effects are removed which may have the term "advantage" or "disadvantage"; I've added a separate version without this removal but the effects have still the same name)
    The rolls affected are the ones coming from the dice buttons in character sheets (physical dice also only), it does not work for "/die..." macros and not for the physical dice under the chat which one can drop over the chat (but drag&drop for the sheet-dice respects this, also with the manual rolls turned on). I tested a MoreCore custom macro and for that it worked, too, but no guarantee for that (Examples for 3.5/PF1: See below)
    The chat message has information about when (dis)advantage is used ([ADV] and [DISADV]).

    I edited the manager_actions.lua, especially the functions roll and resolveAction. So all rolls using these functions should be affected by that, I assume that e.g. the /die macros are not using them and therefore are not affected by this (but also probably due to that effects are connected to characters and NPCs and not directly to the host and client). At the top of that file are two new functions.

    For developers: I added the strings rRoll.adv and rRoll.disadv, with them you can try to code similar effects but then also just for the next roll of specific type like save and skill as one has in 5e But I didn't test that yet, define rRoll.adv = "true" and rRoll.adv = "true" and then you should be able to code advantage and disadvantage, respectively (as strings, not boolean; was too lazy to convert that :P I can change that of course if you want )

    This should work for many rulesets, but there is a reason why I wrote prototype: Making rolls is a complicated thing such that a general code does not always work, depending on the context. Thence, when you want to use that extension then always test it before Test the roll you want to give advantage to and test it against targets for attacks and so on; and give the effect only just right before the roll is made since some other buttons without actual dice count as a "roll", too, see an example in the list below (except when you have the version without automatic removal but then it's always applied :P). I tested 3.5e and had the following observations (see also the EDIT at the bottom):
    • It works for all (?) rolls except some parts of the damage roll. The damage roll has in its description the information about damage types and their distribution (rRoll.clauses). This gets doubled when one has some of the effects but their information is not removed afterwards (corresponding to the rules of advantage and disadvantage) because CoreRPG does not know anything about these informations, so no way to remove this information on that level, I guess. I will integrate this into my advanced effects extension for 3.5e/PF1 when I was able to solve that problem There the effects will then be without that prefix "kel-" because one can define effects there in such a way that they expire on the next roll, action and so on but attack rolls seem to work and the correct value seems to be taken for comparisons with ACs (similar for other rolls gladly, except damage)
    • The cast button does not respect it, but pressing the attack, CLC and save button separately works and respect that. So, when the target has disadvantage then their forced save roll will respect that when the caster presses the single cast button Funnily: When the caster casts on him-/herself then he/she does not get (dis)advantage on saves although the effect is there (but for attack and CLC it seemingly still works). This seems to be independent wether it's the client or host or NPC or PC <> PC interaction etc.. This "bug" only happens when the caster forces his/her own save and I do not really understand why while everything else works for spells (EDIT: This may be due to that the parsing of the save description is a "roll", too, which then already removes the effect from the caster before the actual save roll is made. Similar argument for the cast button. I will fix this when I integrate this into my 3.5 extensions, that's easy to fix when one is on a specific ruleset layer. But not really possible on CoreRPG level. Therefore: Really test everything before. It can never 100% work without extra information of specific rulesets. I can fix this on CoreRPG level by removing the automatic removal of these effects. When you want I will do that)
    • Effects for adding additional dice to several rolls like initiative are respected, too
    • Party sheet rolls are also respected. So seemingly only the three situations (cast button, damage and "own forced save") are missing though this may not be needed for the cast button because there is not really any definition about which of the included rolls should get (dis)advantage (and since this a very generic effect giving any next roll advantage)
    • It's independent of the type and number of dice, gladly But: When you have more than one die as in 2d6 then there is no visual clue yet which dice are taken, it does not necessarily take the combination with the highest/smalles result but it's still correctly handled. E.g. for 2d6 every d6 gets a separate d6 partner so they build some pair. From this pair the highest/smallest number is taken, but you can not really see which dice are paired because all will have the same colour You have to trust my code then :P

    Let me know how it works for you and really test that extension before you use it in your campaign I made this because there was a user request for having (dis)advantage rolls for initiative in 3.5/PF1 and that seems to work

    Best,

    Kelrugem

    EDIT: works for 3.3.8 and already also for 3.3.9

    EDIT2: I now added a separate extension where you do not have the automatic removal. This fixed all the issues I have seen in 3.5e/PF1 (except that with damage because this is really not possible on CoreRPG level) But you have to think about removing the effect then again (I may find a better solution in my extension later) or you define the effect in such a way that it expires on the next roll but then the cast button and "save on me" problem comes back (so for these situations you need it without the automatic removal)
    Attached Files Attached Files
    Last edited by Kelrugem; October 10th, 2019 at 20:14.

  2. #2
    Kelrugem's Avatar
    Join Date
    Sep 2018
    Location
    Geneva, Switzerland, and Lyon, France
    Posts
    606
    I now added a separate extension where you do not have the automatic removal. This fixed all the issues I have seen in 3.5e/PF1 (except that with damage because this is really not possible on CoreRPG level) But you have to think about removing the effect then again (I may find a better solution in my extension later) or you define the effect in such a way that it expires on the next roll but then the cast button and "save on me" problem comes back (so for these situations you need it without the automatic removal)
    Last edited by Kelrugem; October 10th, 2019 at 19:49.

  3. #3
    Kelrugem's Avatar
    Join Date
    Sep 2018
    Location
    Geneva, Switzerland, and Lyon, France
    Posts
    606
    Some other observation (edited this also into the first post):

    It's independent of the type and number of dice, gladly But: When you have more than one die as in 2d6 which are also of the same type, then there is no visual clue yet which dice are taken, it does not necessarily take the combination with the highest/smalles result but it's still correctly handled. E.g. for 2d6 every d6 gets a separate d6 partner so they build some pair. From this pair the highest/smallest number is taken, but you can not really see which dice are paired because all will have the same colour You have to trust my code then :P
    Last edited by Kelrugem; October 10th, 2019 at 20:55.

  4. #4

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Log in

Log in