API no longer triggering sheet workers

Thanks, Scott, that's a very comprehensive answer. 

Hopefully with the problem clearly delineated like that, API functionality can be returned to the sheets that lack it.

I'm getting the error:  Error downloading scripts (probably no scripts exist for campaign.)  in my game ID 5408074. I've removed and readded and removed all API's (all from Roll20 Library) and still cannot get any scripts to run.

Hi Jack, That issue is unrelated to the bugs in this thread. Here are a few things to try: You need at least one script installed for the API sandbox to boot up. If you don't have any scripts installed the API doesn't run to prevent needless resource usage. Once you have a script(s) installed, someone needs to be logged into the game for the sandbox to boot up (aka actually in the tabletop, looking at a map). Once again, this is to prevent needless resource usage. If both of the above are already true and you are still getting the error you copied, I'd recommend posting a bug report as a new thread in the bug reports subforum

API Script : Pathfinder HeroLab Character Import (HL-Import) Sheet : Pathfinder Community by Roll20 Command that fails : !hl-import Expected behavior : Character to be imported from JSON conversion Actual behavior : API Output Console shows following error while nothing occurs in game:   SyntaxError: Unexpected token < in JSON at position 0 SyntaxError: Unexpected token < in JSON at position 0     at JSON.parse (<anonymous>)     at apiscript.js:825:33     at Function._.each._.forEach (/home/node/d20-api-server/node_modules/underscore/underscore.js:186:9)     at HandleInput (apiscript.js:822:6)     at eval (eval at <anonymous> (/home/node/d20-api-server/api.js:154:1), <anonymous>:65:16)     at Object.publish (eval at <anonymous> (/home/node/d20-api-server/api.js:154:1), <anonymous>:70:8)     at /home/node/d20-api-server/api.js:1637:12     at /home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:93:560     at hc (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:39:147)     at Kd (/home/node/d20-api-server/node_modules/firebase/lib/firebase-node.js:93:546) More info : I’ve used this several times in the past and this is the first I’ve had it consistently fail.

This thread is for Sheetworkers failing to be triggered by API changes. I don't think the above is an instance of this bug.

Kimbo, at a guess you still have xml in your file that you got from hero lab. However, I can confirm, that error is not related to the error this thread is for. I'd recommend checking you file to make sure it is in json. If you still get the error, post a new thread in the API forum for the creator of the script to look at.

keithcurtis said: Hopefully with the problem clearly delineated like that, API functionality can be returned to the sheets that lack it. The only thing I have to add to Scott's "Issue 2" is: Scott and The Aaron already explained exactly how eventinfo is missing fields in API notifications.   As far as I can tell, this was always the case.   Then 9+ months ago, the 5e OGL sheet started relying on eventinfo.newValue as an optimization.  This reduces the number of data fetches they have to do on update.  So at that point, scripts that push values to 5e OGL via API stopped triggering sheet workers, because they never had the correct eventinfo support.   So it's not like anything in the API suddenly broke, but rather that the sheet started relying on a portion of the Roll20 core that was never correctly implemented for the API case.   So you probably won't find any Roll20 bugs introduced that you can point a finger at. It's more a matter of "need to implement this thing."  Hope that helps schedule the work :)

Thanks for the input, Ammo. This is a long standing issue that I had really hoped would be resolved by now. :(

Idk if this is still being looked into, but I've found another instance, if it's helpful at all in resolving this Sheetworker API failure example API Script : Ammo Sheet : Pathfinder by Roll20 Command : !wammo -LVbkgV7MRZUAzA3OJba repeating_spell-1_-LXX7YLR2wTmKEApUA6k_spellprepared -1 prepared 1st-level spell Expected Behavior : The value for the number of slots marked as prepared for the spell decreases by 1, and the overall number of prepared level 1 spells decrease by 1 as well. Actual Behavior : The value for the number of slots marked as prepared for the spell decreases by 1, and the overall number of prepared level 1 spells does not decrease. Before command: After command: More info : I'm able to accomplish this using the ChatSetAttr script and either of the commands !modbattr --sel --repeating_spell-1_$0_spellprepared|-1 or !modbattr --sel --repeating_spell-1_-LXX7YLR2wTmKEApUA6k_spellprepared|-1 . Maybe looking at the way each script interacts with sheetworkers and this part of the PF sheet can help? Though ChatSetAttr has trouble triggering sheetworkers in other instances.

Hi Steph, that isn't related to the topic of this thread. Ammo is just old enough that it doesn't utilize the functions that allow API scripts to trigger sheet workers.

Oh, whoops. Thanks for clarifying. At least I found an instance where ChatSetAttr was able to trigger sheet workers. Maybe that can prove useful in comparing to the cases where it doesn't.

Yep, it's because the sheets after the 5e (or at least most of them) by Roll20 were made with this limitation in mind and so are coded around it.

I just updated Ammo to use SetWithWorker.&nbsp; It should be in 1-click on January 7th, but you can get it now at:&nbsp;&nbsp; <a href="https://github.com/shdwjk/Roll20API/blob/master/Ammo/Ammo.js" rel="nofollow">https://github.com/shdwjk/Roll20API/blob/master/Ammo/Ammo.js</a>

Even better! Thanks, The Aaron :)

The Aaron said: I just updated Ammo to use SetWithWorker.&nbsp; It should be in 1-click on January 7th, but you can get it now at:&nbsp;&nbsp; <a href="https://github.com/shdwjk/Roll20API/blob/master/Ammo/Ammo.js" rel="nofollow">https://github.com/shdwjk/Roll20API/blob/master/Ammo/Ammo.js</a> Thanks for the update. &nbsp; I don't feel very 1-click though.... at least you didn't question my age like Scott did above. &nbsp;Seriously though, these notifications look seriously strange in my email inbox :)