This topic contains 7 replies, has 4 voices, and was last updated by 
Lyfox 3 years, 1 month ago.
-
Posts
-
Hi,
i have a little improvement request to miqo’s navigation.
Background is that i try to create “most possible human like”-grids for gathering.
My branch distance in these cases is 5 or lower and place a waypoint above the gathering node.
These waypoints are connects a lot and it is working all fine, miqo moves human-like 🙂But there are two problems:
1)
The waypoint-accurancy threshold is sometimes strange because it is to high.
For example if i place a waypoint on X20 Y20 Z20 miqo moves to X18 Y16 Z4.
This is a litte problem because sometimes i’m “fly” in the ground and can’t unmount.
tbh i’m not even able to reproduce it by hand, it just happens when using miqo.
My question is: is miqo using an accurancy threshold?
If yes you may can add a way to modify it in the settings? (e.g. “normal, “most accurate”)2)
Miqo’s pathfinding for shortest way seams only to include the number of nodes to move by.
I dosen’t include the length of individual connections.
This cases a problem because miqo’s shortest way is not always the shortest.an extreme example as image:
is there any way that you can add a way to include connenction length to miqo’s pathfinding?
Hakuna Matata
Would be nice, and other form of beacon check would be nice. That the bot travels to nearest beacon and i wish a function that the bot only go to a higher Waypoint Beacon. When the bot is on waypoint 5 and there is beacon waypoint 4 and beacon waypoint 6 the bot will travel to beacon 6 everytime ^^
have a nice day
1)
The waypoint-accurancy threshold is sometimes strange because it is to high.
For example if i place a waypoint on X20 Y20 Z20 miqo moves to X18 Y16 Z4.Yes, this is correct.
The algorithm was never designed to arrive at the exact XYZ point every time, because without code injections this is impossible. At low FPS, your character would be constantly spinning back and forth without ever stopping at the requested waypoint. In addition, the movement pattern would become extremely unnatural, because common players never arrive at the same XYZ coordinates.
Miqobot always targets the vicinity of the destination, but never the destination itself.My question is: is miqo using an accurancy threshold?
Yes, the accuracy threshold is approximately 2.0 meters.
Your example, however, does not fit this threshold. If you instruct Miqobot to arrive at (20; 20; 20) then the worst possible arrival would be (18.75; 18.75; 18.75) but not (18; 16; 4).If yes you may can add a way to modify it in the settings? (e.g. “normal, “most accurate”)
At the moment the only way to adjust it is via goToWaypointPrecise() function. It reduces the accuracy threshold to 0.5 meters, but only for the duration of the function. This is a scenario function, therefore its usage is rather limited.
Of course, we can implement an additional setting to adjust it globally as well. But this may result in extremely unnatural motion as described above.
Are you sure this is the only solution to your problem?2)
Miqo’s pathfinding for shortest way seams only to include the number of nodes to move by.
I dosen’t include the length of individual connections.Miqobot always calculates the length of path by the distance traveled. The number of waypoints is irrelevant.
If you experience a different behavior, then it’s a bug.Would you be able to create a navigation grid that reproduces the case in your example and export it for analysis?
Would be nice, and other form of beacon check would be nice. That the bot travels to nearest beacon and i wish a function that the bot only go to a higher Waypoint Beacon. When the bot is on waypoint 5 and there is beacon waypoint 4 and beacon waypoint 6 the bot will travel to beacon 6 everytime ^^
The beacon navigation algorithm is already implemented this way.
Miqobot traverses beacons in increasing order of their waypoint numbers.
For example, if beacon A is #3, beacon B is #7, beacon C is #11, the order will always be:A -> B -> CThis way you are always in control how you want Miqobot to visit beacons, regardless of linear distances, navigation path distances, or unidirectional connections. If you wish to change the traversal order, all you have to do is delete beacons and recreate them in the preferred order.
The only time distance calculation takes place is the moment you click “Start”.
At this time Miqobot detects the closest beacon and rotates the sequence to make it the first to visit. But the order remains unchanged:B -> C -> AIn addition, if Miqobot visits a beacon implicitly while navigating from one gathering node to another, it still triggers a sequence rotation. This rule is designed to prevent occasional backtracking when the next gathering node is visible directly on minimap and the beacon is not used.
If you have any other ideas for AI improvement, please let us know.
Of course, we can implement an additional setting to adjust it globally as well. But this may result in extremely unnatural motion as described above.
Are you sure this is the only solution to your problem?Well, no. Currently im rising the height of the waypoint to avoid this, but i’m often land way to low on waypoints so i have to adjust them. The X and Y is never a problem. So it feels like there is a problem with Z threshold but i can’t verify it.
Miqobot always calculates the length of path by the distance traveled. The number of waypoints is irrelevant.
If you experience a different behavior, then it’s a bug.… or a problem on my side. I wanted to create a example grid and found the problem
It looks like 433 is connected to 432 and 434 but it is’nt. causing miqo to take a connected (long) way.If you have any other ideas for AI improvement, please let us know.
just an addition: fly beacon’s would be nice. last time i tried them causing to go to ground every time.
Hakuna Matata
I would be interested in a force beacon.
In the Diadem i have some routing problems.
This is the overview of the route
When i gather at waypoint 19, then after i finished the node at Waypoint 38 or 39 will appear a node. Now the the bot will route to the node on waypoint 38/39 and try to follow the route arround the map.
When the bot hit the beacon at waypoint 21 it will not stop to scan again the area it will go straigt to waypoint 38/39. Now i have two solution.
Solution 1:
Make a scenario and let it gather until this point and will route to the waypoint x and let it start again gather until i have the problem again. Problem is every time i call the gathe function it will reload the grid and big grids need much time to load. This is a big time lost.Solution 2: I will follow the Bot scanning scheme until the bot do not find a nearby node and then use beacon to route it to the next node. This is not the most efficient route and involves a loss of time.
When i could force the bot to scan the area again when it hit a waypoint with a beacon that would be great or a method to call the gather funcion without reload the grid all the time. So i can use the scenario solution.
It would be great too i could set scanning range of the miqobot, then i could work more with beacons without get routing problems
Why not split the big grid into smaller ones? Its much easier to edit them and they load instantly. I have 6 grids in my scenario for each mini route. Works perfectly.
You get all nodes in the order or you skip any nodes? I need all materials in the same quantity because i want to craft it with all my crafter. Would be intrested how you doing it
My scenario is flexible. It lists all nodes within each mini route and i can easily toggle them on or off depending on what i need at the moment. It looks like this.
grid(Diadem1-8) waypoint(11) gather(1) waypoint(15) gather(1) waypoint(20) gather(1) ...The first chapter covers 8 nodes in total. The next chapter sets grid(Diadem9-16) and covers the next 8 nodes. And so on. Ive actually described this structure a while ago so ill just quote myself if you dont mind.
Well since diademBoom() is a scenario thing i think the best approach is to split the whole grid in separate chunks and work on them separately. When you enter Diadem theres one miner node spawned directly to the right. And it spawns the next 8 nodes in a chain. So you can start by mapping these 8 and restart Diadem. Then make a separate grid and start mapping from #9 which is also spawned on your immediate arrival. Then the third grid and so on. The whole Diadem can be split into six grids.
Grid 1: #1-#8
Grid 2: #9-#16
Grid 3: #17-#24
Grid 4: #25-#32
Grid 5: #33-#40
Grid 6: #41-#48Im using the old botanist map for reference but the idea is the same: https://www.reddit.com/r/ffxiv/comments/fhb5be/advanced_guide_to_diadem_farming_map_of_all_nodes/
Once you finish a grid you make a separate chapter for it with diademBoom() in the end. It probably doesnt change much if your goal is a complete Diadem map. But it makes things easier to manage in my opinion.
So i have 6 chapters with 8 nodes each. Its basically the same as farming unspoileds but without afkUntil(). No compass and no beacons needed. Miqo just follows my grid and farms it exactly how i want. Easy and fast.
You must be logged in to reply to this topic.