Marstead said: Thanks for the help! I think I get the gist of what you're saying, it's tough not being as-immersed in the way Roll20 works under-the-hood. I'll apply the fixes you suggested, but can you help me simplify when I do and don't need deferral characters? Is this only when I'm using &select commands? Right now, the most complicated stuff I do with the API is deal and take cards, set token attribute values, set and remove marker values. If that's the only thing I'm doing do I only ever need ^ characters for the select statement lines? Thanks! Specifically in reference to batching lines (to avoid dropped commands), here are the basic ideas to consider when you think about deferral characters: 1) Does any part of your message (any of the multiple batched lines or any un-batched lines) contain a targeting statement? If so, you will not have a "selected" property -- that is, a script won't recognize any tokens are selected. (This is a bug that goes back to the original programming of Roll20 with the expectation that users would never want/need to have both selected tokens and targeted tokens.) 1A) Do you have tokens that need to be selected for all of the batched messages? That is, will all of the messages share the same selected tokens? If so, you can include a {&select} statement anywhere in the message and it will take effect during the first cycle -- before ZeroFrame dispatches the individual batched lines. 1B) Will messages require different tokens to be selected? If so, you will need to include individual {&select} statements to each line that needs to be different. Since you need these to be different, you will have to defer them so they don't resolve until the individual command line is dispatched. 2) Do you include a Fetch construction to retrieve token information from a selected token? Remember, Roll20 constructions for retrieving information from a selected token (like @{selected|token_id} ) will resolve before the message is even handed off to scripts, so it will act on the first token selected when you run the overall command -- before any {&select} statement would alter what tokens were selected. In fact, this Roll20 construction will resolve even if you have a targeting statement; you just won't have a selected token when the message reaches your scripts. Fetch constructions, on the other hand, run during the metascript cycle, and they run after {&select} statements (so long as ZeroFrame is installed, too). That way, you can use {&select} statements to alter what you have selected, then still use a Fetch construction to return data from the token, i.e. : @(selected.token_id) Fetch constructions also make more datapoints available than standard Roll20 constructions (Fetch lets you get things like rotation, Turn Order initiative value, aura distance, status markers, etc.), so you might need a Fetch construction even if you don't use a {&select} statement to select the tokens you want. 2A) If you are using a Fetch construction that will use the "selected" designation (like the example just above), is the correct token selected for the top level message (either by physical selection on the game board without a {&select} statement changing that information, or by an non-deferred {&select} statement)? If so, you don't need to defer the Fetch construction. It will act on the first selected token and will resolve before any individual message is dispatched. 2B) If the correct token is NOT selected until you are within a specific, individual command line (a batched command line), then you will need to defer the Fetch construction until you are in that line. You can use the same deferral as the {&select} statement would get, since during any metascript loop (the overall message loop or a loop for any given individual batched command line) Fetch runs after SelectManager by default. For instance, this batched command line (imagine this is within the !{{...}} enclosure): (^)!token-mod --set bar1|@^(selected.tracker) {^&select Volcano Man} That would only resolve the metascript constructions when this individual command was dispatched. At that point, the token named "Volcano Man" would be selected. Fetch would then use the selected token reference to return the Turn Order initiative value for the selected token. Since Fetch had to wait for the token to be selected, it also needed to be deferred. Finally, with all of that meta-work done, TokenMod can go about setting bar1 of the selected token (Volcano Man) to the value Fetch has returned. 3) Do you have to take individualized action on each of the selected tokens? For instance, perhaps you want to set a bar value equal to that token's tracker value, with each token having their own entry in the Turn Order. In that case, you will need to run forselected, and use forselected deferrals. If you need to select tokens for this batched sub-command (that is, this command will require different selected tokens than the overall command which reaches ZeroFrame, that {&select} statement will require ZeroFrame batch deferral, but the Fetch construction within the line can take the forselected deferral: (^)!forselected(~) token-mod --set bar1|@~(selected.tracker {^&select Goblin*} Nothing in the above line would register during the initial metascript loop while the message is on the way to ZeroFrame. Only when this line is dispatched will ZeroFrame detect the line-level deferral (the caret), and remove it from the downstream command it issues. When that message is received, it will pass through another metascript loop where the now-exposed {&select...} statement is detected, selecting all Goblins on the page. That will end the metascript work for that message, and it will pass to SelectManager (catching the forselected handle). SelectManager now has a message with all of the Golbins selected, and it is being asked to dispatch a TokenMod call for each Goblin token, iterating over them. As a part of this, SelectManager detects the deferral character declaration (the tilde), and it removes it from the command line it will dispatch. This, in effect, exposes the Fetch construction to retrieve the token's tracker value. Each of these iterated messages will have only 1 token selected (the next one in the series), so the Fetch construction referencing "selected" will now act on the correct token when each message registers finally to TokenMod. This is just a primer on the timing of things and when/why you might need to defer constructions, and how you would go about doing that. Any individual case might present complications, however, so if you run into trouble don't hesitate to post a question and I can try to answer.
