Forum Replies Created
-
Posts
-
I’m fully aware the current state of assist is absolutely not optimised, and don’t take into account new abilities, or if it does, it’s only through some temp fix. So, it is in full knowledge of those facts that I’m doing those feedbacks, and I know that most of the things (if not all) I’m gonna bring up are known to you developers, I’m still doing it in the rare case I would actually have found something relevant.
Indeed, the combat system is not even remotely optimized for endgame raiding. It’s quite surprising that you found it useful in the current state, considering that job rotations were significantly downgraded by the arrival of 5.0. Thank you for the detailed feedback very much!
There’s one thing I would really love we get, it is an ON/OFF green/red “light” on Miqobot window itself, just for those who don’t want to use the overlay Pause Status feature, and prefer watching Miqobot on a secondary monitor.
All right, this should be possible. Thank you for your request!
The reason I’m bringing this, despite knowing it happens now just because Assist is not finished yet, is because I want to know if you’re going to allow her to triple weave, or never, or in rare occasions by taking into account the extra delay it would add before the next Iron Jaw GCD, so that she’s sure she won’t attempt it if she sees she will fail refreshing the DoTs.
To my knowledge, there’s still only one very rare case where triple weaving is not a DPS loss with BRD, but I’m trusting you fully when it comes to numbers, and if you find other cases.In the most optimal setting, triple weaving should never occur.
The general rule that Miqobot follows is to allow oGCD if there’s more than 50% of GCD timer left. However, some abilities do not follow this rule:
– Pitch Perfect. Because clipping was the easiest solution to ensure that procs are not wasted. It must be optimized and aligned with GCD.
– Empyreal Arrow. Because Miqobot still considers it a weaponskill and tries to fire it immediately after Barrage.
With these two issues addressed, there should be no more triple weaving. If you encounter any other cases, please let us know.One other reason I’m bringing this, is that for example I pentamelded two thirds of my set to lower my skill speed a lot, and I was wondering if it was something Miqo was taking into account when she calculates the time she have left before she needs to apply the next DoTs refresh, especially when into Minuet we get now the 10 sec Skill Speed buff of Pean, making suddenly the most busy song for procs a hard place for double weave with high ping, and this is precisely where right now she misses most of the DoTs refreshes.
Varying skill speed should not be a problem, because we use the same system for Ninja and Monk. Clipping issues will be extremely noticeable on those jobs, so they will be addressed accordingly in the endgame optimization stage.
I remember you told me that for now, since she wasn’t finished, she was going to miss some DoTs refresh, that it was expected, but my concern is gear wise (skill speed) and ping wise. Should I be worried with a 165-175ms ping? I have a datacenter close to me, 20ms, but unfortunately this is not the one on which I play, most of the times though, I don’t clip when I double weave.
In general, high ping environment should not cause any significant issues, as long as there are no occasional lag spikes of 220+ milliseconds.
We will be researching this question once again when we start working on endgame optimizations.When I switched to manual for the clear, I noticed I ended up doing 8 GCD more than her, the amount I believe she lost with clipping on a 13min45sec fight.
We believe that this problem is caused by GCD not being queued by Miqobot.
The queueing algorithm is still not implemented and Miqobot activates an icon only when it is fully charged. This results in additional delay of 20-30ms on each GCD. With 250+ GCDs in total this indeed accumulates to the number of lost GCDs you mentioned.So, I believe you already planned this, but just to be sure, for those, it would be useful to have individual boxes we can check to tell Miqo if we want her to handle them or not, instead of removing their keybinds.
Of course, this is the first customization we will implement when we start working on endgame support.
You will be able to enable or disable any weaponskill or ability directly in Miqobot, without any hotbar or keybind manipulations.And this bring me to a following question, about Nature’s Minne, when we feel it’s okay to let Miqo handle it on cooldown. How is it going to be handled in the end when set on auto, will we have an option in Miqo to set which number of the party member we want it to be used on? Or Miqo will be able to recognise a Nature’s Minne macro, in which we would already have set up the party member number? Or can she sees who’s currently tanking within the party, and distribute Minne accordingly?
Miqo is quite fantastic when it comes to switching to party members as healer, it would be great if she could not rely on a macro for Minne, as those are really awful to trigger.Yes, Miqobot is capable of detecting the current main tank. And yes, it won’t be a problem to utilize the same targeting system as healers do.
Precise customization of Nature’s Minne will be also implemented in the final cooldown planning toolkit.Subsidiary question, would it be possible to manually queue some oGCD we set up to use manually? If we don’t want to fight with Miqo, and avoid making her clip when we use something manually, could we tell her we want her to use a specific oGCD as soon as she sees she has a safe window for it, either by having her recognise we pressed it with the game keybinds (and it didn’t triggered), or being able to set keybinds for those directly in Miqobot?
I really don’t want you to have to create such a system if it turns out to be a lot of work, I’m just putting in there in the case you would find the idea useful and not time consuming.This is one of the problems we don’t have a definite solution for at the moment.
As we constantly test Miqobot in different environments, we fully understand the issue you describe. Detecting a manually attempted ability and queuing it for the next GCD cycle could be possible, but we have to research it further.Miqobot saves your license code in catnip.license file in encrypted format.
Do you see this file being created next to your Miqobot application? If not, then something is blocking Miqobot from creating and managing her files.Please try the following solutions:
- Verify that the folder that Miqobot resides in is not restricted for write access.
- Move Miqobot to a different folder.
- Run Miqobot as administrator.
- Verify that your antivirus does not prevent Miqobot from creating files.
Might be an idea to let us use own navigation grids or behaviour coding for boss battles just like current behavior. Just looking at current way squadrons are implemented with checkpoints and bossbattle flags it doesn’t seem like a stretch to just let the community build those scenario’s for eachother.
Similary with the rotations and optimization of combat. Adding an additional layer on top of the base skills currently where priority lists can be implemented with some logic can be of great improvement for the future.
Yes, these feature are already planned.
Rotations and Dungeons Customization are already in the list of next features: [Beta] CombatOk, here goes. Other users might find it useful too (if you ignore backtrack issue) – it’s leveling BTN 56-60 with collectables on Birch place in Clouds.
We have experimented with your grid and haven’t encountered anything unnatural.
Would you please clarify, which beacon does Miqobot backtrack to and under what conditions?BLM also has a horrible rotation now, guess we gotta wait for an update on the rotations 🙂 <3
As we mentioned a few posts earlier, BLM rotation is optimized for levels 1-66 only.
Please refer to the main status thread for detailed information on all jobs: Shadowbringers – Miqobot StatusNew rotations will be implemented in the next update.
Then I have no idea why does it backtrack to a beacon just visited… I can attach the grid which produces this bug if that helps.
Of course, any additional information will help us identify the issue faster.
Weird %) I’d just add a single variable to store number of last gathered slot (1-8), which is reset to zero once node is fully gathered. This way bot can perform GP check only in case variable holds 0 (i.e. we didn’t gather anything from the new node yet), otherwise it should stay on the last gathered slot unless it disappears (and then it shouldn’t perform GP check anyway – just take the next “no {} brackets / no rotation” item name from the list.
Thank you for your contribution very much. We will implement it after all critical issues are fixed.
I’m sorry… any chance you clarify it a bit? Did you mean it’s implemented in the current release, and I’m just doing something wrong (what exactly)? Or that it’s implemented, but not released yet?
It’s implemented in the current release. You can find the detailed explanation of the beacons rotation algorithm in your thread: General gathering problem (HW/SB only)
Hmmm why? If an item disappears – then you more “cursor” to another item; though, my idea is that you never move “cursor” because current amount of GPs changed (i.e. no GP checks except for before the very first hit)!
The current algorithm has no rule to move cursor. At each moment it evaluates the required gathering slot based on the current environment and settings. It does not have any memory of a previously gathered item. Therefore in order to address this issue, we will have to redesign this feature from the core.
Any luck with it? Just to remind: it was a bug where Miqo does weird backtracks once ephemereal node (not connected to the grid) appears. Just encountered it again using another grid…
Yes, we’ve managed to reproduce this issue, albeit only once.
It seems to occur under very rare circumstances and is related to loading processes in the game memory. We need more time to investigate it.I. Once Miqo flies through a beacon (no matter if it is used as a beacon or not), beacon should be marked as “visited”. Later it should choose next unvisited beacon. Of course, in case of star-like grid with just a single “central” beacon it should still fly to this beacon, no matter if it’s “visited” or not.
This solution is already implemented. Please note that the beacon is only marked as visited when Miqobot flies directly through it. Alternative routes in close proximity do no count.
it moves cursor to collectable item and… starts to gather completely useless items as non-collectible, without starting the rotation (well thank goodness: at least it does not waste GPs).
Possible fix: rotation GP check should never be performed once gathering of current node is started. You hit an item = you gather this item until node is totally gathered, no matter of new GP.
Yes, we are aware of this problem. The solution you proposed, however, will not work due to the existence of rare items which disappear from the node after one hit. It requires a more careful algorithm.
The effect of not wasting GP is a result of the solution we implemented earlier when this issue was discovered. In order to address it completely, we will have to redesign this feature from the core. It will be done after all critical issues are fixed.I´m having issues with Ingenuity II on my LTW.
When it´s active it often completes the craft without doing much quality, didn´t have that problem on other crafters as far as I remember.Miqobot has not yet adapted the new crafting math and may indeed miscalculate progress under certain conditions. Especially if you are using Ingenuity.
Please refer to the main status thread for detailed explanation: Shadowbringers – Miqobot StatusIf you are not satisfied with the current state of Crafting Solver for any reason, please consider resorting to macro crafting for the time being.
Does the BLM rotation not include Flare AOE? I’ve noticed that when I was doing assisted Trusts in the 71 dungeon, it never does Flare.
At the moment BLM rotation is optimized for levels 1-66 only. Flare is used as the last spell in Astral Fire phase and does not account for level 68 trait.
Please refer to the main status thread for detailed information on all jobs: Shadowbringers – Miqobot StatusNew rotations will be implemented in the next update.
As we stated in the main status thread, Miqobot was not tested with 71+ content and may perform unpredictably. Especially if you are using Ingenuity.
Please refer to this thread for detailed explanation: Shadowbringers – Miqobot StatusIt will take some time before Miqobot adapts the new crafting math.
If you are not satisfied with the current state of Crafting Solver for any reason, please consider resorting to macro crafting for the time being.Miqobot is designed to support all game client languages, including Japanese.
Would you please give us more information about your issue?1. Show us a screenshot of your settings on Gathering tab.
2. Show us the message log from the Output Area. (Starting from “Hello! I am your Miqobot!”)The more information we have, the faster we’ll be able to help you.
Our developers have verified your information and unfortunately we couldn’t reproduce your problem.
The Beacon of Passage is identified and displayed without issues.- Please verify that you have enabled the necessary settings on 3D Radar tab.
- Please verify that you have enabled Beacon of Passage identification in Advanced Settings of 3D Radar.
If you require additional assistance, please contact our Tech Support directly: https://miqobot.com/#support
We would recommend to read our guide on Keybinds and Icons Recognition in order to understand how Miqobot operates with your hotbars.
Our Tech Support can analyze the hotbars and identify the exact cause of your issue.
Please contact us directly and we will do our best to help you: https://miqobot.com/#support
