I got it!! So I tried reading through the thread again to see if I missed anything and on the most recent page was this: timmaugh said: Rosco James said: Hey, All: About making API calls. I have this same problem with PowerCards as well as ScriptCards. I can’t seem to make my own API calls. I want to use Token-Mod API to set the status of a token. I would normally code !token-mod --set statusmarkers#!dead. With Scriptcards I’m trying with: !scriptcard {{ --@token-mod| _set statusmarkers#!dead }} No go. It’s not just a quick fix I'm looking for. It’s the concept I’m missing. I mean, go ahead and throw in the fix, but ‘splain how it works or won't work. What am I missing when I want to make similar calls with other APIs? As always, thanks ahead of time for the help. In addition to Will's excellent advice, when one API calls another, there is no selected token array, so you have to modify your line slightly. Sometimes, as with TokenMod, there is a way to do it within the command line itself: !token-mod --set statusmarkers#!dead ...becomes... !token-mod --set statusmarkers#!dead --ignore-selected --ids -M1234567890abcdef (Which is where Will's advice comes into play, requiring you to allow players to utilize IDs). If there is only ever one token selected, you can still resolve that with an @{selected|...} formation, since those will resolve even though the token won't survive as part of the array of selected tokens: !token-mod --set statusmarkers#!dead --ignore-selected --ids @{selected|token_id} Alternatively, whether or not a script offers a command-line way to designate the tokens to affect, or if you want to limit the players' ability to affect only the tokens they can select (instead of allowing the players to utilize the ids argument), you can use SelectManager to restore the selected tokens to downstream, API-generated script calls. For a call to TokenMod, which can affect all of the selected tokens, you wouldn't have to do anything other than ensure that SelectManager was configured to hand back the selected tokens (which it is by default). For another script that expected a single selected token but which you wanted to operate over many individual tokens, you can use SelectManager's !forselected handle. That will iterate the command over each token originally selected as individual calls. It offers a customizable escape character if you wanted to defer the detection of a token/character specific piece of data until the downstream call is made. While this deferral *doesn't* allow for standard roll20 parsable constructs (like @{selected|token_id} ) because there IS NO selected token until SelectManager restores it, it does allow for Fetch retrievals. Imagine using !forselected to call Spawn to tell 10 tokens to simultaneously spawn their "familiar". The name of each familiar is stored on the associated character sheet of each original token in an attribute called "FamiliarName". We don't want all 10 spawned tokens to be named "Albertus" just because the first character happened to have that in the FamiliarName field. We want them individualized. That command might look like: !forselected(^) !Spawn --name|@^(selected.FamiliarName) --offset|1,1 ...where the ^ character is being utilized to break up the Fetch construction of @(selected.FamiliarName) . When SelectManager dispatches the Spawn call for each token, that character is removed and the individual selected token is returned, so when the command line hits the installed scripts the Fetch construct is detectable and it has the correct token to pull information from. Obviously, the above lines must pass through one more syntax change to make them work in the ScriptCards macro (replacing -- with _, for instance). Also, if you are going to use more than one of the metascripts, I strongly suggest you install ZeroFrame as a controlling structure that lets you order and loop over them. So I used this to make the command: --@token-mod| _ids @{target|token_id} _set statusmarkers#!dead Which worked!
