Compatibility Conundrum: GroupCheck, ApplyDamage, StatusInfo, & Token Mod

Alright you wonderful wizards of code, I am fumbling for the solution to this problem. I was also unsure of whether this was more appropriate for the Macro forum or the API forum, since it involves both, so if it needs to be moved, I will gladly do so. Currently, I use the following macro to run a fully-queried GroupCheck save on any number of selected tokens, with the ApplyDamage.js added in the API of the campaign to make it handle correctly. It is a modified version of the macro developed in  this discussion thread . !group-check {{ --?{Whisper?|Whisper,--whisper|Public,--public} --?{Ability Save|Strength,Strength Save|Dexterity,Dexterity Save|Constitution,Constitution Save|Intelligence,Intelligence Save|Wisdom,Wisdom Save|Charisma,Charisma Save} --ro ?{Roll Type|Normal,roll1|Advantage,adv|Disadvantage,dis} --process --subheader vs DC ?{DC} --button ApplyDamage !apply-damage ~dmg [[?{Damage|0}]] ~type ?{Damage on Save|Half,half|None,none} ~DC ?{DC} ~saves RESULTS(,) ~ids IDS(,) ~status ?{Status| None, | Prone,back-pain| Restrained,fishing-net| Grappled,grab| ―, | Incapacitated,interdiction| Stunned,pummeled| Unconscious,sleepy| ―, | Charmed,chained-heart| Frightened,screaming| ―, | Poisoned,half-heart| Blinded,bleeding-eye| Deafened,lightning-helix| Paralyzed,padlock| Petrified,broken-skull| ―, | Slowed,snail| Enlarged/Reduced,half-haze| ―, } }} My issues lies in the fact that StatusInfo, designed to send a condition description to chat whenever a designated marker is added to a token, works wonderfully when applying said markers via macros based in TokenMod, but does not display the condition descriptions when the markers are added to a token via the Condition query that makes up the latter half of the code above.  I would like to know what steps could be taken to have StatusInfo recognize the addition of token markers by GroupCheck/ApplyDamage, so the macro above will pair with StatusInfo like I'd hoped it would.  Thank you in advance for any assistance provided! 

I saw someone ask the same question using a slightly different version of the same macro in another thread from a few year ago, but saw no answer to that question. 

Some background: The API is entirely event driven, meaning it merely reacts to things having occurred.  Almost always, the things in question are prompted by a human, such as running a command, or moving a token, or sending a chat message in general.  In fact, changes by the API (mostly) don't even cause events to occur, even if a player having done the action would have caused the event.  When a player adds a status marker to a token, it issues a change:graphic  event for that token, with the before and after state of the token.  When the API changes a graphic, it does not cause an event. That means that for two scripts in the API to work in conjunction, that behavior must be actively added.  In the case of TokenMod and StatusInfo, TokenMod implements the Observer Pattern, and provides an interface where other scripts can request to be informed about changes it makes.  The practical upshot is that when StatusInfo starts up, it sees that TokenMod is there and asks TokenMod to tell it when it does something. To get similar behavior between GroupCheck (or possibly ApplyDamage) and StatusInfo, GroupCheck would need to provide an interface for StatusInfo to know about the change. A possible work around: I don't know much about GroupCheck, or what it's doing in the above macro, but I assume it spits out a button which, when clicked, runs the !apply-damage command with all the attached bits. I speculate that you could add a second call into the button which invokes TokenMod to set the same status markers on the same tokens, thereby triggering StatusInfo by proxy.  I don't know what the syntax would be, so that's just a guess.

Yeah, that's what I was slowly discovering as I was searching through forums and descriptions. Glad my rudimentary sleuthing was leading me in the right direction, haha! I'll keep digging and see if I can't come up with a solution, but will gladly accept any input from those who know more about the specifics. 

It's possible the ApplyDamage script already has some means of being observed, which might make it easy to update StatusInfo to watch it.  Do you have a link to ApplyDamage?

Okay, it's looking like what you suggested Aaron is going to be the best course of action, adding an additional command under the button in order to get Token Mod to run a command that will toggle any marker off and then reapply that same marker. I just also have no idea what that syntax is and it doesn't seem to be something I can find in the documentation of Token Mod either. Is there a way to set a command/macro to run and then do the reverse of what it did?

I do Aaron, you can find it right here: <a href="https://gist.github.com/joesinghaus/9fd52108d07e5ef83ed879a7c6fdc68f" rel="nofollow">https://gist.github.com/joesinghaus/9fd52108d07e5ef83ed879a7c6fdc68f</a>

Ah, nice!&nbsp; It has observation built in already.&nbsp; You can just add this to StatusInfo on line 622: if('undefined' !== typeof ApplyDamage &amp;&amp; ApplyDamage.registerObserver){ ApplyDamage.registerObserver("change",(obj,prev) =&gt; { handleStatusmarkerChange(obj,prev); }); } Or grab this version:&nbsp; <a href="https://gist.github.com/shdwjk/bff22c0d9c7d2f693582f5eed14734ec" rel="nofollow">https://gist.github.com/shdwjk/bff22c0d9c7d2f693582f5eed14734ec</a> Let me know if that works out, I'll see about sending an update to the 1-click version.

Will do! I'm currently out and about, but I will test it out when I get home!

I prepped the change list, just let me know when I can pull the trigger! =D

Okay, after deleting the one-click StatusInfo from my campaign, and manually installing the version you prepped with observation, it does not seem to function like we thought it would. I run the macro, which still applies the token marker just fine after the button in the macro is pressed, but StatusInfo still does not want to register it for some reason. The Sandbox also displays this message now after a restart:

Would it have anything to do with the other observing API's being written with a .ObserveTokenChange, while the Apply Damage has .registerObserver? Update: After testing if replacing .registerObserver with .ObserveTokenChange would work, I have found that it does not. Reverting to .registerObserver for the time being.&nbsp;

...StatusInfo also kept all of my added custom conditions even after I took it out of the campaign, including icon alternation made on the default conditions, is that normal?

Ah!&nbsp; I messed up the registration, grab it again from the link above, it should work now...

You are a genius! That worked like a charm! I really appreciate the time you've spent helping me! I'll keep an eye out for the update on the one-click to be pushed through.&nbsp;

Cool beans, I'll submit it now, it should be in the repo next Tuesday!

Pull Request if you want to track when it's in the 1-click:&nbsp;<a href="https://github.com/Roll20/roll20-api-scripts/pull/1178" rel="nofollow">https://github.com/Roll20/roll20-api-scripts/pull/1178</a>