Hey, Rock... We can defer the inline roll using ZeroFrame deferrals, however there will still be an issue for what you want to do. Here is the way you would defer that roll (not worrying about the &{tracker} bit, for now... and adding a {&simple} tag so you can see the output to verify): ![\][\] get.Dunric.mule.initValue \]\] {&simple} (Remember that if your variable retrieval is fully qualified (character, mule, variable), you don't need to *also* use the {&mule} tag to get the mule added and available... so I can remove it from the message.) The number of backslashes indicates the number of cycles the inline roll needs to wait. Since the mule loads and the variable resolves all in the first pass of the ZeroFrame loop, you only need the single backslash (one deferral). If you're not getting the result you want out of the above command line, we can take a look at what else might be going on, so post back if that is the case. The problem you're going to have with this is the order of operations and the state of each message as they are sent to Roll20. The short explanation is that &{tracker} won't work with this kind of roll because at the time Roll20 sees the roll, there is no associated token. The longer explanation (feel free to skip to the workaround, below, if you don't care) is that there are 2 messages happening for this command. The first message (the parent message) is caught by ZeroFrame and sent through the metascript loop. Since this message would have been sent by a player/gm (i.e., you), there will be a selected token. However, since we deferred the inline roll, there will be no resolved-inline-roll, yet. The message goes through the metascript loop and muler supplies the information to the command line (the initValue in the variable). ZeroFrame sees that work was done, so it un-defers the inline roll and dispatches a new message to Roll20 in the background. Although this message will now have an inline roll that Roll20 will detect, since it was sent by a script it will NOT have a selected token. That means that even though Roll20 sees the &{tracker} tag in the inline roll syntax, it won't have a token to add/update in the turn tracker. (Even removing/leaving the {&simple} tag won't affect this since the &{tracker} tag is processed on the Roll20 side before the message returns, and ZeroFrame only processes the {&simple} tag after the message has returned from Roll20.) Workaround I have intended to add the ability for ZeroFrame to process this situation natively (detecting whether it sees the &{tracker} tag in an inline roll in a message it is about to dispatch). When it gets the roll back from Roll20, it could insert/edit the selected token in the Turn Tracker with the new initiative value. Handled correctly, it could even give you more flexibility (having multiple tokens selected, for example). However, I haven't had the time to implement that fix, yet. For now, to handle the situation you want (using a Muled variable to drive entry into the Turn Tracker), I would suggest using a script that does that job specifically. The metascripts will still supply the data you need, and should supply it before the other script would see the message so it won't know the difference. The good news is that in this case you shouldn't need an inline roll (the script you use would likely be just as happy with a simple value). So that might look like: !initScript --value|get.Dunric.mule.initValue/get Or, you could agnosticize it to work with any selected token, if they all had a similar "mule" ability with an initValue variable: !initScript --value|get.@{selected|character_name}.mule.initValue/get The above is just an example command line to a hypothetical script. I know there are several scripts in the repo that would handle this sort of operation for you, so I'll leave determining which you would want to use to you. For my part, I'll move adding this sort of functionality to ZeroFrame to the top of my to-do pile for when I get a minute.
