Suggestion: Automatic interruption for unspoiled nodes

[jponryParticipant]

I know you guys are focusing on more important features right now, and this is a rather big change that will take a lot of time, but I think in the future this would be really useful for gathering + scenario writing 🙂 This is a bit of a long post as I tried to think in detail of how the feature would work, as well as how to avoid issues.

Images are also provided as attachments in case the links don’t work.

I will say outright that this might require gather presets to have a new “aetheryte” setting so that Miqo will know how to get back to where she started.

REASONING:
Currently, when I’m writing a scenario that involves gathering multiple items, I have to add a lot of workFor/workUntil conditions if I need to get unspoiled nodes, like so:

teleportIf(REGULAR NODE LOCATION)
job(BTN)
gatherPreset(PRESET)
workUntil(23:50et) //stop for 12 AM node
gather(999)

teleport(UNSPOILED NODE LOCATION)
job(MIN)
gatherPreset(PRESET)
afkUntil(01:30et) //wait for GP to replenish + cordial to come off cooldown
waypoint(9)
sendKey(8, 2.5) //use cordial just in case GP is not full
workFor(00:00:20) //must specify this or else miqo will say "work time is over" and skip the node
gather(1)

teleportIf(REGULAR NODE LOCATION)
job(BTN)
gatherPreset(PRESET)
workUntil(04:00et) //stop halfway between last node and next node
gather(999)

teleportIf(REGULAR NODE LOCATION)
gatherPreset(PRESET)
workUntil(07:50et) //stop for 8:00 AM node
gather(999)

teleport(UNSPOILED NODE LOCATION)
job(BTN)
gatherPreset(PRESET)
afkUntil(09:30et) //wait for GP to replenish + cordial to come off cooldown
waypoint(9)
sendKey(8, 2.5) //use cordial just in case GP is not full
workFor(00:00:20) //must specify this or else miqo will say "work time is over" and skip the node
gather(1)

And this must be repeated for both AM and PM versions of the node.
This can be difficult when trying to write more intricate (and/or human-like) scenarios, not to mention taking up extra chapters for the AM/PM versions. Also, if you only have one regular and one unspoiled node you want, you have to write a scenario for it, you can’t use the regular gathering feature.

SOLUTION:
Basically, I imagine an addition to Gathering Presets, where you can tell Miqo to stop for an unspoiled node (or multiple, perhaps with a maximum limit so as not to overwhelm her!), and you can specify whether you want her to stop for AM, PM, or both. Behind the scenes, I’d imagine Miqo would use code similar to the workUntil()/workFor() functions — which, of course, would still exist for other uses in scenario writing, it’s just that this is abstracted from the user in cases of unspoiled nodes.

As far as linking those unspoiled items to actual presets, I imagine on the preset screen, the user can choose between “Interrupt for the following nodes” or “This is an unspoiled node”, similar to how they can choose between a rotation or a macro.

POTENTIAL ISSUES (+ solutions):
Obviously, the first thing that comes to mind is people trying to link different items to unspoiled presets (i.e. Raw Onyx to the Lemonette setting) and making a mess of things. I imagine this could be mitigated by hardcoding various settings of the unspoiled item in question. So, if the user selects “Lemonette” in the drop-down menu, “Gather By Name” is locked to “Lemonette”, and it has a specific aetheryte to teleport to (can’t be changed). That way even if the user supplies the wrong grid, Miqo just won’t be able to gather anything (probably throw an error like “Oh no, I can’t figure out how to get to the node! I guess I’ll just go back.”). If the user has not specified a preset to go along with the chosen unspoiled node, Miqo will throw some kind of “Preset not found” error and either stop or refuse to start gathering.
The other thing I can think of is Miqo having to deal with concurrent nodes. I think, other than simply not allowing it, she could have a “queue” of sorts, i.e. “go here, gather thing, go here, gather thing, go back”.

If you have read this far, thank you for listening 🙂
And thank you Miqodevs for all of your hard work! I hope this all made sense.

Attachments:

You must be logged in to view attached files.

[NekroParticipant]

If I understood correctly you basically want to have a hook like function, to react to specific conditions in your scenario. So you can interrupt your current activity on a specific time to do something and then return to your old task.

I think your solution would be a little bit too specific and hardcoded to really be worth the effort taken to adjust the gathering presets. As the tabs like fishing, gathering, crafting etc. are there for a single task I guess. For everything else you have Scenarios.

In my opinion a new Scenario function would be better. I already suggested (and some others have too) the possibility to call specific chapters in a scenario from within a scenario (basically like functions, you can call everytime and everywhere you want).
A variation of that with an function like hookTime() would prove quite helpful not only in your case, but possibly in more cases like the old unspoiled nodes from Heavensward/Stormblood or others in the future aswell. The function would work like this:

hookTime(Scenario-Unspoiled-Node-8AM, 08:00et)
hookTime(Scenario-Unspoiled-Node-1PM, 13:00et)
hookTime(Scenario-Unspoiled-Node-4PM, 16:00et)
teleportIf(REGULAR NODE LOCATION)
gatherPreset(PRESET)
gather(999)

So it adds a condition which is periodically checked (like every second or so?) and once it matches a condition, the hook triggers the Scenario mentioned in the argument.

Lets first just assume that the hookTime() function returns to this Scenario and the same Chapter it was called from, but in the end it might need a system like the current koCheckpoint() mechanic where you can tell miqo which chapter she can re-enter on, once the linked Scenario was executed. Also it needs at least a limit how much you can nest those hooks, as in theory you could create a recursion of Scenario-Calls.

Thats just a rough idea, but would be probably more flexible and more useful in general. Also there could be more hooks in the future like hookWeather() which I would love to see, instead of the current skipBadWeather() function, cause it’s still executing the line under it for a minute, even if the weather is not good. Thats a bit clunky to use in my opinion.

• This reply was modified 3 years, 11 months ago by  Nekro. Reason: wording, more specific examples

[LyfoxParticipant]

This looks great but i imagine it will be hard to develop a system like this without bugs. A scenario generator would be easier and more reliable in my opinion. Miqocrafter by Shishio Valentine does something similar: https://miqobot.com/forum/forums/topic/miqocrafter-craftinggathering-full-scenario-generator/

[jponryParticipant]

Nekro wrote:

In my opinion a new Scenario function would be better. I already suggested (and some others have too) the possibility to call specific chapters in a scenario from within a scenario (basically like functions, you can call everytime and everywhere you want).
A variation of that with an function like hookTime() would prove quite helpful not only in your case, but possibly in more cases like the old unspoiled nodes from Heavensward/Stormblood or others in the future aswell. The function would work like this:

hookTime(Scenario-Unspoiled-Node-8AM, 08:00et)
hookTime(Scenario-Unspoiled-Node-1PM, 13:00et)
hookTime(Scenario-Unspoiled-Node-4PM, 16:00et)
teleportIf(REGULAR NODE LOCATION)
gatherPreset(PRESET)
gather(999)

So it adds a condition which is periodically checked (like every second or so?) and once it matches a condition, the hook triggers the Scenario mentioned in the argument.

I actually like this idea better! Seems like it would be much more flexible and expand Scenario capabilities immensely 🙂

[MiqobotKeymaster]

This feature would be an extension of a more basic mechanism – the ability to call scenarios recursively.
Such algorithm would require an implementation of call stack which is a rather complex mechanism in itself. We will look into this when we start working on new Scenario Engine functions.

Please keep in mind that this system will occupy a full development cycle and may be implemented only at the cost of other features. But we will try our best.

[TetsuyaParticipant]

would it be an option to replace the scenarion engine by someting like lua scripting engines?

sure, the effort on the first side is high to very high and it will break all existing scenarios, but after this you only have to care about functions and return values, and not on the runtime/scriptingfeatures itself.
Then users can create more complex scenarios and can use subfunctions, interrupts, hooks etc

[VixenParticipant]

The idea behind the current scenario engine was that it shouldn’t need the user to really know anything about programming, to make it more accessible. I very much doubt that a full-fledged scripting language engine will be implemented for it.

[MiqobotKeymaster]

Yes, Scenario Engine was designed with simplicity being a priority in order to allow players to understand it and access its features easily.
Replacing it with a programming language would eliminate this concept.

[TetsuyaParticipant]

not at all, thats why I suggested Lua. As language itself it is very powerfull, but can also be as functional as the current system.
But yes, as developer i can understand it totally. But some interrupt or bypass functions would be great in the scenario engine. Change scenario step depends on weather for example for automated diadem fishing 🙂

[MiqobotKeymaster]

All right, we will consider your suggestion for the future development.
Thank you very much.

In any case, better Diadem support is one of the things planned in Gathering Updates. We will try to design special functions for weather-based decision making. Once we find a suitable solution, it might be possible to generalize it for time-based chapter selection as well.

[jponryParticipant]

I am asking purely for curiosity — is there the possibility of if/elseif/else blocks in Scenario Engine’s future? Or if not that complex, perhaps a jump command for moving between chapters? Thank you 🙂

[MiqobotKeymaster]

jponry wrote:

I am asking purely for curiosity — is there the possibility of if/elseif/else blocks in Scenario Engine’s future?

For the reasons mentioned above, creating complex mechanisms usually available in programming languages is not a priority.
But if there is enough demand and the community decides that it justifies postponing other features, the development plans will be adjusted.

jponry wrote:

Or if not that complex, perhaps a jump command for moving between chapters?

Yes, special functions for switching chapters and scenarios without a call stack should not create additional complexity and are already planned.

[Author]

Posts