OnyxRing Change Player Hack Incompatible With API

From another thread, Scott C wrote, "...I would recommend not using the Roll20 Async stuff from OnyxRing. It is very cool, but unfortunately it makes your sheet incompatible with any API scripts (as in the API sandbox will error out and shut down)."

I didn't see any cautionary tales when researching Custom Roll Parsing (CRP), for which OnyxRing originally posted this nifty hack.  While losing brain cells trying to grok CRP, something finally clicked for me reading over OnyxRing's post for the 20th time.  It occurred to me that I could automate a great deal of combat and perhaps other things in my character sheet sans API.  As many of the players/groups I've met so far are not paying for a Pro account, I felt this could be a fantastic way to eliminate more complexity and drive further game immersion.  

As mentioned above, in another thread Scott mentioned not to use OnyxRing's change player hack, and now weeks of research, design, development, blood, sweat, and tears...and brain cells, are at risk!  Why Scott....WHY?! *camera slowly pulls away to the flicker of lightning, rain droplets, and thunder*

I wanted to make this a public discussion for anyone looking to do the same as I, and supply them with this information so they may make the best informed decision on how to proceed with their character sheet.

Also, your thoughts on whether I could hide this functionality behind a feature flag and let GMs decide whether to use it or remain API compatible?

I do wish that the Roll20Async framework worked, and it does seem to when you only look at character sheets.

However, because the API sandbox runs server side in NodeJS, there's no browser for it to interact with. This means that the sheetworkers that spin up in the API sandbox don't have access to the window or self objects, and that the functions bound to self that the Roll20Async framework relies on don't exist. Now, we could keep the sandbox from shutting down by just defining some standins for those as backups, but there's no way that I'm aware of to replicate their function. So, best case scenario is you'd wind up writing your sheetworkers twice; once using the Roll20Async framework and once using standard Roll20 sheetworkers with callbacks. That's a lot of extra code and work for something that is most likely going to be extremely fragile no matter how well you guard against it.

Thanks for the explanation, Scott.  It seems I may have misunderstood your original statement in the other thread about ORs change player hack being API incompatible, but it appears all of Roll20Async framework, and, therefore, Custom Roll Parsing that is not compatible with the API?

No, custom roll parsing is perfectly fine. The startRoll function is the only (hopefully the first of many) sheetworker function that can be used with async/await. It's the Roll20Async framework from Onyx Ring that is not API compatible. The setActiveCharacterID function from the framework requires a browser to be used in order to work.

And, I should expand on the custom roll parsing a bit; it is possible to make a custom roll parsing function that would not be API compatible. But, this compatibility issue wouldn't be one that crashes the API sandbox, it's just that if you make a CRP function that also queries the user for some input, the API has no way to answer that query and so if an API script triggered that roll, it'd just hang for eternity waiting for an answer to the query.