[MiqobotKeymaster]

Nott wrote:

Everything you said makes sense but I wonder why I sometimes see it putting CZ as the first step when I never disable progress first?

Comfort Zone is applied only when the estimated number of steps is more than 10 and neither of them will be blocked by the lack of CP.
In order to estimate number of steps, Miqobot looks into the future and evaluates the rotation under several luck scenarios:

• With a lot of Good / Excellent conditions.
• With some Good conditions.
• Without Good conditions at all.

In the dimension that has no knowledge about Inner Quiet and Great Strides, it may result in the number of steps being less than 10. For example, if you encounter several Excellent conditions CP will be burnt faster than usual.
But if all scenarios are safe in the “Progress First” dimension, Comfort Zone will be applied on the first step.

You are correct, recipe durability does affect the estimation algorithm but this is only one of the factors.

[MiqobotKeymaster]

Both of your questions are easy to answer.
Please note that they are not related to the original post about Stroke of Genius.

1. When there is no Inner Quiet active, using quality actions would be a waste of CP and Durability.
   So when an early Good condition pops at max CP, there are two options:

   – Ignore it and continue the opener normally.
   – Use Tricks of the Trade and continue the opener normally.

   Both options do not affect the opener, but the second one switches condition back to Normal and extends the total number of steps. This choice gives one more opportunity to encounter a Good condition later when we can actually utilize it.

2. Delay of Comfort Zone is a price we have to pay for certain optimizations.
   When you enable “Progress First” optimization, Miqobot splits internal logic in two dimensions:

   – The first dimension has no knowledge about Progress bar.
   – The second dimension has no knowledge about some CPU expensive actions like Inner Quiet, Great Strides, or Comfort Zone.

   Both dimensions are solved independently from each other and the final solution is constructed at the post-processing phase by merging different dimensions. The actions that were sacrificed in the second dimension must be weaved into the opener, but it is impossible to do so with 100% efficiency since neither dimension knows their true place.
   This method results in a significant computational boost at the cost of slightly suboptimal rotation.

   According to our calculations, this optimization reduces average HQ rate by 3%.
   Depending on recipe difficulty, it will result in x3-x20 computational boost.

   If you need the +3% HQ rate increase, please disable “Progress First” optimization.
   It will allow Comfort Zone to appear 1-2 steps earlier in the opener.

[MiqobotKeymaster]

In order to answer your question, we have to dive a little into the technical side of the game.

When you enable “Limit FPS when client is inactive”, the resulting value is 3-4 times lower than the maximum allowed FPS.

• If the game is capped at 60 FPS, it will be limited to 18 FPS when inactive.
• If the game is capped at 30 FPS, it will be limited to 11 FPS when inactive.
• if the game is capped at 15 FPS, it will be limited to 8 FPS when inactive.

Since Miqobot doesn’t use code injections and doesn’t take away your mouse, she can only control your character with keyboard.
Low FPS in combination with high camera speed result in fragmented movement which is very hard to control. It may cause some extreme behavior wherein Miqobot is unable to aim the camera at specific angle, because that particular angle is being skipped between frames. And if it happens several frames in a row, Miqobot will get stuck continuously jolting camera up and down.
This behavior falls under the definition of “something went very wrong”, and therefore must trigger a kill switch.

You can easily reproduce this problem in the following way:

1. Set Camera Speed (Keyboard) to 100.
2. Set FPS limit to 15.
3. Enable “Limit frame rate when client is inactive”.

Now create a new scenario in Miqobot and try this:

vangle(-0.8)
vangle(-0.4)
vangle(-0.2)
vangle(0)

Did Miqobot manage to align the camera correctly at each angle or did she get stuck at one of the functions?

The settings in this experiment are of course beyond the critical threshold and you would never use them during normal gameplay. However the problem is of random nature.
In other words the closer your settings are to the critical threshold, the more likely this problem will occur. Depending on FPS and camera speed it may indeed take many hours of uninterrupted performance before it finally happens.

We apologize for the long and technical explanation, but it’s the only way to answer your question about why it happens only sometimes 🙂

[MiqobotKeymaster]

Thank you for your answers.

Yes, the settings you use are dangerously close to critical values.
Miqobot can function at 10-15 FPS, but this is the bare minimum at which game performance starts to cause problems. In addition, your camera speed is set to 60, which is twice faster than the default value of 33. Was there any specific reason for this setting to take place?

We will give an explanation about why it happens in the next post, but first let us give you a solution.
In order to avoid this problem, please use the following settings:

• Frame Rate Limit: 60 FPS
• Camera Speed (Keyboard): 33

This will ensure that Miqobot gets at least 18 FPS when client is inactive.
You may also increase camera speed up to 40, because this is the default setting used by our developers.

[MiqobotKeymaster]

Thank you for reporting!

We have analyzed the message log you provided and managed to identify the problem.
There is only one function in the navigation module which triggers a kill switch after exactly 20 seconds. It’s the vertical camera alignment function.

After every navigation sequence Miqobot tries to restore the vertical camera angle to roughly 15 degrees above eye level. In your case she failed to do so for 20 seconds which is extremely long for a simple camera rotation, so she decided that something went very wrong and triggered a kill swtich.

Would you please answer the following questions:

1. What keybinds are assigned to actions “Point Camera Up” and “Point Camera Down”?
2. What value is assigned to camera speed in Character Configuration settings?
3. At what FPS do you usually run the game with Miqobot?
4. Do you experience game stuttering from time to time?

[MiqobotKeymaster]

Thank you very much!

Indeed, Miqobot attempts to make an 80 progress step but in reality it turns out to be 81. This case is almost identical to the one described in our primary Crafting Guide.
We will use the data you provided and try to improve the internal formulae for Crafting Solver.

The easiest workaround in your case is to remove Rapid Synthesis from the hotbar until the next level up. This will allow Miqobot to use Careful Synthesis II earlier in the synthesis and learn its true value before it’s too late.

[MiqobotKeymaster]

Thank you for reporting!

Do you remember what keybinds you had assigned to actions “Move Cursor Left” and “Move Cursor Right” before reset? These are the actions that Miqobot uses to cycle through nearby NPCs and it looks like she had an issue with them.
The default ones are set to NUM4 and NUM6.

[MiqobotKeymaster]

Yes, this is a known issue which happens for some unique combinations of crafting level, craftsmanship value, and recipe difficulty.
It is described in details in our primary Crafting Guide.

As you already mentioned a temporary workaround is to slightly alter the input parameters, such as equip different gear, temporarily remove Rapid Synthesis from the hotbar, or simply level up.

The issue is impossible to fix completely, because the true crafting formula is evaluated server-side and therefore is unknown.
But we improve the internal formulae used by Miqobot with every new version based on the data our users provide.

Would you please enable crafting logs in Miqobot and send us the output for analysis? The more data we have, the better algorithm will be in the next version.
An example of what we need can be found here: Crafting Solver Miscalculates Progress

Thank you for your assistance very much!

[MiqobotKeymaster]

Miqobot v1.3.13

Download Miqobot Beta

A rare issue is addressed.
– Fixed an issue wherein a boss battle would sometimes not finish when an ally NPC enters the arena.

[MiqobotKeymaster]

Yes, the system you describe is already implemented for battle navigation 🙂
You can find screenshots of upgraded navigation grids we use for combat in the development section: Combat | Development

After the core battle system is stabilized, it will be adapted for common navigation as well.

[MiqobotKeymaster]

Yes, the purpose of obstacle correction algorithm is to get around unlucky camera angles which can happen quite often.

Since Miqobot does not use code injections, she can not force a specific enemy to be selected instantly. And sometimes even the perfect line-of-sight camera alignment results in the target being slightly obscured by a tree or terrain decoration. You may have experienced this during normal playing as well, when the game simply refuses to select the enemy you need for unknown reasons unless you move the camera slightly left or right.

In the case discussed earlier, however, the problem is not related to obstacles.
Miqobot tries to target an enemy which existed for a fraction of second due to temporary data corruption. That enemy is the Goblin Pathfinder NPC now, so the game does not respond to “Target Nearest Enemy” action which results in a logic deadlock.

We expect many issues like this one in the future, because implementing a truly stable system requires evaluating a tremendous number of rare cases.
So please keep providing feedback, it helps us identify them faster.

Thank you very much!

[MiqobotKeymaster]

Thank you for providing the requested information!

We have investigated the problem and it appears to be caused by temporary data corruption in the game memory, which occurs when the Goblin Pathfinder NPC enters the arena. We are already working on a solution but it’s not an easy issue to fix, so it will take a few more hours.
We apologize for inconvenience.

[MiqobotKeymaster]

Thank you for reporting!

Unfortunately after several hours of testing we couldn’t reproduce your issue.
Based on your description, it seems that Miqobot was trying to fight a monster that was outside the arena for some reason. In this case, however, she had to discard the battle mode automatically and navigate further before re-engaging. But without any message logs it’s very hard to understand what exactly happened or how to avoid this in the future.

Next time you encounter this issue, please take a moment to copy the message log in a text file for further analysis.
Thank you very much!

[MiqobotKeymaster]

Yes, if there is enough demand for this 🙂

For now, the main priority is to eliminate the tedious grind of leveling battle jobs.
But of course, if many players are interested we will continue to improve Miqobot until she is capable of going through the highest levels of PotD / HoH and clearing Savage raids.

[MiqobotKeymaster]

Miqobot v1.3.12

Download Miqobot Beta

A critical issue is addressed.
– Fixed an issue wherein Miqobot would not recover after KO events when using Scenario Engine.

[Author]

Posts