To Roll20 Devs: Please Please Please Allow Selections Across Pages

I am a long time GM and mod developer. I recently have been working on a new mod called Gaslight. It is working right now, but it would be working so much better if SelectManager could pass selected tokens across pages. Here is the scenario: I run a command using SelectManager to select tokens A, B, and C. The command fires, but because A, B, and C are all on a different page than the one that I am currently looking at, the command's msg.selected contains no tokens, causing it to fail. I set a timeout to run the same command after 10 seconds, and during that time, I switch to the page that contains tokens A, B, and C. The command fires and runs fine because A, B, and C are on the same page as me. I assume that this is a limitation of Roll20's environment and not a limitation of SelectManager, since tokens I select on other pages manually become un-selected when I transition to a different page. I don't ask for much, but this one thing would really make my day. Please, please, please, and thank you.

The Mod sandbox itself can affect tokens on any page. Tokens are graphic objects with a _pageid, and a script can modify them by ID whether or not that page is currently being viewed. The limitation here is msg.selected, not the sandbox’s reach. msg.selected comes from the VTT client’s current selection at the moment the chat command is sent, and Roll20 selection is page-local. If the GM is on a different page, tokens on another page are not part of the current client selection, so they won’t be in msg.selected. Gaslight can use stored token IDs, explicit token IDs, page ID plus criteria, character IDs, or some other way to find the intended graphics without depending on msg.selected. If you post your code (or a link to it in Github or elsewhere) then others could help with troubleshooting.

Gaslight is operating as a meta-script. I know I can store my own token IDs. The point is that I wish to utilize SelectManager to inject tokens from other pages into msg.selected for other API. I know that this is a limitation of the VTT client. This is why the title of the thread starts with "To Roll20 Devs:" . What I am asking for is NOT something that can be fixed with plugin API.

A Roll20 mod can store a cross-page “virtual selection” in state , then later use that stored list to run actions against those tokens. A workable pattern would be: state.GaslightSelections = {   mySelectionName: [     { _id: tokenAId, _type: 'graphic' },     { _id: tokenBId, _type: 'graphic' },     { _id: tokenCId, _type: 'graphic' }   ] }; It would not be a real VTT selection, and it would not visually select tokens across pages. But it could absolutely behave like a selection for other API scripts , as long as those scripts rely on msg.selected and can operate on token IDs that exist on other pages.

Right. So for API scripts that can run against IDs, there's no problem here. I've already got that figured out. The issue is that I'd like to have this work seamlessly for API scripts that run against selected tokens only. And in those cases, I need to be able to inject tokens into msg.selected.

Kenan Millet said: &nbsp;This is why the title of the thread starts with "To Roll20 Devs:" .&nbsp; If you want to contact the Devs the forums are not the best place for that. The forums are primarily community help. The Devs may or may not see it.&nbsp; File a Help Center request or a Suggestion in the Suggestions forum.&nbsp; Help Center:&nbsp; <a href="https://help.roll20.net/hc/requests/new" rel="nofollow">https://help.roll20.net/hc/requests/new</a> Suggestions forum:&nbsp; <a href="https://app.roll20.net/forum/category/385189" rel="nofollow">https://app.roll20.net/forum/category/385189</a>

(Author of SelectManager and the other metascripts in the Metascript Toolbox)... Fetch can refer to tokens from another page in a couple of ways: 1) if the token is uniquely named across the game (I know, not always ideal), and 2) by using a page reference in the Fetch construction (new in 2.2.1) Because you're using a Fetch construction to return the token, and Fetch typically runs AFTER SelectManager (if you have the full Toolbox installed), you either need to defer the SelectManager construction: {\&amp;select ... } ...or you could use a ZeroFrame timing structure to reorder Fetch to be first: {&amp;0 fetch, sm} Also, if you are operating as a metascript but (it would seem) *not* registering to ZeroFrame, you'll need to make sure your script is installed *after* the Toolbox to make sure that the Toolbox can do all of the above before your script sees the message. (Seems like you're doing that already, but figured I'd say it.) If you have any trouble utilizing or building the new functionality of Fetch and making it work with SelectManager, post back.

To make it clear... Fetch does not require the unique name to reference a token from another page if you're using the method from update 2.2.1 (linked). Those were 2 different methods of referring to a token from another page.

I guess I'm a bit confused @timmaugh. Are you suggesting that I can pass token IDs to SelectManager in a command, and it WILL add them to the msg.selected for that command even if the token IDs that I pass to SelectManager are on a different page? Because the behavior that I am seeing is that it only worked when I was on the same page as the tokens that I passed to SelectManager.

Kenan Millet said: I guess I'm a bit confused @timmaugh. Are you suggesting that I can pass token IDs to SelectManager in a command, and it WILL add them to the msg.selected for that command even if the token IDs that I pass to SelectManager are on a different page? Sooooo... you're right. I just double checked and while I'd opened up Fetch to retrieve token information via page reference, I hadn't opened up SelectManager to do the same thing. So while Fetch *would* retrieve the token ID from another page for you, SelectManager was losing that token because it didn't cmoe from the same page that you were on. But I just fixed that in SelectManager and pushed the update into the merge queue.&nbsp;Once that propagates down to your game, you should be able to EITHER: use a Fetch construction with a page reference to retrieve the token ID, i.e., @(Bob[Token Library Page].token_id), ...or... use an explicit token ID you've pre-retrieved from another page and hard-coded into your command line If you need it before the merge happens, you can modify SelectManager yourself. Change line 234 to: &nbsp; &nbsp; &nbsp; &nbsp; let alltokens = [...findObjs({ type: 'graphic', pageid: pageid }), ...findObjs({ type: 'text', pageid: pageid }), ...findObjs({ type: 'path', pageid: pageid })] Obviously the second option is more static (having to pre-retrieve the token IDs from whatever page they are on), however it does come with the benefit of not having to defer other constructions that would establish or rely on the token being in the msg.selected array. The opposite is true for the first option... it offers the benefit of being more "run time" oriented (you don't have to know what the ID is of the "Bob" token on the "Token Library Page" page, you just need to know that you HAVE a token named "Bob" on the "Token Library Page" page), but it *will* require the deferrals. For instance, since Fetch runs after SelectManager (by default), you'd have to defer the "select" construction that would be establishing the select tokens: {\&amp;select @(Bob[Token Library Page].token_id) } And if you were going to retrieve any information from the selected token in the command line, it would have to be deferred to wait until SelectManager had a chance to select the token: @\(select.hp) All together, that could look like: !The HP of @\(selected.name) is @\(selected.hp). {&amp;simple} {\&amp;select @(Bob[Token Library Page].token_id) } A quick explanation... In any metascript loop, SelectManager will run before Fetch: Loop N SelectManager Fetch Since SelectManager will rely on Fetch having returned the ID of the token to select, we can't let it try to find the token before the Fetch construction has resolved. That means we defer it (to hide the construction), and our work proceeds as: Loop 1 SelectManager - no work detected Fetch - retrieve ID of Bob from "Token Library Page" Loop 2 SelectManager - select the token with the ID (as returned by Fetch in Loop 1) Fetch - retrieve info from the currently selected token (as selected by SelectManager in Loop 2)