Minty23185Fresh
April 12th, 2022, 05:22
I believe users of my Druid Wild Shapes extension and I am experiencing an asynchronous timing issue. It's manifesting itself as a different armor Class (AC) value being displayed in the host instance of FG than in the client instances. E.g. when the user wild shapes his Druid character, the AC in the host (DM) instance of FG is say 12 but in the players' instances it may be displayed as 11. The behavior is incredibly erratic and inconsistent.
For instance, while troubleshooting, once when I observed the issue, I left the Druid wild shaped (as a beast) closed down the client instance, then the DM instance, thus forcing a save of the DB to disk. When I started everything back up the ACs in the host and client were the same, the problem rectified itself. I have been able to repeat this a number of times. The only thing that changed in this scenario is the closing down and reopening of FG.
I have added Debug.console and Debug.chat to the code in my extension and into the ruleset to dump the values of character sheet fields. The values of the fields and of their corresponding DB entries always add up to the correct expected wild shape (beast) AC yet the value displayed by FG is wrong (in the client instance).
Another thing I have tried, when the display is wrong is "tickling" the DEX ability score. When the displayed values of the AC between host and client don't agree, I edit the DEX field on the client instance of the character sheet. I add one to the field then subtract one from the field (net zero change). This process fixes the incorrectly displayed value.
The Druid Wild Shapes extension effects the stat changes as set forth by the 5E rules by manipulating the DB values, changing the Druid stats to the beast stats in the underlying DB (db.xml). I believe that the display fields shown on the screen that correspond to the DB fields are updated in an asynchronous manner, and sometimes, with the right Druid stats and beast stats, and particularly with a multi-component field like total AC (calculated from 6 underlying fields) data gets stomped on during refresh and numbers get messed up, resulting in an invalid display. This is because each time one of the six numbers is changed a refresh is requested. But who knows when it is serviced. If they were to be serviced in the wrong order, the display might end up being incorrect. (I'm guessing, I'm not sure. I can't prove it.)
So does anyone out there have suggestions that might help me mitigate this issue? In my next release I have added code that calls the AC refresh routine at the end of the onDrop() function; the function that initiates the wild shape (in essence at the very end of code execution as FG goes back to "steady state").
I'm considering manipulating each of the display fields instead of the underlying DB fields to effect the stat changes. Comments? Might this help? This would involve a complete rewrite of DWSI and I'm not quite sure I want to undertake that venture without some real authoritative affirmation that this would be the correct avenue to pursue.
Thanks in advance.
For instance, while troubleshooting, once when I observed the issue, I left the Druid wild shaped (as a beast) closed down the client instance, then the DM instance, thus forcing a save of the DB to disk. When I started everything back up the ACs in the host and client were the same, the problem rectified itself. I have been able to repeat this a number of times. The only thing that changed in this scenario is the closing down and reopening of FG.
I have added Debug.console and Debug.chat to the code in my extension and into the ruleset to dump the values of character sheet fields. The values of the fields and of their corresponding DB entries always add up to the correct expected wild shape (beast) AC yet the value displayed by FG is wrong (in the client instance).
Another thing I have tried, when the display is wrong is "tickling" the DEX ability score. When the displayed values of the AC between host and client don't agree, I edit the DEX field on the client instance of the character sheet. I add one to the field then subtract one from the field (net zero change). This process fixes the incorrectly displayed value.
The Druid Wild Shapes extension effects the stat changes as set forth by the 5E rules by manipulating the DB values, changing the Druid stats to the beast stats in the underlying DB (db.xml). I believe that the display fields shown on the screen that correspond to the DB fields are updated in an asynchronous manner, and sometimes, with the right Druid stats and beast stats, and particularly with a multi-component field like total AC (calculated from 6 underlying fields) data gets stomped on during refresh and numbers get messed up, resulting in an invalid display. This is because each time one of the six numbers is changed a refresh is requested. But who knows when it is serviced. If they were to be serviced in the wrong order, the display might end up being incorrect. (I'm guessing, I'm not sure. I can't prove it.)
So does anyone out there have suggestions that might help me mitigate this issue? In my next release I have added code that calls the AC refresh routine at the end of the onDrop() function; the function that initiates the wild shape (in essence at the very end of code execution as FG goes back to "steady state").
I'm considering manipulating each of the display fields instead of the underlying DB fields to effect the stat changes. Comments? Might this help? This would involve a complete rewrite of DWSI and I'm not quite sure I want to undertake that venture without some real authoritative affirmation that this would be the correct avenue to pursue.
Thanks in advance.