Detecting Jumpgate

With the recent advent of /s for roll buttons I am planning on adding secret rolls to the current options (everyone can see, me and GM can see). Currently, the functionality is implemented with a <select> and two <option>s with the values " " and "/w GM ". Adding "/s " works for Jumpgate games, but breaks rolls in legacy games. So, is there a way to detect the game type (legacy, Jumpgate) using JavaScript (sheetworker scripts)?

The only way I can think of to do so is to send a secret roll on sheet open and after it set a global variable (say isJumpgate) to true. If it isn't jumpgate the secret roll will fail, and the js will never get to that setting of the global variable. Of course the problem with this is that you spam chat with secret rolls (and spam the gm with them). That isn't really feasible or desirable.

Indeed, checking that on every sheet open would surely be overkill. But, that check does not require that frequency. For now, we have two game types and as far as I know you can only migrate from legacy to Jumpgate, so once the sheet passes as Jumpgate it is safe to assume that it stays that way. So, I imagine this to look like that: on:sheet-open Get game type. If game type is legacy, proceed. Get current time. Get time of last game type check. If last check was 24+ h ago, recheck. Check: Roll "/s {{msg=Automatic game type check roll. If this command produces an error, this game is a legacy game and, unfortunately, secret rolls are not available. This check will not be triggered for the next 24 hours. If you upgraded the game from legacy to Jumpgate and would like to force this recheck before the end of the cool down time, please use the 'Jumpgate Check' button on the info tab.}} {{jumpgate=[[1d1]]}}" CRP evaluate the roll results and if "jumpgate" is 1, this is a Jumpgate game, so set game type to Jumpgate.

The reason it will spam the chat isn't because of what one person opens. It's because of what happens when the GM and the 6 players in the party all log in to the game for the week. Each one of those will need to send the check because they can't (easily) check the status of other sheets and can't see the js variable state of those sheets. So, the gm then gets blasted with a message for each player. Now, you could do it so that it just assumes if jumpgate once, it is always jumpgate. That would mean you only get the spam once on sheet creation (and only if someone makes a new sheet before opening an existing sheet). That would cause less chat pollution, but on the other hand it would cause "random" chat pollution that users would likely not understand why it was or wasn't happening.

Isurandil said: Indeed, checking that on every sheet open would surely be overkill. But, that check does not require that frequency. For now, we have two game types and as far as I know you can only migrate from legacy to Jumpgate, so once the sheet passes as Jumpgate it is safe to assume that it stays that way. So, I imagine this to look like that: on:sheet-open Get game type. If game type is legacy, proceed. Get current time. Get time of last game type check. If last check was 24+ h ago, recheck. Check: Roll "/s {{msg=Automatic game type check roll. If this command produces an error, this game is a legacy game and, unfortunately, secret rolls are not available. This check will not be triggered for the next 24 hours. If you upgraded the game from legacy to Jumpgate and would like to force this recheck before the end of the cool down time, please use the 'Jumpgate Check' button on the info tab.}} {{jumpgate=[[1d1]]}}" CRP evaluate the roll results and if "jumpgate" is 1, this is a Jumpgate game, so set game type to Jumpgate. I posted a simple and hastily tested version (without the cool down stuff) on the Community Wiki . Turned out that using an unrecognized command will stop the script (hopefully not all of it forever, not yet tested!) so no need to look for a roll result. Just getting the execution past the await startRoll() is enough to proof that /s is recognized and the game is no legacy game. EDIT (we were probably posting more or less at the same time): Scott C. said: The reason it will spam the chat isn't because of what one person opens. It's because of what happens when the GM and the 6 players in the party all log in to the game for the week. Each one of those will need to send the check because they can't (easily) check the status of other sheets and can't see the js variable state of those sheets. So, the gm then gets blasted with a message for each player. I did not consider this such a big issue. The message it is currently displaying should/could explain to people what is happening, maybe even a bit better, but: Maybe someone else can find a better way/improve upon this solution. Or Roll20 adds a shiny new function getGameType() or getGameInfo().

I have a pretty high bar for what jankiness I will accept in a sheet. Most of the sheets I build are on contract for publishers, so I can't afford to have display issues like this in my output. However, like I said it will work, it's just a matter if you want to accept the jankiness.

Scott C. said: I have a pretty high bar for what jankiness I will accept in a sheet. Most of the sheets I build are on contract for publishers, so I can't afford to have display issues like this in my output. However, like I said it will work, it's just a matter if you want to accept the jankiness. I see. But, what would do if a publisher with an existing sheet asked you to add secret roll functionality without "adding jankiness" for legacy games? EDIT: Some more experimenting revealed that a) the execution stop is limited to that run of action attached to the action listener (i. e. everything else continues to work) and b) just having an action button for detecting the game type works without spamming the chat. While I would prefer a completely automatic solution, this might be superior (less janky) to repeated automatic tests.

I'd probably tell them the issues with the jankiness, lay out the options, which include what you've talked about here plus a few more that require a large support infrastructure of code to pull off, and then give them the option of what is most important to them.