Could someone create this teeeeeensy API script for me? :-)

Thanks for opening my post and giving it a read :-) Here's the description for what the API-script would need to do: Activation trigger: !green-bar Output: If the API-sandbox is up, then display a green bar in the chat. . . . And, if you're interested, then here's the reason why I find myself in need of this script: The thing is, my group and I, we've become quite paranoid about some of our API-equipped-macros, after a "silent API crash" happened to us the other day, and completely ruined our session. So, my plan is to have all of our important macros do the following: Step 1) "!green-bar" Step 2) Do what the macro is actually supposed to do. Step 3) "!green-bar" The reason for this is: because then I'll easily be able to spot the lack of a bright, green bar in the chat, and then I can know from it's position either before or after the main macro output, whether I need to manually do what the macro was supposed to do for me (the stuff in Step 2). Or, in other words, this would help me and my group to immediately correct errors, as soon as they happen, rather than just letting them accumulate, like happened to me and my group the other day (plus, that those errors were so stealthy that we were completely unable to EVER get our true game-state back... needless to say, we were extremely frustrated).

I believe there already is something for this, though I haven't used it. <a href="https://app.roll20.net/forum/post/1567329/script-apiheartbeat-a-visual-cue-that-the-api-is-running/?pagenum=1" rel="nofollow">https://app.roll20.net/forum/post/1567329/script-apiheartbeat-a-visual-cue-that-the-api-is-running/?pagenum=1</a>

While I greatly respect The Aaron, and all his works, I'm afraid that I just cannot use APIHeartBeat for this, since it does not give me the precise timing of when exactly the API-sandbox went down. But I still (of course) would like to thank you for the kindness that you have shown by offering to help me :-)

That may not be completely satisfactory.&nbsp; Scripts that have asynchronous operations will un-nest themselves from within the start and end headers you create with it.&nbsp; Give it a try and see: !green-bar You can also have it whisper by prefacing with a w: !wgreen-bar And anything you put after either command will show up in the bar: !green-bar Beginning initiative roll... Here's the code: on('ready',()=&gt;{ const buildArgs = (str) =&gt; { let firstWhitespace = str.search(/\s/); if(-1 === firstWhitespace){ return [str]; } return [str.slice(0,firstWhitespace),str.slice(firstWhitespace+1)]; }; on('chat:message',msg=&gt;{ if('api'===msg.type &amp;&amp; /^![w]?green-bar(\b\s|$)/i.test(msg.content) &amp;&amp; playerIsGM(msg.playerid)){ const who = (getObj('player',msg.playerid)||{get:()=&gt;'API'}).get('_displayname'); const whisper = /^!w/i.test(msg.content); const text = (buildArgs(msg.content)[1]||'&amp;nbsp;'); sendChat('',`${ whisper ? `/w "${who}"` :''}&lt;div style="background-color:#009900; color:white; font-weight:bold; border: 1px solid #006600;border-radius:.2em;text-align:center;padding:.1em 1em;"&gt;${text}&lt;/div&gt;`); } }); });

Here's an example of how an asynchronous script will break out of the header/footer:

Not sure about silent API crashes, but I have one of my scripts that displays a message saying I should really update my API created macros to the most recent version. I never bothered because I don't really use it anymore, but I found the message useful since it shows up on sandbox startup, so I left it in there. From what I can tell with a bit of testing, the *first* time the sandbox crashes it spins up a new one. If there are no more crashes, everything is fine. If it crashes again before it has had a manual restart, though, a replacement sandbox doesn't get spun up and further API calls don't do anything. Here is a quick script (I pulled the code from PCMHelper that bugs me about updating and changed the text :)) that shows a message when the sandbox starts/restarts. You always get one when the game starts up, but if you see one mid-game you know something happened and the sandbox crashed and restarted. I have this in my game now as "APIAlerter.js". It sends the alert to everyone, but you could modify the sendChat line to make it more directed. on("ready", function() { var d = new Date(); var html = "&lt;table border=2 width=100%&gt;&lt;tr&gt;&lt;td bgcolor=goldenrod colspan=2 align=center&gt;&lt;font color=black&gt;&lt;strong&gt;API Sandbox Alert&lt;/strong&gt;&lt;/font&gt;&lt;/td&gt;&lt;/tr&gt;"; html += `&lt;tr&gt;&lt;td colspan=2&gt;The API Sandbox has started or restarted (${d.toDateString()} ${d.toTimeString()}). If this is unexpected, it is likely that your sandbox crashed. `; html += "If that is the case, it is recommended that you manually restart the sandbox, as API scripts running in your game are/will become "; html += "unstable.&lt;br /&gt;&lt;br /&gt;&lt;strong&gt;NOTE:&lt;/strong&gt; This is expected behavior if you just launched your game or made updates to your running API "; html += "scripts."; html += "&lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;"; sendChat("APIAlerter:", html); })

I just want to chime in and restate how much I hate their change to the API crash sequence.&nbsp; A short while ago, months or so ago, they changed the sandbox to restart with offending scripts silently disabled and that is annoying AF.&nbsp; I really wish they would keep the state crashed waiting for us to restart it OR make it a setting we can toggle on and off even.&nbsp; Silent crashes and disabling of scripts is very much happening in sessions, but mostly just on the really obscure ones, it never kills things like token mod or chatsetattr, usually the manual ones.&nbsp;&nbsp;

Huge thanks to Aaron and Kurt!!! You guys are incredible !!! :-D Now I'll be able to use Aaron's script as an "API confirmer", and Kurt's script as an "API alerter"! And, by letting the messages from both scripts be visible to everyone (at least for the next few weeks), I'll be able to soothe my group's mistrust of the roll20 API system! Noice! :-D Thank you guys so much! You're the real heroes! :-D

I didn't know that. Broken API scripts are silently disabled? DM Eddie said: I just want to chime in and restate how much I hate their change to the API crash sequence.&nbsp; A short while ago, months or so ago, they changed the sandbox to restart with offending scripts silently disabled and that is annoying AF.&nbsp; I really wish they would keep the state crashed waiting for us to restart it OR make it a setting we can toggle on and off even.&nbsp; Silent crashes and disabling of scripts is very much happening in sessions, but mostly just on the really obscure ones, it never kills things like token mod or chatsetattr, usually the manual ones.&nbsp;&nbsp;

This...is...AWESOME!&nbsp; We are very fortunate to have Kurt, The Aaron, tim, David and others available to help.&nbsp; Thanks!&nbsp; And thanks to Ronnie for pursuing the problem.&nbsp; I just assumed that this was something I would have to live with and was quite frustrated with having to check to see if a script blew during games.

Gold said: I didn't know that. Broken API scripts are silently disabled? DM Eddie said: I just want to chime in and restate how much I hate their change to the API crash sequence.&nbsp; A short while ago, months or so ago, they changed the sandbox to restart with offending scripts silently disabled and that is annoying AF.&nbsp; I really wish they would keep the state crashed waiting for us to restart it OR make it a setting we can toggle on and off even.&nbsp; Silent crashes and disabling of scripts is very much happening in sessions, but mostly just on the really obscure ones, it never kills things like token mod or chatsetattr, usually the manual ones.&nbsp;&nbsp; I have seen silent failures of the sandbox (no pink error box, but nothing is working), but have not seen individual script disabling. Since Roll20 concatenates all scripts into one file when spinning up the sandbox, I'm not sure this is even possible to do on the fly.

Yeah, the scripts aren't disabled, but it is possible to cause the sandbox to repeatedly crash so that some API commands are not received because they are sent while the sandbox is rebooting. The reboot also causes issues where you can wind up with a script running 2, 3, 4, or even more times all at the same time which can cause duplicate responses to chat commands.

keithcurtis said: Gold said: I didn't know that. Broken API scripts are silently disabled? DM Eddie said: I just want to chime in and restate how much I hate their change to the API crash sequence.&nbsp; A short while ago, months or so ago, they changed the sandbox to restart with offending scripts silently disabled and that is annoying AF.&nbsp; I really wish they would keep the state crashed waiting for us to restart it OR make it a setting we can toggle on and off even.&nbsp; Silent crashes and disabling of scripts is very much happening in sessions, but mostly just on the really obscure ones, it never kills things like token mod or chatsetattr, usually the manual ones.&nbsp;&nbsp; I have seen silent failures of the sandbox (no pink error box, but nothing is working), but have not seen individual script disabling. Since Roll20 concatenates all scripts into one file when spinning up the sandbox, I'm not sure this is even possible to do on the fly. You can actually detect these restarts very easily if you run a session with a script like Paladin aura, Wildshape API, or Teleport API cause these scripts ping when the sandbox finishes restarting with a message whispered to the DM in chat.&nbsp; Because of this, you can even kinda sorta deduce what script caused the restart.&nbsp; I've had it happen with just abut everything.&nbsp; Dealer API for instance, if you deal out a ton of cards with a command will hang then restart the api.&nbsp; Group init I recall for sure just out of the blue restarting the sandbox and I couldn't get the group init buttons to fire till I went into the sandbox and hit a manual restart again.&nbsp; But I really do not think its a script issue, I think its a roll20 issue.&nbsp; I suppose in a way the OP could install one of the scripts that ping on restarts to show them if the API has crashed/restarted, and the heartbeat api will show them when the api has hard crashed and not restarted.&nbsp;&nbsp;

Thank you for the answers. Whew. Glad i don't need to check for Disabled scripts in-addition to checking for crashed sandbox / Restart API / error messages in the console