FG Forge
Page 12 of 12 First ... 2101112
  1. #111
    Quote Originally Posted by MeAndUnique View Post
    Personally, I do not think that CA and AWDE have hit the point of concluding incompatibility. However, given that CA works on its own and with roughly 100 other extensions of varying capabilities including additions to the modifier stack and dammage application, if I am to be able to address the present conflict in CA I require either more constructive guidance than being advised to rewrite it, or a better understanding of exactly how AWDE deviates from the ruleset.
    AWD interacts with the applyDamage function that you also change, which breaks the 'assumption' in your extension that you can hold the decodedDamageText as static. Because it is not.

    Since applyDamage is calling the decodeDamageText the inputs to applyDamage can be 'adjusted' in extension. Like you do in your extension. I just dont assume that it is 'static' or that no other extension could possibly be in the calling stack of overrides for applyDamage call chain.

    The issue is that your extension 'assumed' that once you had processed 'applyDamage' and then called down into the 'chain' of possible other extensions that could overload this function, that they would not also change something in the call process. ( Which since you wrap this function to apply your own changes, you can not assume other will not also apply changes before it hits the actual ruleset function. ) Your extension is holding the value from your extension level call, and then passing it back into the 5e ruleset version and assumes nothing will ever happen to it or be between you and the ruleset function.

    AWD also scans the damage lines before calling the ruleset applyDamage, and can change the lines. Which makes this a dynamic item. Your extension should not be assuming it is static which it will be if no other extension is in the stack that access/changes the applyDamage function.

    I dont think the suggestion change I've posted will cause you any issue, because AWD does not change the decoded outputType which is what you are holding from the stored value. You could reduce what you store in the local value to just that one item. Then not have caused this conflict.

    The reason I can not fix it in my extension, is because yours sits on top of mine and is pushing back in the stored values. Without changing my load priority I can not resolve it. As far as I know my extension does not break your extra codes as they pass through my extension. But in theory we could have some extra interaction like this. ( Like the 'transfer' damage code I already talked about. )

    I also do not think you should be doing 'extra' work in the 'messageDamage', as people will not be expecting this. I know you do it so you do not have to adjust the applyDamage function in a mid code point, which causes a possible massive conflict point. So I understand why you do this. But I suggest you look to see if you can do this work before the applyDamage or post the applyDamage function. But this would be a more of the re-write I think you should do.

    I do think you should just store the 'decodeResult.sType' which is all you use outside the applyDamage function, then you could store this at the point you 'decodeDamageText' in your applyDamage function, and then totally remove your access to the 'decodeDamageText'. Since you link into messageDamage you can use this to change your sTypeOutput to "maximum hit points'. I've not looked into the 'effectmanage/actiondamage' calls in applyDamage so it might not be possible to remove the decodeDamageText 'sTypeOutput' change.
    Last edited by bratch9; September 16th, 2021 at 20:57.

  2. #112
    I'm not sure if this has been addressed, but when I use this extension, ongoing damage (for example, "DMGO: 1d4 fire") always becomes untyped damage. I've tested this with only this extension on and it still happens. Has there been a fix for this, or has anyone else had this problem?

  3. #113
    Quote Originally Posted by BlazingAzureCrow View Post
    I'm not sure if this has been addressed, but when I use this extension, ongoing damage (for example, "DMGO: 1d4 fire") always becomes untyped damage. I've tested this with only this extension on and it still happens. Has there been a fix for this, or has anyone else had this problem?
    I can replicate this, and will take a look. It should not be causing an issue like this.

    EDIT: I've got a fix for this issue working, but want to look at what I can sort with the CA extension above before doing a new release.
    Last edited by bratch9; October 5th, 2021 at 15:15.

  4. #114
    v2.2 is now uploaded, should fix both CA and DMGO issue.

  5. #115

  6. #116
    The issue is fixed! Glad to see that resolved. I noticed it happening months ago but didn't track down which extension it was until this week. Glad it could be fixed so quickly!

Thread Information

Users Browsing this Thread

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

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Fantasy Grounds Fridays Pre

Log in

Log in