Multi stage macro

So I'm not sure if any of this is possible or not but I'm trying to get a macro when it will run through multiple stages  (I will use these images as a reference it will be a flippable token with image 1 being the blank one and the starting point) 1: Change the flippable token image to image 1 the blank one  2: Play a sound  3: When the sound is finished playing randomly change the token to any side other than side 1 I know how to get token mod to flip a token but I do not know how to make it choose a random one much less one that excludes one of the sides. I also don't know how to get a macro to play a sound (though I'm sure that could be looked up easily) and then delay then next macro (until the sound finishes)

That will have to be a custom API script, which I think you can probably build using a timer. You can't do it with standard mechanics.

I was worried about that since I have no idea how to even remotely do that.  

I'd bet the meta toolbox can do this. Paging the metamancer!

Ok lets say we drop the sound. Is there a way to choose a random side of a flippable token excluding one of the sides?

Do you mean with ever diminishing choices? I.e. keep choosing a new, random, unused side until all sides are used up? If so, I don't know of a way without writing a script.

Master Azroth said: Ok lets say we drop the sound. Is there a way to choose a random side of a flippable token excluding one of the sides? You described three stages. All of them require the API (except the first probably) - none of them can be done with the basic mechanics of roll20. They all doable with the API though. I think the trickiest part is having a timer that doesnt do something immediately, but waits and *then* does something. It's also the riskiest part from a GM point of view - do you know the players will be watching at the right time and so see what you want them to see? You can pick a random token side manually (place a multi-image token on the board and selet a random side), but you need the API to be selective about which side to pick (exclude the first face).

It's the metamanca-danca-palanza-extravaganza! ... ...this part was supposed to have dancers, a whole entry number... ...nothing? *sigh* I'll just have to do it myself. Just imagine the dancers. They'd make it much more impressive. So. TokenMod can select the side, and Roll20AM or possibly SimpleSound can play a sound. ZeroFrame can batch everything up and delay the next change of sides until the sound has finished (provided the length is stored somewhere we can access). Either ChatSetAttr or Muler can store our remaining available sides, probably Muler since we're already in the deep end of the meta pool... and MathOps has a randb() function that returns a random entry from a provided list. Plugger also has a filter() function, which we'll need... and APILogic has the IF/THEN logic to let us test when we're done. Just talking it through, then, it would look like (feel free to skip over the part formatted as a quote, meet me after for some questions)... We start with a list of available sides to choose from. Given the images in the original post, that means 1, 2, and 3 (by whatever 0-basing or 1-basing offset we need to perform, we can pick from the images that have the 1, 2, or 3 on them). Those are written to a Mule variable (we'll hand-enter them, but you'll probably want a "Reset" ability macro to reset all of these entries so you can do it again). When you click the "Change" ability macro, we use a Muler get  statement to return the list of available entries to the MathOps ranb() function. In that way, the available options become the set of options randb() can choose from. We filter  the Muler-returned list (using Plugger's filter() function), then  rewrite the Muler variable with a set statement using the filtered result. We use the value we selected in a TokenMod statement to pick the new side. If there is a standard sound associated with every change (the same sound for every change), we play it. If, on the other hand, there is a specific/different sound associated with each side depending on what is chosen, then we use the value we randomly selected to look up, in another Muler variable, the sound file to play. If it's a static sound, we know the length of the delay; if it's a different-sound-per-side arrangement, we use the same value to look up the delay from another Muler variable. Whatever that delay is, we then have the original "Change" ability macro call itself on that delay. Which means we'd need APILogic running first off in the Change ability macro, to initially test our conditions. Only if the conditions are right (ie, there are still sides to choose from) do we let the rest of the macro run. So, some questions... Do you have a different sound for each face, or is it always the same sound? How does the loop end? When there are no more faces to choose from? Is there also some other way to stop it (some game mechanic like the character pushes a button to lock in the current status)? What happens when it reaches the last face if no one has stopped it? Does it start over? Does it disappear? I'll see what I can get started, but let me know the answers to those so I can hit closer to the mark before I'm done. ...high-steps behind curtain, stage left...

I have some api like token mod The only face that is excluded from the "random roll" it the starting face from step 1 No faces get get used up, all but the starting one are available each time it's rolled The loop ends when it picks a random face It would only be the one sound that plays before the random face is rolled, but the sound isn't necessary I can live without it. the sound was more ambiance than anything 

If I understand you, there really isn't a "loop". There's one set of commands, one time that the face changes. You just need to not let it go back to the original face. I was confused when you said that the next macro would need to be delayed... That made it sound like a loop where the command would repeat (being the thing you want delayed). Now I think you're saying you just want the next macro delayed no matter what it is ... It could be anything that anyone else might try to do and you want it delayed. If I'm right, then you won't be able to wholesale delay everything (whatever could come next). We could delay a specific command line, but delaying the whole sandbox (and the chat interface and anything that might come from a character sheet, etc) is impossible. However, the good news is that if I now understand what you want, everything else becomes very, very simple to do. Much simpler than I thought initially. Let me get a working model together... But tell me if I still am misunderstanding anything.

I had forgotten the purposes of the various random functions in MathOps, so forgive that I initially referenced the randb() function. That is the "random between", which we won't use. We'll need either the randa() function (the "random among"), or the randib() function (the "random integer between"), depending on how you build it. So, here are a couple of options of the command line you would need to use to have the token switch to any other side than the first. The first requires TokenMod and MathOps to be installed: !token-mod --set currentside|{&math randa(2,3,4)} Notes: that will affect the selected token. It will also only swap between faces 2, 3, and 4. If the token happens to have more than 4 sides, you won't get the higher numbered ones unless you alter the command line to include them. For a better option in that case, read on. The next option requires TokenMod, MathOps, ZeroFrame, and Fetch (v2.0.8, pending in the one-click or at my repo , now), as well as the supporting scripts that get installed from the one-click: !token-mod --set currentside|{&math randa(2,@(selected.sidecount)+1)} Notes: this one also affects the selected token. However this time, we take into account the total number of sides on the token at the time the command is run. (We add 1 because of how javascript generates random numbers -- inclusive of the lower boundary, but not including the upper boundary). Since we have an upper and a lower range, we'll use the randib() function instead of the randa() function. This version of the command line is a little more hands-off, since you don't have to update it if the number of sides of the token changes... or if you want to use the same command for a token that has 4 sides, then use it on a token that has 15 sides. It will still work... you just have to select the token you want to affect. Notes 2: You can change the Fetch syntax to refer to a token by name or ID instead of "selected". Using this in conjunction with a TokenMod --ids argument can change the above command to work with a different token than the one you have selected. You could, for example, build it to target a single token no matter what you have selected (using the exact ID of a token). Or you could build them both to refer to a @{target} statement, so that both Fetch and TokenMod would now look to read and affect the token you clicked on as a part of the targeting resolution. The last option requires all of the scripts mentioned in the previous version (including the latest Fetch), as well as SelectManager: !forselected(^) token-mod --set currentside|{^&math randa(2,@^(selected.sidecount)+1)} {&select Obelisk*} Notes: This would be a good form if you had a number of these tokens that you wanted to affect, and they all needed to change at the same time, but each to a random value. TokenMod can change multiple tokens at once, but without the forselected iteration, the tokens would all be set to the same side. In this case, I'm imagining that all of these multi-face tokens are named some version of "Obelisk01", "Obelisk02", etc. The select statement will get all of the tokens answering that wildcard formation on the current page, and feed them into a forselected iteration sending a unique TokenMod command to each to get your new side showing. The above options get you settled on a random side from the token. For the sound, that would be a Roll20AM or SimpleSound implementation that you can easily pair with any of the above. Those are not my forte, but someone else should be able to chime in to help get you the correct command line to play the sound you want. That sound-playing command line can be paired with one of the above command lines (in succession) to get both to fire... though sometimes there is a bug where Roll20 drops a command line. If you find that is an issue for you, we can get around that with ZeroFrame quite simply. Just post back with your finished command line (with both the TokenMod command and the sound command) and I'll show you the modification to make.

Wow Thank you so much