Scenario scripting – essential features and general design philosophy

[VixenParticipant]

The scenario scripting engine was designed to be as close to idiot-proof as possible. It’s supposed to be easy to understand and use for anyone, including people who have never so much as dabbled in computer science before. The whole idea was that anyone should be able to write a scenario, not just programmers. But did that go too far?

The main issue with the scenario engine scripting language (which I’ve taken to calling miqoscript) is that it’s too restricted. There are no provisions for conditionals, so you just have to make sure that you start in the correct state every time. We have rudimentary loops that allow executing a chapter a set number of times, but what about when one individual parameter needs to change between runs? If you want to craft ten each of, say, five different items, you have to copy and paste.

I’m not advocating the implementation of a full-on programming language, that would be beyond excessive, not to mention counter to the stated goal of keeping it simple enough for anyone to use. But I am suggesting that miqoscript needs to be extended to include features considered basic and essential for any scripting language.

Idea #1: implementing “blocks” as chapters
Using chapters instead of extending the syntax to allow for in-chapter blocks would keep miqoscript more accessible, at the cost of increased “chapter bloat” from each additional block. I think that, given Miqobot’s stated desire to make scenarios easy to use for everyone, this is a fair tradeoff.

Currently, scenarios progress from the first chapter to the last, sequentially, with no way to jump from one chapter to another. The only flow control is to repeat a chapter or the entire scenario a given number of times, or to repeat a chapter for/until a certain time. Additionally, functions that set options or parameters for future actions (such as setCraftRecipe()) may (but also may not!) reset back when the chapter ends.

If this functionality were standardised to not reset (perhaps offering a function to reset on demand if necessary) and functions were added to jump to given chapters and return back to the jump point (for those familiar, see AutoHotkey’s gosub/return combo) then a chapter could be written to, for example, set a crafting recipe, jump to a chapter that applies food/medicine, does the crafting, and optionally (for collectibles) turns them in, then jump back again, set a new recipe, and continue. At present, the only way to accomplish that is to copy and paste the whole block, then change the recipe lines.

As a secondary to this, a function to stop executing the scenario would also be useful, so as to prevent falling through from one chapter into the “subroutine” chapters that are called from it. Alternatively, a chapter jump at the end of the “main” chapter could skip over those to an end chapter.

Idea #2: “random choice” jumps
There are currently two functions to move to a random waypoint on the current navgrid, but what about when you get there? Outside of very specific circumstances, you’ll probably need to adapt your actions to wherever you end up. But there’s no way to even check which point you ended up at. To that end, I propose that perhaps instead a function to jump to a random chapter would be more useful (when combined with the ability to afterward jump to a particular (constant) one to avoid executing all the following chapters) because you could then write a chapter for each point you want to be able to randomly move to and add specific actions to take after moving there. Additionally, you would be able to select a random course of action not involving movement if you so desire.

Idea #3: conditionals
This one would probably be the most difficult to implement, and it would also be important to decide what conditions will be exposed and how. Testing how much gil you have or what class/level you are would probably be easy, but what about testing for minimum item counts? Or location?

This one would probably be best done with an extension to miqoscript’s syntax, honestly. The only alternative is that a separate function be made for each condition, and that wouldn’t allow for arbitrary multi-factor complex conditionals. Being able to test if a single condition is true would be useful, but still very limited – what if you need multiple conditions to be true in order for a particular course of action to work? To that end, while the single-factor simple conditionals could be easily added as if<Condition>(chapterIfTrue[, chapterIfNotTrue]) (and would simply continue the current chapter if the condition is false and no second chapter is given) I instead propose a somewhat python-like condition syntax. Grouping could be done via parenthesis or whitespace, but conjunctions would be english and/or/not (and possibly xor for advanced conditions) rather than the symbolic &&/||/! that many programming languages use. Equality and inequality could be left with the mathematical symbols.

Given the near-requirement for syntactic extension, this is also the most abstract feature recommendation/request that I have. The above can all be implemented as some form of function call with the existing syntax, but this would be best implemented some other way, and for that I have no detailed ideas.

I want to make it clear that the scenario engine is a fantastic feature, and as far as I’ve seen one that’s unique among XIV bots. I’ve been using Miqobot since before it was even implemented, and I was very excited to hear about it. I love the idea, but in terms of current usability, I feel it needs some work. These are simply my suggestions/requests as a user of the bot (and, admittedly, a programmer) and I am absolutely open to discussion on all of them, from the devs and from the other users.

[MiqobotKeymaster]

We never stated that Scenario Engine was restricted on purpose.
As with any other feature, we implement new tools in order of their complexity. And it just so happens the tools easiest to implement are also easy to use.

There are many improvements planned for Scenario Engine, including the ones you described.
Technically speaking, nested function calls and conditions are the only elements that separate Scenario Engine from creating formal algorithms by definition. And we will be progressively adding new elements as long as there is enough demand.

There are only two problems that everybody has to understand:

1. The more complex a feature is, the more time it takes to implement.
   If we start working on nested function calls or conditions support, it will be the only feature added to Miqobot during the next several months.

2. The more complex a feature is, the less players will be using it.
   Each of the elements discussed here is objectively an improvement. However, only players with programming background will utilize them to create new scenarios. As we have seen many times, non-IT players experience problems when simply using finished scenarios, not to mention making modifications.

Therefore in order to start working on these features, we have to make sure that they are in demand and that this decision is supported by the majority of Miqobot community.

Vixen wrote:

Additionally, functions that set options or parameters for future actions (such as setCraftRecipe()) may (but also may not!) reset back when the chapter ends.

This behavior is standardized as follows:

• If a function changes a UI setting, it does not reset the value after chapter ends. Resetting such values may conflict with user actions, such as adjusting UI settings on the fly.
• If a function is an extension and does not have a corresponding UI setting, it resets the value after chapter ends. Leaving such values in memory without any means to reset them outside of special scenario functions may lead to unpredictable behavior and extremely elusive bugs.

[VixenParticipant]

I may have been less clear than I thought, I didn’t mean that miqoscript is “restricted” by design. IIRC, one of the goals of it was that users shouldn’t need to be programmers to use it, hence the relatively simple syntax. Thank you also for the explanation on the function resets!

As for the rest, I understand both points, although I hadn’t been paying enough attention to see the issues people tend to have with writing/using scenarios as-is. I expected each of these ideas to be complex to implement alone, and it’s nice to have a better idea of how long it’ll take. This topic was partially to post my suggestions/requests to the dev team, but also to open discussion among the community about those ideas. I’m hoping to hear responses from other users to see what people think… although I may have written a bit much for casual users to bother reading.

[dermParticipant]

Whats missing most for me personally is:
– runChapter(4), a way to skip chapters within a Scenario
– runScenario(Name), a way to run different Scenarios within a Scenario and then go on with the original Scenario.
I realize that there is conflicts with workFor() for example but the option of having a library of small Scenarios and being able to call them basically like functions would be amazing.
– being able to move the Scenarios within the list in Miqo. “Right Click/Move Up” or something?

I mean in a perfect world i’d like to be able to define variables etc but “small improvements” would be nice to have QoL tweaks.
And i’m not trying to hate just raising my hand to show some interest. Still love the bot 🙂

[shinya kogamiParticipant]

if anyone can make Miqobot have inherent functions already built in so we “casuals” do not have to find and import tons of scenarios etc. It would make this bot more popular and will be happy to pay even more each month.

Im just coming from a new player and newbie perspective – it is not easy to understand what this bot can do and how to make it do stuff. First day was spent researching and trying stuff with a lot of headache. I can say that after around 24hrs of fiddling with it – I am slightly more comfortable using Miqobot to perform tasks like auto crafting items and gathering. But I have not explored the tons of scenarios yet as I am just starting out.

I probably cannot understand or get working full fledged scenarios even if I import them because the language is way too complicated, just saying if Miqobot had more consideration for the newbie players – who just wanna sub the bot press a few buttons to get working without having to fiddle around the forums etc it will be even more popular. thx.

[Author]

Posts