A way to post 'next item on the list' with just a button click?

So I have  a whole month's weather in a drop down querry, like this /em ?{Weather| August 1 Light air (1) towards South-West with Thick Haze (10 km) | August 2 Light breeze (2) towards South-East with Haze (20 km) | August 3 Gentle breeze (3) towards East with Rain (2 km) |    End, End} I have an excel sheet to generate the random weather and preformat the list for a Roll20 macro, so I just copy-paste it in. But it takes time to find the right day in the drop-down list. Any way to automate this so that at a click the next day's info gets posted in the chat? I considered using a roll table, but it's rather tiresome to enter every day as a seperate entry. Preferably it should be just one copy-paste action to add another month's weather.

An API script can certainly handle that. Something might already exist, but if not it wouldn't be difficult to knock together from the weather data & an example template output.

Drop it into a Mule (Muler script), and include an iterator variable. To do it right, you'd need ZeroFrame and SelectManager, at least... possibly MathOps or APILogic if you wanted to make it really dance. The idea is every time you click the "advance" button, the iterator is incremented and the new variable is retrieved. So let's say your mule (an ability on a character) was named "WeatherConditions", and it was on a macro mule character named "MuleBoy". That mule would look something like: WeatherConditions 0=August 1 Light air (1) towards South-West with Thick Haze (10 km) 1=August 2 Light breeze (2) towards South-East with Haze (20 km) 2=August 3 Gentle breeze (3) towards East with Rain (2 km) day=0 maxdays=2 Then you could do a "CurrentWeather", "AdvanceDay", and "ResetDays" set of abilities on the same MuleBoy character. CurrentWeather !&{template:default}{{name=Current Conditions}}{{Day get.MuleBoy.WeatherConditions.day/get=get\.MuleBoy.WeatherConditions.get.MuleBoy.WeatherConditions.day/get/get}}{&mule MuleBoy.WeatherConditions}{&simple} AdvanceDay !{&if get.MuleBoy.WeatherConditions.day/get <= get.MuleBoy.WeatherConditions.maxdays/get}{&template:default} set\.MuleBoy.WeatherConditions.day=[\][\]get.MuleBoy.WeatherConditions.day/get + 1\]\].value/set {{name=Current Conditions}}{{Day get\.MuleBoy.WeatherConditions.day/get=get\\.MuleBoy.WeatherConditions.get\.MuleBoy.WeatherConditions.day/get/get}}{&else}/w gm {&template:default} {{name=End of Days}}{{Last Day Reached=You have reached the last day of generated weather. Do you want to reset your day iterator?%NEWLINE%[Reset](~ResetDays)}}{&end}{&mule MuleBoy.WeatherConditions}{&simple}{&0 get, apil, set} ResetDays !&{template:default}{{name=Days Reset Successfully}}{{=Current day has been reset to 0.}} set.MuleBoy.WeatherConditions.day=0/set{&mule MuleBoy.WeatherConditions}{&simple} In Action In action, that would look like: CurrentWeather AdvanceDay (repeated) ResetDays Scripts Required For this solution, you'd need Muler, ZeroFrame, and APILogic. Further Expansion You could, if you wanted to, convert your spreadsheet (that generates the random weather patterns) into Mules, too, and then have an ability macro that creates the various "WeatherConditions" variables. Your "ResetDays" macro ability could then have a second option to "Generate New Weather" that would run that ability. If you want to go down that path, post back.

timmaugh said: - Thank you. How would the first macro look without a template? I tried to strip it down, but couldnt get it to work that way.

The CurrentWeather ability/macro would look like this if you took it out of a template and just wanted plain text: !/w gm The weather for day get.MuleBoy.WeatherConditions.day/get is get\.MuleBoy.WeatherConditions.get.MuleBoy.WeatherConditions.day/get/get{&mule MuleBoy.WeatherConditions}{&simple} It has to start with an exclamation point to trigger the API. Since we want text output we include the {&simple} . (The template was also a chat output, so we had a {&simple} then, too.) We get the current day (the iterator variable) like this: get.MuleBoy.WeatherConditions.day/get And since the weather we pull to report comes from that iterator variable, we have to defer the resolution of that get one time: get\.MuleBoy.WeatherConditions.get.MuleBoy.WeatherConditions.day/get/get The backslash breaks up the detection of the first get, so it is the second that is recognized during the first pass. Does that make sense and/or let you dissect the other macros?