Yes, sorry... I should have included that bit about the Plugger syntax. I'll try to keep the footprint of the meta stuff in this thread to a minimum, but just so it's all in one place should anyone want to know how to do it... Plugger can call scripts (like ScriptCards can), where it sends the command through the chat parser. Doing that creates an entirely new message with the playerid = 'API', so it doesn't help you on its own. However, Plugger also allows scripts to register as "plugins" so that instead of sending a new message to the chat parser, it simply hands off to the registered function the message object as it stands (with the playerid, inlinerolls, content, etc.). Scripts that register as plugins also gain the opportunity to return something to the command line if they want. That's where the "who called?" question comes into play. If your plugin can detect that it was called from Plugger, it might want to return something to the command line. Obviously, if you don't return anything, a zero-length string is returned, and by the time ScriptCards receives the macro line, it has no idea all of this went on. To register find-token as a plug-in, you'll want this somewhere in that script: on('ready', () => { try { Plugger.RegisterRule(handleInput); } catch (error) { log(error); } }); Where "handleInput" is whatever function handles the chat event. Using a generic name like "handleInput" can lead to name collisions if you register a few scripts to Plugger and they all use the "handleInput" name for their chat handler. In that case, I suggest a renaming wrapper function: const findtokenHandleInput (m) = handleInput;(m); ...and then registering that wrapper in the try/catch example just above, or exposing the chat handler from find-token, then registering the fully qualified name: Plugger.RegisterRule(findtoken.handleInput) However you register it, to call it, take the command line as you would send it through chat and use parentheses to wrap around the arguments. Put all of that in {&eval} ... {& /eval} tags: {&eval}find-token(--Kharg){& /eval} That will run the find-token script as if the command line were "!find-token --Kharg", but it will do it with the inlinerolls, who, playerid, etc., already caught and processed from when the ScriptCards macro was called. If you DON'T need ScriptCards to do anything based on the result of calling find-token, then you can put it anywhere in the ScriptCards macro and make sure it returns nothing (which most scripts do -- they return nothing from their handleInput function). If it DOES return something already and you don't want it to, just bury it in ScriptCards syntax that won't go anywhere... like assign it to a variable you'll never use. If you WANT it to return something and it does not currently (like the token's location, let's say), then you can add a couple of lines to the bottom of the handleInput function in find-token. if(msg.eval) { return... } And add whatever you want it to return. As long as that is text, number, boolean, or bigint, the results returned from a plugin are put into the macro line in place of the entire {& eval}...{& /eval} structure, leaving that new content there for when ScriptCards parses the line. OK, so maybe not a huge success keeping the meta footprint on the ScriptCards thread to a minimum, but that's all the info you should need to turn find-token into a Plugger plugin that can run in your ScriptCards macro. In deference to Kurt, if you have any questions, hit me up on the Plugger thread and I'll answer them there!
