STAR TREK 2d20
  1. #1
    Minty23185Fresh's Avatar
    Join Date
    Dec 2015
    Location
    Goldstone, CA, USA
    Posts
    1,211
    Blog Entries
    29

    Can Asynchronous Timing Issues be Mitigated?

    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.
    Current Projects:
    Always...
    Community Contributions:
    Extensions: Bardic Inspiration, Druid Wild Shapes, Local Dice Tower, Library Field Filters
    Tutorial Blog Series: "A Neophyte Tackles (coding) the FG Extension".

  2. #2
    The problem usually occurs because both the GM and player are attempting to set the value at the same time; and one is blocking the other from completing. I suggest moving any operations like that to purely occur on the GM side using the OOB messaging, as the GM will always be the master and always propagate shared data to players.

    Regards,
    JPG

  3. #3
    Minty23185Fresh's Avatar
    Join Date
    Dec 2015
    Location
    Goldstone, CA, USA
    Posts
    1,211
    Blog Entries
    29
    Thank you very much Moon Wizard for your reply.

    Earlier (2019) in my extension's development I ran into timing issues too, with revert from wild shaping and managing damage side effects (like forcing a revert). At that time, I tried just what you mentioned, moving all processing to the host instance using OOB. Unfortunately, the solution created even more problems, which all stemmed from the fact that it is not guaranteed that the host (DM) will have the player's character sheet open. If the DM does not have the character sheet open, the calculations are not done for many fields that are manipulated during wild shape. I spent a great deal of time trying to make it work and eventually abandoned the idea. I guess I could force the character sheet to open on the DM side, but that seems a bit draconian and might be unacceptable by some DMs - having a player's character sheet just pop-up.

    [EDIT] oops forgot. Interestingly. If I wild shape using the DM instance the player displays correctly but the DM does not. Additionally the displayed incorrect value in the DM instance actually affects the “to hit” calculation in combat. Super yuck!

    A follow up question: is the servicing of window control refresh of what is displayed on the screen really random (asynchronous) or can it be controlled at system level? What I am getting at is, if it can be controlled, maybe the system should force recalcs/refresh of source data before refreshing dependent fields. For example, (in 5E) the displayed armor class value is dependent on the armor, shield, dex modifier, 2nd stat modifier, misc, temporary and DEX ability score modifier field values. If a refresh of armor class is requested, maybe system should request refreshes of each of these source data fields first?

    Also, if I tried this at the ruleset level, will it still be asynchronous, or might I be successful in forcing accurate field values?
    Last edited by Minty23185Fresh; April 12th, 2022 at 16:06.
    Current Projects:
    Always...
    Community Contributions:
    Extensions: Bardic Inspiration, Druid Wild Shapes, Local Dice Tower, Library Field Filters
    Tutorial Blog Series: "A Neophyte Tackles (coding) the FG Extension".

  4. #4
    Usually, timing issues like this are related to calculations for both default values and scripts performing calculations independently, and the values crossing over the network.

    That's why I recommended moving everything the GM side using OOB; and preventing all calculations for this on the player side.

    Regards,
    JPG

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
  •  
Starfinder Playlist

Log in

Log in