How to set token initiative equal to another token's initiative?

I need to be able to set a token's initiative equal to a selected token's, preferably using a spawnDefaultToken, but tokenMod is also available.

You could do this with ScriptCards, which can read & write the Turn Tracker. I don't think TokenMod can deal with the Turn Tracker, that's not a Token thing. 

Fetch has a way of retrieving that information, and can do it right from within another script's command line (like Spawn). The Fetch construction looks like this: @(selected.tracker) @(@{target|Initiative Source|token_id}.tracker) @(Token Name.tracker) The first option would use the currently selected token and get its tracker value. The second option would use a targeting statement to know why token you wanted to use as the source. And the third just uses a token's name to locate it. (You could also use a token id in that position to get the associated tracker value.) Just put that in whatever location of the Spawn command line (or whatever other script) to have it read and converted to the value you want. Also, if you want a default value (for instance, if the token isn't actually in the tracker),  you can include it in any of the formations by enclosing it in brackets right before the closing parentheses: @(selected.tracker[0]) And, finally, if you want to use this in a way that would do the math right in the line (adding some value to this initial tracker value), you can do that with MathOps, or by using ZeroFrame to defer an inline roll. Fetch, MathOps, and ZeroFrame are all installed as a part of the MetaScriptToolbox (available in the one-click). If you have a specific question on how to handle the math or the deferral I mentioned, post back and I can give an example.

What I'm trying to accomplish is having an enemy token be replaced with its buffed counter part as its easier for me to have 2 character sheets; one for the normal enemy and 1 for the buffed enemy. My macro looks like this, where "selected" would be the normal enemy !Spawn {{  --name|buffedEnemy  --bar1|[[@{selected|bar1}]]/10 --bar3|[[@{selected|bar3}]]/11 --tokenName|temp }} !token-mod --set layer|gmlayer !token-mod --set top|0 left|0 !script {{   --#hidecard|1   --=total|@(selected.tracker)   --~|turnorder;addtoken;@{temp|token_id};[$total] }} What I want is for the buffed enemy (whose name gets changed to temp for ease of access) to be placed on the map, then be given the same initiative as the selected, normal enemy. So far I can spawn it with the same HP bars. It seems like I can't get the token id of the buffedEnemy to get it added to the initiative. @(@{target|Initiative Source|token_id}.tracker) How does this one work?

UPDATE: I have a semi-functional method it's two major flaws are that it only allows for 1 buffed enemy at a time and I couldn't get ZeroFrame's delays to work with the !script, so I had to add a bunch of empty scripts to ensure the timing was correct but it does what I want it to. For context, this is for a Shadowrun 5e game where some generic enemies can use drugs for better stats. I found it easier to have 2 sheets for the buffed and unbuffed enemies and just drag & drop the buffed enemy onto the board, but wanted to automate the process. Now, I select the unbuffed enemy, play this macro, and the unbuffed enemy is "replaced" with his buffed version. If anyone can suggest and improvements, I would greatly appreciate them. !Spawn {{  --name| buffedEnemy --bar1|[[@{selected|bar1}]]/10 --bar3|[[@{selected|bar3}]]/11 }} /em The buffedEnemy hits a dose of kamikaze! He immediately gets the high. /w GM DON'T HAVE MORE THAN 1 HIGH GUY AT A TIME !script{{   --#hidecard|1 }} !script{{   --#hidecard|1 }} !script{{   --#hidecard|1 }} !script {{   --#hidecard|1   --=total|@(selected.tracker)   --~|turnorder;addtoken;@( buffedEnemy .token_id);[$total] }} !token-mod --set layer|gmlayer !token-mod --set top|0 left|0

So I see you set bar1 and bar3 on the token with new elements, so I am assuming bar2 is already set as well. One thought I have is if something is available on the token to stash the current turnorder, then you could cut out ScriptCards there and have the Spawn command execute an ability that will read the stashed turnorder and add it to the tracker. Somewhere like bar2 if available or the tooltip if you don't use the tooltip. Then you can use the same Fetch syntax to pull that in the ability and run it like a regular Init roll basically. Another idea I had would be to wrap it all in a ScriptCard, the ScriptCard would execute the Spawn first and you can use a re-entrant button to then pull the token id from the newly spawned token and do the remainder of the script. Obviously that would add 1 extra click to the summon as you have to click another button since Spawn would fire after the ScriptCard so getting the newly created token id during the initial ScriptCard run is impossible I believe. The upside of this would be that you should be able to add the initial token id to the --#reentrant value so it can be run for multiple tokens if you want.

Joshua N. said: So I see you set bar1 and bar3 on the token with new elements, so I am assuming bar2 is already set as well. One thought I have is if something is available on the token to stash the current turnorder, then you could cut out ScriptCards there and have the Spawn command execute an ability that will read the stashed turnorder and add it to the tracker. Somewhere like bar2 if available or the tooltip if you don't use the tooltip. Then you can use the same Fetch syntax to pull that in the ability and run it like a regular Init roll basically. This is what I was referring to... if Spawn has the ability to add the token to the Turn Order with some value that you supply, you don't have to store the initiative somewhere on the character (or token). That is exactly where you could use the Fetch construction to return the current tracker value of the token being replaced by the one you Spawn. I'm looking for the Spawn syntax to add it to the Turn Order... I thought it could do it, but I can't find it in the documentation at the moment...

Spawn has an option to use an ability with some limits.  Documented options here Since you have the buffed and unbuffed character sheets linked, creating an ability to do do the turnorder sounds like it should work even with the limits Spawn's ability execution has, although I will admit I have not tested Spawn using an ability that uses Fetch, so that could very well be an incorrect assumption.

Ah, I see what you're saying. Yes, with the right setup to the command line in the triggered ability, Fetch would work, even with the limitations David described in the linked thread. However, I believe Spawn has a more direct "--turnorder|" argument that would do this directly, but I've asked David for clarification on its usage, since I still can't find it. =D

Oh that would be neat, I've looked at what I think is the source code repo  and didn't see anything related to turnorder, tracker, or initiative so I thought ability was the only option but would be cool to be proven wrong about that.

Joshua N. said: So I see you set bar1 and bar3 on the token with new elements, so I am assuming bar2 is already set as well. One thought I have is if something is available on the token to stash the current turnorder, then you could cut out ScriptCards there and have the Spawn command execute an ability that will read the stashed turnorder and add it to the tracker. Somewhere like bar2 if available or the tooltip if you don't use the tooltip. Then you can use the same Fetch syntax to pull that in the ability and run it like a regular Init roll basically. Another idea I had would be to wrap it all in a ScriptCard, the ScriptCard would execute the Spawn first and you can use a re-entrant button to then pull the token id from the newly spawned token and do the remainder of the script. Obviously that would add 1 extra click to the summon as you have to click another button since Spawn would fire after the ScriptCard so getting the newly created token id during the initial ScriptCard run is impossible I believe. The upside of this would be that you should be able to add the initial token id to the --#reentrant value so it can be run for multiple tokens if you want. Actually, no. I'm not using bar2. I'll give that a try next time