5E Character Create Playlist
Page 34 of 64 First ... 24323334353644 ... Last
  1. #331
    Quote Originally Posted by Leprekorn View Post
    This is what I posted on Advanced Weapon Damage Is there a conflict with max?
    I tested in a new campaign with just CA and AWDE and SRD loaded dragged both lightbringer and hew item into the actions tab from the AWDE mod. Added a plant based creature and undead to the CT, tried lightbringer against the undead worked properly, tried lightbringer vs plant creature worked properly. Tried Hew against plant creature combined the max and the rolled damage worked incorrectly. Tried hew against the undead worked properly only applying the normal damage not maxed. Added type plant to the undead tried hew again worked incorrectly combining the max and the normal damage. I think it has something to do with the max damage trait.
    According to the forum post for the Advanced Weapon Damage extension, it uses "MaxDice" as the damage type. Constitutional Amendments uses the "max" damage type to cause the damage to reduce the target's maximum hp.
    My Forge creations: https://forge.fantasygrounds.com/crafter/9/view-profile
    My GitHub: https://github.com/MeAndUnique
    Buy me a coffee: https://ko-fi.com/meandunique
    Discord: MeAndUnique#6805

  2. #332
    Agreed but there is a conflict somewhere and it seems to relate to the MaxDice calc and CA

  3. #333
    Sorry, I misunderstood the situation. So given that it works as intended when the plant type is not present, and breaks when the type is present, it sounds like something is being handled awkwardly in AWDE, a blind hunch would be that it treats "max" the same as "MaxDice", which would cause problems. As I don't own that extension there's not really much I can do even to investigate, though I'm happy to discuss making adjustments in CA if Bratch9 identifies a path forward.
    My Forge creations: https://forge.fantasygrounds.com/crafter/9/view-profile
    My GitHub: https://github.com/MeAndUnique
    Buy me a coffee: https://ko-fi.com/meandunique
    Discord: MeAndUnique#6805

  4. #334

  5. #335

  6. #336
    Quote Originally Posted by MeAndUnique View Post
    Sorry, I misunderstood the situation. So given that it works as intended when the plant type is not present, and breaks when the type is present, it sounds like something is being handled awkwardly in AWDE, a blind hunch would be that it treats "max" the same as "MaxDice", which would cause problems. As I don't own that extension there's not really much I can do even to investigate, though I'm happy to discuss making adjustments in CA if Bratch9 identifies a path forward.
    This is not the case, when 'type(plant)' is included the target type is checked for its type and if it is NOT of type plant then the 'damage' caused by those dice will be removed. This happens between the CA applyDamage and the ruleset applyDamage as AWDE hooks into the applyDamage between these two due to load priority and modifies the sDamage and nTotal values to represent this line been 'removed' or not due to target 'type' check.

    CA is 'injecting' the old 'now' out of date values it cached when the CA call 'applyDamage' was called before AWDE 'applyDamage' and the ruleset 'applyDamage'

    As AWDE is a closed black box for you, I've created a simple 'simulation' ruleset 5e change, that forces all damage to be considered as zero by 'applyDamage'. ( As if an extension between CA and the ruleset had an 'applyDamage' function and modified the nTotal value. )

    With an unpacked 5e ruleset and this replacement file, any weapon or damage done that calls the 'applyDamage' should always result in zero damage to a target. This is the case when CA is not enabled, but with CA enabled you will see the old rolled values been re-injected into the 'applyDamage'. I've added a bunch of notes on the 'applyDamage' function at line 1074 for the simulation injection and then below that my notes on the reason and flow of why CA re-injects the old 'now' wrong values.

    Hope this helps sort out this issue.
    -Pete

    ( I've renamed the lua file to txt to have it upload, you need to rename it to .lua and override the 5e extracted version of the file in the ruleset\5e folder made by extracting the ruleset. )
    Attached Files Attached Files
    Last edited by bratch9; September 20th, 2021 at 18:54. Reason: edit: added notes in c++ style // instead of -- for lua.. so updated the file.

  7. #337
    Quote Originally Posted by bratch9 View Post
    This is not the case, when 'type(plant)' is included the target type is checked for its type and if it is NOT of type plant then the 'damage' caused by those dice will be removed. This happens between the CA applyDamage and the ruleset applyDamage as AWDE hooks into the applyDamage between these two due to load priority and modifies the sDamage and nTotal values to represent this line been 'removed' or not due to target 'type' check.

    CA is 'injecting' the old 'now' out of date values it cached when the CA call 'applyDamage' was called before AWDE 'applyDamage' and the ruleset 'applyDamage'

    As AWDE is a closed black box for you, I've created a simple 'simulation' ruleset 5e change, that forces all damage to be considered as zero by 'applyDamage'. ( As if an extension between CA and the ruleset had an 'applyDamage' function and modified the nTotal value. )

    With an unpacked 5e ruleset and this replacement file, any weapon or damage done that calls the 'applyDamage' should always result in zero damage to a target. This is the case when CA is not enabled, but with CA enabled you will see the old rolled values been re-injected into the 'applyDamage'. I've added a bunch of notes on the 'applyDamage' function at line 1074 for the simulation injection and then below that my notes on the reason and flow of why CA re-injects the old 'now' wrong values.

    Hope this helps sort out this issue.
    -Pete

    ( I've renamed the lua file to txt to have it upload, you need to rename it to .lua and override the 5e extracted version of the file in the ruleset\5e folder made by extracting the ruleset. )
    In the example, the only thing changed is nTotal; which is itself only used to pass in to decodeDamageText(). As such would it not be easier to have AWD extend decodeDamageText to account for the value change rather than decoding the value in an override of applyDamage?

    To clarify, I'm not opposed to making changes in CA, its just that it will take a while before I have the time to make the non-trivial changes and go through the rigor of testing. If the example is representative it should be a matter of 5 minutes to move AWD's decode logic to the ruleset's decode function, which would then be fully honored by CA's current approach.
    My Forge creations: https://forge.fantasygrounds.com/crafter/9/view-profile
    My GitHub: https://github.com/MeAndUnique
    Buy me a coffee: https://ko-fi.com/meandunique
    Discord: MeAndUnique#6805

  8. #338
    Quote Originally Posted by MeAndUnique View Post
    In the example, the only thing changed is nTotal; which is itself only used to pass in to decodeDamageText(). As such would it not be easier to have AWD extend decodeDamageText to account for the value change rather than decoding the value in an override of applyDamage?

    To clarify, I'm not opposed to making changes in CA, its just that it will take a while before I have the time to make the non-trivial changes and go through the rigor of testing. If the example is representative it should be a matter of 5 minutes to move AWD's decode logic to the ruleset's decode function, which would then be fully honored by CA's current approach.
    AWD is not as simple as this example, but suffers from the same re-injection of old values you capture on entry to CA applyDamage function as this simple case. ( I made a super simple case to show the re-injection of old values by CA. AWD does a lot of decode and repack of the applyDamage input variables. )

    Because CA also overrides decodeDamageText and is very selective on how it calls down to the original ( and hence a possible AWD decodeDamageText version, then the ruleset version ), only on the first call version when the CA applyDamage is called. This would also cause the AWD decodeDamageText to be totally skipped ( or called before any AWD applyDamage call to configure what might need to be changed in the decodeDamageText ) and you would still return the old values you captured at the start of your CA applyDamage. In exactly the same way you return the old values to the later ruleset version of decodeDamageText.

    Basically your decodeDamageText and its 'capture' of the values at the start of applyDamage into the local variable, and then just returns that until the messageDamage call, forces your CA applyDamage to sit direct on top of 5e ruleset applyDamage and anything that is between CA and Ruleset that changes values gets splatted on. ( Like in the very simple example I made for you, or the much more complex AWD version. )

    The use of a global and early capture of data that could change in CA applyDamage is causing the reset/reinject of these old values over any extension that sits between CA applyDamage and ruleset applyDamage.

    The best solution is to remove this global, and I gave a code change in my forum side, but as I do not know your extension I was not sure if it would cause malfunctions in your calculations. But it allow for the correct AWD and other extensions damage by not 'holding' onto the early data captured in the applyDamage call to decodeDamageText. ( it basically removed the 'if not' part in the decodeDamageText to allow later parameter calls to call down to the ruleset decodeDamageText function. )

    Its not a complex change, and I provided the source in my forum. If you have not already given it a go, check it out and see if it causes other malfunction in your calculations. Its a simple fix, but not a re-write of that area of code, so if not causing you malfunction is a quick solution compromise to this issue.

  9. #339
    While I appreciate the effort to provide an example of how things could conflict theoretically, I'm fairly well versed in how the ruleset functions and how the use of precalculation in CA interacts with it and with ~99% of other extensions successfully.

    Unfortunately, you were not able to so simply fix my extension for me. The suggested change may resolve the conflict with AWD, however it does so at the cost of breaking a number of other features in CA.

    In order to resolve the minority case of conflict with AWD I really do need a wholistic comprehension of its unique behavior. I need to know why AWD can't decode damage during decodeDamageText(). I need to understand why AWD allows sDamage and nTotal to reach applyDamage() when neither is ready for application. I need to consider the circumstances that prevented the damage from being modified during modDamage(). While I assume there are reasons and answers to each of these, as you have said, AWD is a closed black box to me.
    My Forge creations: https://forge.fantasygrounds.com/crafter/9/view-profile
    My GitHub: https://github.com/MeAndUnique
    Buy me a coffee: https://ko-fi.com/meandunique
    Discord: MeAndUnique#6805

  10. #340
    Bratch9 would it not make sense to gift MeandUnique a copy of your ext to help to resolve this?

Thread Information

Users Browsing this Thread

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

Bookmarks

Posting Permissions

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

Log in

Log in