This topic contains 1,142 replies, has 259 voices, and was last updated by 
Miqobot 2 years, 4 months ago.
-
Posts
-
Found another gathering bug/feature… Say, there is a grid which covers gathering spot which consists of 3 groups of nodes, 3 nodes per group: 1a, 1b, 1c, 2a, 2b and so on. There are beacons between each pair of groups. Say, beacon A is placed after group 1, to cover all nodes of group 2; beacon B is placed after group 2, etc. Now there are two possible scenarios:
1) Either node 1c or node 2a did not spawn. Then Miqo either gathers 1a and 1b (neither of group 2 nodes are visible from 1b), or it gathers first node of group 1 plus 1c (neither 2b nor 2c are visible from 1c), so it flies to beacon A, notices nodes of group 2, gathers them, finds no more nodes and proceeds to beacon B: everything works as intended.
2) Both nodes 1c and 2a spawn (does not always happen, but still happens). Miqo gathers first node of group 1 + node 1c, and instantly notices node 2a. It flies to 2a through beacon A, but it is not used as actual beacon – rather, used as a common waypoint. In gathers 2a and then another node of group 2, and… backtracks to beacon A, because it’s not marked as “visited”, most probably (as opposed to going to beacon B, which is the closest to nodes 2b and 2c).Possible fixes:
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.
II. Miqo should always choose the nearest unvisited beacon (if any).===========================
Plus there is another bug. Say, my collectable rotation requires 600 GP. With not enough GP (and no scenarios) Miqo does not use rotation, but rather gathers something else. Now let’s say it started to gather with 599 GP. The first hit on non-collectible item brings 5 GP, now Miqo thinks it has enough GP to use collectible rotation, so 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.
-
This reply was modified 4 years, 8 months ago by
Gray.
Hi,
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.Here´s a log from trying to craft Sea Swallow Leather with Level 75 and Ingenuity II:
—CraftLog opened—
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Solver DONE: 12242.5321 ms
Step 1. Recommended skill: (Initial Preparations)
Step 2. Recommended skill: (Tricks of the Trade)
Step 3. Recommended skill: (Comfort Zone)
Step 4. Recommended skill: (Inner Quiet)
Step 5. Recommended skill: (Careful Synthesis II)
Step 6. Recommended skill: (Tricks of the Trade)
Step 7. Recommended skill: (Ingenuity II)
Step 8. Recommended skill: (Steady Hand II)
Step 9. Recommended skill: (Tricks of the Trade)
Step 10. Recommended skill: (Rapid Synthesis II)
SUCCESS-
This reply was modified 4 years, 8 months ago by
Ark.
Hello again Miqo!
Love using this, just have a bit of a concern I just discovered:
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. It is on my bars, and I haven’t changed my configuration. It does the single-target rotation even during times where I know it should recognize it as AOE. My BLM is still 71 so I know it shouldn’t be doing the advanced AOE rotation unlocked by the 72 traits, so just wondering if it’s Flare itself that’s not supported yet.
For comparison, I went to do a low-level dungeon (non-squadron) and during AOE pulls Miqo uses Fire II correctly.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.
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.
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?
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.
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)!
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.
It’s implemented in the current release. You can find the detailed explanation of the beacons rotation algorithm in your thread: <span class=”d4pbbc-underline” style=”text-decoration: underline;”>General gathering problem (HW/SB only)</span>
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.
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.
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.
But oh well, you could have did it yourself already if it was that easy, hehe…
-
This reply was modified 4 years, 8 months ago by Gray.
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.
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.
Not expecting this to be done this expansion, but perhaps something for the future. I’d love to make some dungeon grids and boss battle logic.
Of course, any additional information will help us identify the issue faster.
Ok, 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.
-
This reply was modified 4 years, 8 months ago by
The topic ‘Shadowbringers 5.58 – Issues & Feedback’ is closed to new replies.