API HeartBeat Problem.

I turned off API HeartBeat because I was going in and out of my library game several times today and got annoyed waiting for API HeartBeat to load every time. When I restarted the game I noticed that API HeartBeat was still active even though it was greyed out in the list of MODS on the game's API screen. Also, I saw that it had added new copies of its macros to the collections tab. Later, when I reactivated API HeartBeat and again entered the game, API HeartBeat was creating a new macro in the collections tab every few seconds (I noticed because I went to edit a rollable table that I am working on). I exited the game and deleted API HeartBeat from my list of MODs, logged out of Roll20, cleared cache, logged back in, reinstalled API HeartBeat from the 1-click menu and restarted the game: same issue. I again deleted API HeartBeat from the games MOD page, This stopped the spawning of multiple macros (which I deleted using MacroCleanup), but (4) instances of the API HeartBeat macro still keep appearing in the collections tab. BTW, when I open these macros to see what they are calling, they are blank. I deleted these blank macros, but they get recreated every time I go back into the game. Having the ScriptInfo MOD loaded, I ran !scriptInfo and !stateinfo. The output from !stateinfo still shows  API HeartBeat even though I deleted it from the MOD library, as well as  several MODS that I once had loaded but have long since deleted. The screen shots below show: My game's current MOD library, the first several entries under the game's collection tab, and the output from !scriptinfo and !stateinfo. In the output from !stateinfo, I've circled in yellow the MODS that I have deleted from this game's MOD library - some of them weeks or months ago. Edit: grammar and spelling

Hi Rick. Sorry to hear you're having problems. Let me break down a few things from above: The multiple macros thing is weird. There are two possibility I can think of: 1) the sandbox sometimes spawns multiple times for a game. That isn't usually too noticeable, and usually fixes itself after a few minutes, but could lead to multiple copies of the macro being created. If they are all continuing to be updated, that would indicate multiple sandboxes persisting. If that's the case, PM me and we'll get a dev involved. 2) the Unicode vs Emoji makes me thing it's more likely that there is a mismatch when it tries to find the current macro. I need to revisit the code and look at that. You could try manually installing the script rather than the 1-click version. The 1-click breaks emojis.  The state info: scripts write to a persistent object in the game called state. That info exists after the script file is removed and there is no way for a script to have a cleanup step to remove it. It's generally not a problem, but there are ways to clean it up. You can basically think of it as the config file sticking around after you uninstall the software. The state object can be roughly 2048k in size, of which you're using 7.9k, so shouldn't be a problem.  I wanted to ask what you meant about waiting for it to start up?  It shouldn't have that much to do at launch. It will take time to gather stats if unite looking at those, but shouldn't be causing performance issues. 

Hi Aaron, thanks for the reply. I'll try manually reinstaling the script. That's how I did it originally; I used the 1-click this last time assuming that the MOD had been updated to match since last time. If that fixes things I'll be happy. :) Your explantation of the "state"  object explains that oddity nicely. Thanks. As for waiting for APIHearBeat to start: Sometimes it takes up to a minute for the prompt to appear in chat saying that the MOD has started. Before that prompt appears any macros that call other MODs won't work. Other times the prompt appears within seconds. The long wait times seem to correspond with the same days where I experience a lot of sandbox crashes (like today) The Aaron said: The multiple macros thing is weird. There are two possibility I can think of: 1) the sandbox sometimes spawns multiple times for a game. That isn't usually too noticeable, and usually fixes itself after a few minutes, but could lead to multiple copies of the macro being created. If they are all continuing to be updated, that would indicate multiple sandboxes persisting. If that's the case, PM me and we'll get a dev involved. 2) the Unicode vs Emoji makes me thing it's more likely that there is a mismatch when it tries to find the current macro. I need to revisit the code and look at that. You could try manually installing the script rather than the 1-click version. The 1-click breaks emojis.  The state info: scripts write to a persistent object in the game called state. That info exists after the script file is removed and there is no way for a script to have a cleanup step to remove it. It's generally not a problem, but there are ways to clean it up. You can basically think of it as the config file sticking around after you uninstall the software. The state object can be roughly 2048k in size, of which you're using 7.9k, so shouldn't be a problem.  I wanted to ask what you meant about waiting for it to start up?  It shouldn't have that much to do at launch. It will take time to gather stats if unite looking at those, but shouldn't be causing performance issues. 

Ah, that makes sense.  The way the API works in general is event driven.  Scripts register for those events, and when they occur, they take various actions.  There are events for tokens being changed, events for chat messages, for tracks being played, etc.  At startup, there is an event called `ready`, which is issued once all the objects in the game have been loaded in the sandbox.  APIHeartBeat will send that message when it gets the `ready` event.  Since registered event handlers are called in order of registration, the further along the list of scripts they are (lower and more to the right in the API Sandbox tabs), the later they will get a chance to register for events and by extension the later they will be called.   I say that to say that if there is a delay to that message being issued, it's more likely that something earlier in the list of scripts is taking a long time, or possibly that the game is very, very large, and takes a long time to load into the sandbox. The function that APIHeartBeat launches on `ready` is like this: const checkInstall = () => { log(`-=> ${scriptName} v${version} <=- [${new Date(lastUpdate*1000)}]`); if( ! _.has(state,scriptName) || S().version !== schemaVersion) { log(' > Updating Schema to v'+schemaVersion+' <'); switch(S() && S().version) { // SCHEMA UPDATE CODE OMITTED FOR SIMPLICITY } } HBMacro = getOrCreateMacro(); assureHelpHandout(); newTimeSegment(); startStopBeat(); sendCheck('gm'); }; After the first run for a version, this should be almost immediate.  You can convince yourself of that by opening and watching the API Console in one window and watching the chat in game in another.  You should see (the log('...') call at the start): -=> APIHeartBeat v0.5.1 <=-  [ <some date> ] come across the API Console, then pretty quickly thereafter, in chat (the sendCheck('gm') call above): API is running. If there is a significant delay, then that's definitely something happening in APIHeartBeat. Several of the scripts you have should have console log messages, you can watch those to see when they go to the API Console and get a feeling for where the slowdown might be happening. Just some additional background on how most scripts are designed, scripts will register a handler for `ready`, then during that event, go ahead and register all their other handlers for things like chat messages and or graphic changes.  Generally, scripts will not be responsive until that `ready` event happens : on('ready',...) < ... some time later ... > READY: on('chat:message',...) on('change:graphic',...) I advocate strongly for this model for several reasons.  Scripts that register earlier than `ready` for chat messages could end up executing commands before everything is loaded, which will likely corrupt things.  Registering early for `create` events gets calls for each thing that is being loaded, not what's being created by the player.  Not distinguishing those cases can lead to a bunch of redundant work.  Additionally, delaying until after `ready` allows some special scripts to be created, like the Meta Scripts that Tim writes. Anyway, hope that provides insight and helps you track down the script causing issues.  Definitely let me know which one it is, or if you don't find it.

Before I try manually installing the script: why are the "!-↘️-００１" and "!-↗️-００１" macros (2 copies of each, both empty) still being created under collections even after API HeartBeat is deleted from the MOD list? Also, here is what's in the API console after the Sandbox is restarted: "🏠 ScriptInfo v0.0.2, 2023/3/31 🏠 -- offset 15494" Restarting sandbox by user request... detected currently running sandbox... restarting "Loading character sheet data..." "Starting webworker script..." "Loading 1094 translation strings to worker..." "Starting webworker script..." "Loading 1094 translation strings to worker..." "Starting webworker script..." "Loading 1094 translation strings to worker..." "%cRoll20 Kingmaker Module log| kScaffold Loaded" "Roll20 Environment: Web" "-=> TokenMod v0.8.76 <=- [Wed Dec 14 2022 17:45:16 GMT+0000 (Coordinated Universal Time)]" "-=> GroupInitiative v0.9.36 <=- [Thu Feb 03 2022 01:42:35 GMT+0000 (Coordinated Universal Time)]" "TokenAction v0.3.8 is ready! Designed for use with the D&D 5th Edition by Roll20 character sheet!" "-=> ApplyDamage v1.1 <=-" "checkLightLevel v0.5.0" "-=> Dynamic Lighting Tool v1.0.7 is loaded. Base command is !dltool" "-=> GroupCheck v1.12 <=-" "-=> Reporter v1.1.8 is loaded. Internal commands of !RPping, !RPpage-mod, !RPechochat, and !RPchangelayer are used in code." "sheet is D&D 5th Edition by Roll20" "PathEditor v0.4 initialized" " ________________________ ╱ ______ ╲ ╱ _____ ╲ ╱ ____ ╲ ╱______________________________╲ ┃ _____ _____ ┃ ┃ ┃_┃_┃ MOD ┃_┃_┃ ┃ ┃ ┃_┃_┃ _____ ┃_┃_┃ ┃ ┃ ┃ ┃ ┃ ┃ ┃ o┃ ┃ _____________┃_________┃___┃________┃_______________ " "🏠 ScriptInfo v0.0.2, 2023/3/31 🏠 -- offset 15494" At the line reading "detected currently running sandbox... restarting" the console paused for about 15 seconds, and for about 10 seconds at the line reading "Roll20 Environment: Web"" No mention of API HeartBeat, yet those four macros are still created. Now, this IS a large game; it's my library in which I keep currently 63 maps, 31 archived maps, and a slew of handouts and character sheets.

"detected currently running sandbox... restarting" is when the sandbox gets recreated and all the game objects get loaded into it. The "Loading character sheet data..." through "Roll20 Environment: Web" is when the DnD 5e by Roll20 character sheet is loading up.  Since the advent of sheet workers, character sheets are loaded and executed on the Mod Sandbox.  Weird that there are 3 copies of starting web worker and loading translation strings.  I get the same thing in my sandbox though so I guess it's operating as expected. Since TokenMod is in the first tab, when you see its output is the start of the 'ready' event.   Regarding the macros, are they getting recreated when you restart the API?  or are they just still there?  If the latter, you should delete them and make sure they do not come back.  If the former, then that's super weird...

I noticed the multiple instance of "   starting web worker"; if you're not worried about it, neither am I :) As for those macros: API Heartbeat isn't even currently loaded in this game, but those macros keep getting recreated. I delete them, exit the game, go away and do something else for a while, come back and start the game and there they are again. In my "live" game, which is much smaller with way fewer maps, things work ok, other than the sandbox crashing repeatedly when we play on Sunday nights. The Aaron said: "detected currently running sandbox... restarting" is when the sandbox gets recreated and all the game objects get loaded into it. The "Loading character sheet data..." through "Roll20 Environment: Web" is when the DnD 5e by Roll20 character sheet is loading up.  Since the advent of sheet workers, character sheets are loaded and executed on the Mod Sandbox.  Weird that there are 3 copies of starting web worker and loading translation strings.  I get the same thing in my sandbox though so I guess it's operating as expected. Since TokenMod is in the first tab, when you see its output is the start of the 'ready' event.   Regarding the macros, are they getting recreated when you restart the API?  or are they just still there?  If the latter, you should delete them and make sure they do not come back.  If the former, then that's super weird...

Rick A. said: I noticed the multiple instance of "   starting web worker"; if you're not worried about it, neither am I :) As for those macros: API Heartbeat isn't even currently loaded in this game, but those macros keep getting recreated. I delete them, exit the game, go away and do something else for a while, come back and start the game and there they are again. In my "live" game, which is much smaller with way fewer maps, things work ok, other than the sandbox crashing repeatedly when we play on Sunday nights. I wouldn’t expect API Heartbeat macros to be (re)created if the script isn’t loaded into the game. I suggest double checking your currently installed scripts by opening any that are manually loaded in your game and doing a quick Ctrl-F search for ‘heartbeat’.  What is the MacroCleanup script? Otherwise maybe your game has a bug or something and will need a Help Center request to clean up the sandbox. Odd!

I tried your suggestion about looking for "heartbeat" using CNTRL-F. No joy. MacroCleanup is a script for cleaning up macros under the collections tab, posted by timmaugh in this thread . Jarren said: I wouldn’t expect API Heartbeat macros to be (re)created if the script isn’t loaded into the game. I suggest double checking your currently installed scripts by opening any that are manually loaded in your game and doing a quick Ctrl-F search for ‘heartbeat’.  What is the MacroCleanup script? Otherwise maybe your game has a bug or something and will need a Help Center request to clean up the sandbox. Odd!

It's a good thought Jarren, but if there was a second copy of API HeartBeat, there'd be log messages and chat messages from it, and the macros would get updated with a different value constantly. I'd be curious to know if the macros have the same ID, or if they have a new ID.  If you use that MacroCleanup script, you can push up in the chat box to see the prior command it ran.  It should look like: ! !macrodelete -k13241231234 That second part is the ID.  If it has the same ID after you refresh the game, then it isn't getting deleted, problem with the game requiring dev assistance.  If it has a different ID, then it's getting recreated, problem with scripts that we have to fix.  I suspect it's the former.  Another test you could make is stopping the API  (put something invalid in a tab and save it to crash the sandbox), then delete the macros and refresh.

Typing !macrodelete does nothing. I don't think we're referring to the same script. Pushing up the chat after running MacroCleanup doesn't show anything besides what I typed. Well, now that uncovers another weird thing. In the chat, I entered !MacroCleanup --starts=!  .... the result was: Entering !MacroCleanup --starts=  ... the result was: The top of the list under collections is: Note that MacroCleanup did not find any macros that begin with "!", "1", or "A". I again tried to delete the four API Heartbeat created macros manually, and all four again re-appeared when I restarted the game.

Hmm.. Any interest in PMing me an invite to your game and GMing me so I can investigate?

I'm going to be away from my desktop for the rest of today, but I've DMed you a game invite and will upgrade  you to gm when I get the chance.

Sounds good!  I've joined, just ping me when you've GM'd me and I'll take a look.