Hey, James... you have to think of the metascripts as a series of loops before the destination script (ScriptCards) gets involved. The order of operations for a loop goes: Roll20 Parsing: ======================================== Abilities Macros Attributes (repeat these three up to 99 times) Roll queries (up to 99 levels deep) Inline Rolls Meta Toolbox Scripts: ================================== one after another in whatever order you have them installed (without ZeroFrame) or sequenced (with ZeroFrame) If ZeroFrame is installed and detects that changes have been made, it initiates the loop over again. The caveat about subsequent loops is that after the first loop you no longer get roll queries, and you no longer get @{selected...} resolution... only resolution by character name. Then, once all of that is done and ZeroFrame detects no further work to do, it releases the message... which then gets picked up by ScriptCards. So. You can see you can't really use ScriptCards to feed information *into* a metascript operation... at least while you're in the same message stack. (I'll explain that in a minute). You can agnosticize the metascript operation with Roll20 constructions, since those get parsed before the metascripts get at the message: {&mule ?{Mule character|}.Chart } {&mule @{Target|Mule character|character_name}.Chart} ...and then use the same Roll20 construction for your get/set statements: set.@{Target|Mule character|character_name}.Chart.Dexterity/set New Message Stack If you absolutely need to use information from ScriptCards in your metascript operation, that's fine. You can absolutely construct the appropriate meta-syntax. The question, then, is: how do you get that to process? Your metascript window has closed, right? Half right. ScriptCards can issue new outbound commands... I think the SC syntax is to start a line with --@scripthandle| If you send a new message, you start a new message with it's own metascript loop. While you can't further alter the initial message (that has already gone through the metascript loop), you can do things like set mule variables, etc. If you don't actually need the outbound message to land in another script, just use a dummy handle for a nonexistent script: --@meta|{^& mule [&Name].Chart} set^.[&Name].Chart.Dexterity = [$Dex]/^set Note the carets (^) used to break up the metascript syntax. I believe the ^ is the ScriptCards deferral character, but I think you can actually change that, too, so whatever you want to use, just follow ScriptCards syntax for establishing the deferral character. Whatever character you use, use it like I did to break up the character strings that would trigger a metascript (Muler, in this case) from detecting a syntax token on which it needs to take action. By using the deferral character, you hide it at the initial metascript loop. Then ScriptCards prepares your information, builds the syntax, removes the deferral character, and issues a new command. For the new message, the metascripts detect their work (Muler, in this case, recognizes a variable has to be set), and they do their thing before stepping out of the way. Then the message carries on, waiting to be picked up by a script that watches for !meta ... which you don't have. Or, if you do... pick something else. =D