Forcing the same operations as when a character sheet is opened using the API

Legacy character sheets seem to behave very differently before the first time they are actually opened during a session. Would there be a way for the API to emit (maybe indirectly) an event sheet:opened   for a given character?

Hi Ulti! I am unqualified to answer your question directly, but it sounds like it might be an XY Problem . What issue do you hope to solve by this? I might not be able to answer the specific issue, but there may be other ways of achieving your goal, or I might be able to direct this to someone who can.

The issue I'm trying to fix: before the first time the character sheet is opened, when using macros buttons or changing token bars linked to sheet attributes, the sheet worker seems to be doing unexpected changes in the sheet, with crashes in the console log. It seems to be working perfectly fine once the sheet is opened. I wouldn't like to have to open all sheets before playing each time I start (or restart) a game session. So I thought maybe I could automatize the opening stage. I opened  an other subject  to see if the orginal bug can be fixed, but I'm not very optimistic on that. And since it is legacy sheet, Roll20 support just doesn't seem to fix any bug. So I'm looking for workarounds.

Thanks! I'll see if I can point any knowledgeable eyes this way.

Thanks keithcurtis!

When you create a new sheet ( "+ Character" from the sidebar), isn't it opened automatically?  So the sheet has been opened at least once.  Seems like the sheet's attributes would be "initialized" at that time.  Perhaps there are additional attributes that still need to be set before using the API which could be done using sheetworkers?

Is there a javascript error with the " Error: Unable to find a character view" you're getting? It would tell you what sheet function is giving you the problem.

vÍnce said: When you create a new sheet ( "+ Character" from the sidebar), isn't it opened automatically?  So the sheet has been opened at least once.  Seems like the sheet's attributes would be "initialized" at that time.  Perhaps there are additional attributes that still need to be set before using the API which could be done using sheetworkers? Yes, one would think that the first opening at creation should be enough. But there seems to be something else the first time a sheet is opened for a given session. Re-loading the page seems to undo that step, and one needs to open the sheet again to have it in a 'good' state.

Timothy B. said: Is there a javascript error with the " Error: Unable to find a character view" you're getting? It would tell you what sheet function is giving you the problem. The function is populateListOptions . But the argument to the function seems quite ok.

I suspect there is some backend (Firebase) state that is being created by the VTT when the sheet is first opened, which is silently depended on by the sheet infrastructure. I don't know that it is tied to an event that the Mod Script Sandbox could issue, but it might be duplicatable (or better yet exportable) to the Mod Script Sandbox. I'll investigate and see what I can come up with. The best solution would be for characters to always be created in an initialized state, but that might not be reasonable to achieve currently.  Can you see if you have the same issue when the Character is created and configured from a Mod Script?  That would be a useful data point. 

This is because populateListOptions is a view interacting sheetworker that only runs on the client (aka your computer itself). If there is no character sheet view, then it can't do anything for that character sheet. Although, I'd think it should fail silently in that case, not cause complete failure. So, short answer, there's no way to trick the system into thinking the sheet was opened. It probably works after opening and closing the sheet because it then uses a stashed view of the sheet.

Did some testing, the error appears any time the character sheet is closed, not just before it's opened the first time. Note that an API script triggering these things might seem to fix the issue. I believe that the API server uses a stub version of populateListOptions that never tries to change the html, however that also means that using the API to cause these changes would result in populatelistOptions not working at all.

The Aaron said: I suspect there is some backend (Firebase) state that is being created by the VTT when the sheet is first opened, which is silently depended on by the sheet infrastructure. I don't know that it is tied to an event that the Mod Script Sandbox could issue, but it might be duplicatable (or better yet exportable) to the Mod Script Sandbox. I'll investigate and see what I can come up with. The best solution would be for characters to always be created in an initialized state, but that might not be reasonable to achieve currently.  Can you see if you have the same issue when the Character is created and configured from a Mod Script?  That would be a useful data point.  Yes I observe similar issues when I create a character through script. Thank you for taking a look! Other aspects I observed: issues with the $20 function addClass and removeClass (which seems to corroborate what Scott C. was saying), and the eventInfo for the attribute change in the token has undefined newValue and previousValue.

the undefined newValue/previousValue is a long standing bug. Best practice is to not rely on newValue/previousValue.

I remember that it was the case 9 years ago, when I wrote my first character sheet. It is a bit sad that Roll20 didn't fix that or just removed newValue and previousValue.