Call a macro while turnorder event NPC

Hello, I'm very new with script but am very happy to see all the possibilities. First example for me : I would like to all a specific macro each time the turn order arrives only to a NPC I created a personnal script easy for now (pasted from the forum), but dont know how to specific that the player has to be a NPC, and to actually call the macro. To be noticed that, to run the macro, the token of the current NPC in turn order has to be selected... Thanks in advance ;) function DoSomething(){     sendChat('Crawler','DoSomething triggered'); } on("change:campaign:turnorder", function(obj){         sendChat('Crawler','on event triggered');         DoSomething(); });

Take a look at the OnMyTurn script that TheAaron wrote a few years ago. 

Yes, thanks David. I indeed found it but meets issue to make it start a #macro inside the "OnMyTurn" ability. I should post directly in this thread...

If you are trying to call a collections macro, try using this syntax in your ability: #MacroName

Here is what i di... may be I miss something obvious...

Hm, so I've never actually used OnMyTurn (haha), just remembered seeing it on the forums. My guess is that there is an "Inception"-type issue calling the ActionNPC macro from an ability from a script (OnMyTurn). You might try putting the text of the macro directly in the OnMyTurn ability. However, there is a possibility that the powercard may crash your sandbox if it is looking for the Player DisplayName who sent the api command, since now it is "API" that is sending the message. I don't use powercards, so I'm not sure if that script supports being called from another script.  If there are still problems after putting the powercard directly into your OnMyTurn ability, there might be some shenanigans that you can pull using something from timmaugh's ZeroFrame suite, but he would have to chime in with that. Or, Aaron might stumble on this thread and be able to shed some light, or you could try sending either one a PM.

Thank for your answer. Indeed, if I put the content of my macro ActionNPC directly in the box of "OnMyTurn" ability, its works great (but for now I dont like this option, requiring to change X NPC if I improve my ActionNPC macro). I'll wait a bit to see if someone get's it. About powercard, don't think thats the issue. If I replace the content of my macro ActionNPC with just "/r 1d20", I get the same trouble. Looks like the script does not want to call an external macro.

I am not in front of my computer at the moment to test this, but I think you might have a simple solution, and if that fails, you can use Fetch to help out. (It's just so rare that I've used Fetch to retrieve a macro that I'll have to double-check the syntax, later!) Here's what I'm thinking: OnMyTurn is issuing the PowerCard command line (the contents of your macro) if you input it directly to the OnMyTurn ability. That means that it is issuing a message with an API command. We can take advantage of that. A message will follow the order of operations to expand a macro, you just have to make sure that you trigger OMT to actually dispatch the message. That means you could change the OnMyTurn ability to start with an exclamation point and remove the exclamation point from your macro: OnMyTurn: !#ActionNPC ActionNPC: power {{ ... }} If you wanted to run your macro directly (instead of only running it when an NPC's turn comes around, you could have a "launch" macro that does the same thing: LaunchActionNPC: !#ActionNPC Fetch Alternative If that doesn't work, you can try Fetch. Fetch is a metascript that can get in and play in the message command line before the destination script (PowerCards) gets a hold of it. Fetch will retrieve the contents of a macro with the syntax of: #(macroName) So, the same parameters should work that you would start the OnMyTurn ability with the exclamation point and remove it fromi the ActionNPC macro: !#(ActionNPC) ...and then possibly employ a "launch" macro for times when you want to run it directly.

Thanks a lot ! Understood the logical of your proposal, however that does not work, for both solutions... It's perfectly ok if I manualy launch the ability "OnMyTurn" from the charsheet with !#ActionNPC in it, but nothing happen if this is the turn order change that occurs... The Ability OnMyTurn is well launched (I put in second line a /r 1d20 that works), but I have nothing about my "ActionNPC" macro... Too difficult for me ^^ ! PS : Installed fetch as well... same same....

Ok, let me look tonight when I can get to my computer.

I have read through the OnMyTurn script, and nothing there seems like it would cause a problem. It does its thing to locate the character from the token, and runs the appropriate ability. In fact, you say that when you run the ability yourself, it works. But when OMT runs it, you don't get anything. Even more indicative of what is going on, if you add the roll command, *that* processes, but not the PowerCard. That tells me that PowerCards needs a little help to be run in this way. When you step back, you're running an API (PowerCards) from an API (OnMyTurn). When you do that, you lose certain portions of a typical message... like selected tokens, "who" sent the message, and the playerid of the sending player. My new guess is that PowerCards needs one of these things to make it go. The good news is that SelectManager can help with that. It comes preconfigured to give back the selected token, but you can also turn on the other 2 properties. I would install SM, then run the most simplified version of your ability (just "#ActionNPC"). If that doesn't work, you can tell SM to give back one of the other two properties... I would start with "who": !smconfig +who If that doesn't work, then you can add the playerid to the give back list: !smconfig +playerid I'm thinking one of those will unlock PowerCards to do what it needs to do... but if not, post back and we'll keep digging.

Thanks again for your time. For using this script, so : 1) I installed SelectManager 2) I write once in the chat the two command you mentionned > the chat said "enabled" for both as an answer. Is There anything else to do in OnMyTurn ability when I call the ActionNPC ? If Not, I did that but same problem calling "#ActionNPC" only Also, I got some lock on token when I do that... Anyway, dont loose too much time on this, I will finish the content of my ActionNPC at the maximum quality, and think I will copy/paste the entire macro text directly in the ability... This is embarassing only if I want to change the powercard, but I will try to avoid that :p

OK, one more try short of spinning up all the infrastructure to mimic your setup. Now that I take a closer look at your macro, yes, there is something else to do. You have Roll20 constructions like: @{selected|token_id} Roll20 is going to try to resolve those at the time you send the message (or, more properly, when OnMyTurn sends that message). At that point, there is no selected token because this message is created and sent from the API. SelectManager gives the selected token back to the resulting message, but only after Roll20 hands the message off to the stack of installed scripts -- in other words, after the above formation has been parsed and replaced with the appropriate value. That's too late. So we need to delay those @{selected} constructions until after SelectManager gives back the selected token. We can do that by turning them into Fetch constructions instead: @(selected.token_id) @(selected.character_name) @(selected.character_id) @(selected.bar1_max) (I think those are the only ones I see in your macro, above.) Since these run in an the API, they get resolved later than Roll20 constructions. We just have to make sure that they are resolved *after* SelectManager has a chance to restore the selected token. Since the order of script execution goes from first installed to last installed, that would mean having to make sure that Fetch was installed *after* SelectManager... but there is an easier way: Install one more script, ZeroFrame. ZeroFrame controls the other metascripts in a loop. Aside from giving you other options that you won't need for this particular application, it runs the metascripts in order, and allows you to change the order of metascript execution from loop pass to loop pass. For your usage in this case, the default order ZeroFrame establishes will suffice (it will let SelectManager run first, whether or not Fetch is installed before or after). Try that, and if it doesn't work, post your new macro code just so I can double check your syntax.

What a motivation ! So I reduced the ActionNPC to the very minimum in order to test it. SelectManager & Fetch > Check, SelectManager first Zeroframe > Check Abilities "OnMyTurn" with "#ActionNPC" Still same result...! Honestly, it seems to be hard to solve, let it go men ;) FYI, the entire ActionNPC macro !power {{ --tokenid|@{selected|token_id} --emote|@{selected|character_name} --name|@{selected|character_name} --Points de Vie |--> [!@{selected|bar1}!]/@{selected|bar1|max} --Classe d'Armure|--> [!@{selected|ac}!] --npc_trait_list|@{selected|character_id} --whisper|GM --bodyfontsize|13px --emote| --tokenid|@{selected|token_id} --npc_attribute_summary|@{selected|character_id} --npc_skills_summary|@{selected|character_id} --npc_qualities_summary|@{selected|character_id} --template|template_npc --npc_action_list|@{selected|character_id} --spell_list|@{selected|character_id} --!Reactions|**Available Reactions** --npc_reaction_list|@{selected|character_id} --spell_slots|@{selected|character_id} --spell_list|@{selected|character_id} --!LA|**Legendary Actions** --npc_legendaryaction_list|@{selected|character_id} }}

My god, man. Do you even know what you ask? =D I looked into this some more, and I can now tell you what the problem is. MetaScripts work based on registering in the script stack before other scripts... that way they can do what they do in the message before the intended-recipient script receives the message. Other scripts, however, are sometimes built to register themselves at "metaspeed"... effectively using the metascript registration trick, and getting themselves into the script stack before other scripts. At that point, we're back to which script (registering at meta-speed) is installed first. In your case, you installed the metascripts (SelectManager, Fetch, and ZeroFrame) after you had PowerCards installed. That means that none of the metascripts will run until it's too late. PowerCards will process first. So everything you tried to do with the metascripts wouldn't ever work -- they never did anything. I converted PowerCards to a standard script (not registering at meta-speed), and confirmed with a very simple PowerCards macro, OnMyTurn, ZeroFrame, and Fetch that the Fetch construction of retrieving the macro will work. OnMyTurn sends the command, Fetch retrieves the macro text, and PowerCards runs. After that, it's just a matter of making sure your PowerCards macro retrieves the data from the selected token by using Fetch constructions instead of Roll20 constructions (Roll20 parsing will be over and done by the time all of this happens). You can achieve the same effect simply by removing PowerCards and reinstalling it after the above metascripts*. So. Your component parts should be: OnMyTurn (ability) !#(ActionNPC) ActionNPC (macro) power {{ --tokenid|@(selected|token_id) --emote|@(selected.character_name) --name|@(selected.character_name) --Points de Vie |--> [!@(selected.bar1)!]/@(selected.bar1_max) --Classe d'Armure|--> [!@(selected.ac)!] --npc_trait_list|@(selected.character_id) --whisper|GM --bodyfontsize|13px --emote| --tokenid|@(selected.token_id) --npc_attribute_summary|@(selected.character_id) --npc_skills_summary|@(selected.character_id) --npc_qualities_summary|@(selected.character_id) --template|template_npc --npc_action_list|@(selected.character_id) --spell_list|@(selected.character_id) --!Reactions|**Available Reactions** --npc_reaction_list|@(selected.character_id) --spell_slots|@(selected.character_id) --spell_list|@(selected.character_id) --!LA|**Legendary Actions** --npc_legendaryaction_list|@(selected.character_id) }} I think that's right. * - this works, if you can make it happen. In my testing, sometimes even though I installed PowerCards as the last script in the stack, it would lodge itself not as the last script but a few forward from there.

Ah ! Awesome and almost perfect. Thanks a lot for your time The last issue : the macro is messing, because it doesnt know on which token it has to send the macro, that requires to select. To finish : is there a way (macro or onChange event in turn order) to auto select the current token in the turn order. If I do that before the OnMyTurn is activated, it will know on which token it has to start my ActionNPC. For know, its kind of chaotic, it sends the ActionNPC automatically, but not in the good token.

The easiest way would be for me to give you a Fetch construction that could pull out the token associated with the current token. Something like: @(tracker.token_id) That doesn't work yet, of course, but I'll get it knocked out relatively quickly and let you know!

OK, I've pushed that change out. You should get Fetch from my repo or wait for it to update from the 1-click with the next merge. (I'll put more details in the Fetch thread as soon as I can get some time.) You're looking for version 1.0.10. What you're going to want to do is use the construction: @(tracker.token_id) ...as part of a SelectManager select construction: {& select <<some token's identifying info>>} The trick is that typically SM will run before Fetch in the loop, so you'll want to DEFER the SelectManager construction using a backslash: {\& select @(tracker.token_id)} ...so that the Fetch call to get the token from the Turn Tracker will resolve first, then be used to seed the selected token when ZeroFrame loops around and runs the once-deferred constructions. You can put the above construction anywhere in your PowerCards macro and it will "virtually" select the token identified by the token id you have returned. Then, the rest of your Fetch calls in that PowerCards macro  rely on that selected token, so you're going to want to defer those, as well: @\(selected.character_id) @\(selected.bar1) @\(selected.bar1_max) etc. This way, they will resolve only in the second loop; and since Fetch runs after SelectManager, once that loop comes around, SelectManager will have "selected" the token you're after. Let me know if anything isn't clear. I'm sure I can muddy it up a bit more. =D