My apologies on the incoherence of that sentence. Talk-to-post failed me, there, but I have corrected the sentence in my previous post. Also, just entering a Fetch construction like @(Bob.token_id) into chat won't do anything. All of the metascripts require that your message starts as a bangsy message (prepended with ! ) to let them do work. This is because... while scripts can listen for non-bangsy messages (taking action based on simple chat messages that never go to the Script Moderator), the whole point of metascripts (like Fetch) is to process the message and add/remove data from it along the way... before another script picks the message up. Scripts can't change a simple message headed to chat, so it wouldn't help to try to have Fetch look for Fetch-constructions in a normal message... the Fetch construction would still be in the message that hit the chat output. So you'll have to start with a bangsy message. The easiest way to see if Fetch is working would be to install ZeroFrame (the metascript organizing script), and then send a message using its {&simple} syntax. The {&simple} tag outputs the message as a simple chat message once all of the metascripts (like Fetch) have had a chance to make their alterations. So, with Fetch and ZeroFrame installed, you can test your Fetch construction like this: !The ID returned by Fetch is @(Bob.token_id[not found]).{&simple} You should see something like this hit the chat: The ID returned by Fetch is -M1234567890abcdef ...or... The ID returned by Fetch is not found The "not found" bit in the Fetch construction is a default value in case nothing is found... ie, if the token can't be found to return an ID. Seeing that in the chat would tell you that Fetch is, indeed, working, but you just haven't referenced a token that Fetch can find. If, instead, you see the Fetch construction survive into the chat: The ID returned by Fetch is @(Bob.token_id[not found]) ... that would tell you that Fetch is either not installed, disabled, or that there is some other problem. Once you've confirmed that Fetch is going to return the data you want, I believe the syntax to declare a variable in ScriptCards is: --=var|value EDIT : Corrected by David's post, above. Regarding SelectManager... To understand metascripts (and ScriptCards) generally, you have to remember which message you're in, and when you want the meta-construction to be detected. In something like what you posted from the ScriptCards documentation: --@token-mod|{^& select Quej Gr'stra} _on showname ...that is the way ScriptCards will dispatch a new, outbound message. So we have our first message (sent to ScriptCards), and then ScriptCards constructs a new command line (from what you provide), and sends a new message out (which, in this case, will be picked up by TokenMod). Both of those messages will go through the entire stack of scripts you have installed, it just happens that not every script will take action. They're all testing for the triggers that tell them "this is my message... it's time to get to work." (Metascripts sit at the head of that queue, and instead of looking for a trigger that tells them "this is my message", they look for triggers that tell them to do things to the message... if you think of the message as a train and installed scripts as stops along the train's route, metascripts are more like a series of tunnels that let the train pass through.) The important bit is that since both messages will run through the metascripts, you have to know when you want to actually "select" the token. If you let SelectManager see that {&select} structure in the first message (the message that will eventually land in ScriptCards), then the token will be detected for the first message. That isn't what you'd want. You want to select the token (in this case) for the message that will land with TokenMod (ie, the second message). So the documentation you copy/pasted is showing you also how to defer (using the ^ character) the SelectManager construction {&select} so that it isn't immediately detected. When ScriptCards dispatches the new message (through chat, but which we know TokenMod will pick up), it removes the caret. That means that when the second message goes through the scripts installed in your game, SelectManager will now see the construction and select the token you want... and all prior to TokenMod catching the message. That's just explanation for that bit of documentation... in your case, you don't have an outbound message. You just want to be able to access the token immediately in your ScriptCards command line. So you wouldn't defer the detection of the selection. You'd just put this somewhere in your command line: {&select Bob} After that, the token is selected -- and it is selected in the right message -- but this only happens after Roll20 parsers have had their chance at the message, so you aren't going to be able to use Roll20 constructions like @{selected|token_id} ... because at the time you dispatch the message and the Roll20 parsers examine the message, you don't yet have the correct token selected. Using the SelectManager method, you have to use another script to pull the data you want. That can be Fetch, using a reference to the selected token: @(selected.token_id) ...or it can be ScriptCards, using ScriptCards syntax to reference the selected token (ScriptCards doesn't know that the token selection was added by SelectManager... and it doesn't care). Those are two options beyond the initial idea of just using Fetch, where you can use Fetch directly in the ScriptCards syntax... ...but I'm just your resident metamancer. After verifying that Fetch works by using ZeroFrame (as mentioned above) and after replacing Bob with your token name (obviously), if the above doesn't work we'll want a ScriptCard acolyte to weigh in. One caveat about using SelectManager and Fetch without ZeroFrame... If you don't use ZeroFrame, then the metascripts run only once, and they run in the order you have them installed in your script stack (even though they'll run before standard scripts). If you have Fetch installed before SelectManager, then you won't be able to first select the token and then pull the data using Fetch. When Fetch discovers its syntax structure in the command line, it will try to pull the data from the selected token at that point... and you don't know what token (if any) will be selected. By having ZeroFrame installed, it will organize the other scripts into an order that typically makes sense (and which you can change), and it will loop through the metascripts until they are done. In the default configuration, SelectManager runs before Fetch. If you are still having issues... If you're still having issues after all of this, please post a screenshot of your installed scripts, and the actual text of the command you're trying to run. Or you can send me an invite to your game and I'll come take a look. We'll get to the bottom of it!
