search

PunishXIV / AutoRetainer

Collect and assign ventures to your retainers from the comfort of your bed.
https://puni.sh/plugin/AutoRetainer
BSD 3-Clause "New" or "Revised" License
56 stars 36 forks source link

do Post-Processing only in multi mode #90

Closed ShamelessEnd closed 3 weeks ago

ShamelessEnd commented 3 weeks ago

I'm getting some unexpected behaviour due to AR always running post-processing when relogging - and honestly it just feels really weird/unwanted to have it trigger when manually relogging (through command, or UI buttons). Personally I use the relogging often just to jump between characters when playing normally, any only want the post-processing to fire when multi-mode is running.

It also causes kinda broken behaviour when trying to relog via SND script if any post-processing is registered in SND:

  1. SND script is running, calls ays relog
  2. ays triggers post processing
  3. SND runs the script registered to ays post processing
  4. post processing SND script completes
  5. control returns to original SND script
  6. original SND script continues running, but has failed to relog (and cannot even attempt to relog again because now it's within ays post-processing)
  7. original SND script completes, probably has not completed its intended tasks (because relogging failed)
  8. ays actually does the relog initially requested, even though the script that requested it is no longer running

now this specific issue isn't caused by ays per-say - this happens because SND only detects completion of post-processing once it is idle, instead of specifically checking that the registered post-processing macro is complete. But I do think it highlights some of the jank that this behaviour can cause - and it would be great if there was at least an option to turn it off.

The way i see it there's a few options for fixes

  1. only run post processing if MultiMode.Enabled
    • probably my preference, I think it makes the most sense - post processing definitely feels like a MultiMode-specific feature rather than something that should be running on every relog.
    • if you have C.MultiDisableOnRelog enabled then manual relog will first disable multi mode, then skip post-processing anyways due to multi mode being off
  2. only run post processing if reason == RelogReason.MultiMode
    • similar to the above but imo worse - I think if you manually relog but multi mode is enabled (and you dont have C.MultiDisableOnRelog on) then it's not unreasonable to run post-processing, which this wouldn't allow for.
  3. only run post processing if reason == RelogReason.MultiMode || !C.MultiDisableOnRelog
    • i.e. if C.MultiDisableOnRelog is set, and you do a manual relog, skip post processing
    • I don't think it's unreasonable to tie to C.MultiDisableOnRelog, since it's pretty similar conceptually - essentially means when manually relogging stop doing anything and relinquish control to user.
    • the difference vs option 1 is that if C.MultiDisableOnRelog is disabled, then a relog when multi-mode is disabled will still trigger post-processing.
  4. add an entirely new option to the settings for suppressing post-processing if multi mode disabled
    • feels like overkill for such a small piece of logic