Forum Replies Created
-
Posts
-
setSquadronFullClear( on / off )
Set “full clear” setting for squadron dungeons.
The change will be reflected on UI.Allowed values are:
– on / off
– 1 / 0Aliases
squadronFullClear
fullClearParameters
on / off – new value of settingExamples
fullClear(on)
fullClear(off)———————-
Set it to off and it will ignore coffers in Squadron Dungeons.
Miqobot doesn’t really use “rotations”, she has algorithms that make her analyse the situation to pick the best available ability. So there’s no place where you could find what she does.
So the best way to learn your job with her, is actually to first sort your hotbars in a meaningful way for you, and then watch her play against a striking dummy, then take her in a real dungeon with other players, and watch her play her role, then re-sort your hotbars if needed.
The more you watch her play, the more you’ll learn from her, it’s a precious tool.
It might be because currently Miqobot doesn’t have a queuing system for GCD, she uses them as soon as they’re available, without queuing them first.
The devs are currently working on implementing a queuing system into the Combat Assist, this is a very promising feature, that will turn Miqobot into a real player behaviour, while increasing DPS.
-
This reply was modified 5 years ago by
Carl Arbogast.
This is a complex known bug, and there’s a workaround, you have to cast manually something, anything, even Return, and Miqobot will work again.
It happens under very rare circumstances due to a bug in the game client, which allows the Cast Bar to remain active (albeit invisible) if it is interrupted by a cutscene, a loading screen, or in another non-standard way.
In addition, another bug may occur randomly wherein the Cast Bar would indicate that it’s not interrupted and is still proceeding normally.
When both of these bugs occur at the same time, it affects Miqobot’s ability to identify the Cast Bar correctly. She assumes that a cast is still in progress and therefore does not attempt to perform another action.In order to recover from this problem, all you have to do is initiate the cast manually once. It doesn’t matter what ability to cast, even a simple Return will work. You can immediately interrupt it by moving.
The purpose of this action is to trigger the normal behavior of the Cast Bar, which will allow Miqobot to identify it properly once again.As this issue is extremely hard to reproduce, it will take some time for us to design a proper solution.
In the meantime, if you encounter this problem again please use the workaround described above.There is another workaround.
You can create two hotbar manipulation macros. One will remove AoE abilities from your hotbar and the other will quickly put them back.Miqo, Miqo, Miqo, thanks again for taking the time to answer, that workaround is quite good, I feel stupid I didn’t thought about it. I just used it flawlessly for 3 hours, going forward and back, pun intended.
This is actually possible thanks to your code, where we can completely mess with things, and the bot just never crash, always pick up and adapt. I would expect the bot to crash if I change some icon in the hotbar while it’s performing, or if I change keybind in live, but no, she always pick up and adapt immediately. That’s not job rotations, it’s jobs solvers, we abused the language one too many times.
I think I requested that already a very long time ago, when you guys Miqobot devs just started to share your plans about a future combat system, I asked if you we could get a feature to switch from single target to AoE manually.
I requested this way before you created such a cool automated AoE system where Miqobot detect on her own enemies in range and switch alone to AoE, making her so accurate and efficient.
I wasn’t expecting you guys to create such a useful system, I thought we would have to switch on our own manually.This system is fantastic, but, I know I don’t teach you anything, there’s still moments where we would need to turn off momentarily AoE, to prevent killing/damaging targets where fight mechanics require to handle them in a specific way, such as the current new Alexander Ultimate, where players must take care of linked dolls without killing them, as well as taking care of keeping the Living Liquid and Hand Liquid within the same HP percentage, etc.
Miqobot is too efficient there, she destroys everything, it’s beautiful, but deadly. And if Alexander is later anything like A8S, I see where we would have to handle the 4 robots by keeping each of them at different HP percentage in the same area.I know nothing is easy, and that you likely had that planned already for the Raid features, but since Miqobot already knows how to do AoE and Single target, if it is possible to implement in advance a feature similar to the Pause one, where we can set up ourself a keybind to go from Default (the current mode where Miqobot herself choose when to use AoE) to a forced Single Target mode, that would be awesome.
I realise we’re asking too many things currently, and I think I know you guys prefer to add features in the right order, but I thought it worth a shot to ask, in case it turns out more or less easy to implement, but I really know nothing is easy.
In the mean time, I’ll continue proging Ultimate while turning on and off Miqo when necessary, she’s a blessing for this prog, the mechanics are so difficult to unscramble and puzzle out that being able to focus on sight-reading every clue, save hours.
It’s like they want it to be easier to bot.
It’s hard to figure what are the real goals of FFXIV devs.
I remember what I thought when 2.5 years ago I saw they were adding crafting abilities in Stormblood, on top of all the Heavensward ones, I thought that it look like FFXIV devs were pissed that somewhere creators of a bot managed to engender an ultimate solver, a real one, despite the complexity and computing required.
I thought they were so pissed, that their solution was to come up with more abilities, more branches, more possibilities, to kill the process Miqobot devs were using by making it unsolvable in a timely manner. Yet Miqobot managed to adapt.And so this time it’s weird to see FFXIV devs “giving up”. Of course it’s weird only if in the first place we think their choices for SB and ShB were influenced in some way by Miqobot, which is something we can only speculate on.
Nevertheless, funny evolution.
Maybe then you will find useful this quote from Miqobot in 2016:
The day when Miqobot will be able to clear end-game without supervision will probably be the day when machine becomes equal to a man 🙂
It was right after Miqobot announced combat features (DPS Solver, Enemies priority list and new 3D radar) in development along Raid support for this purpose:
According to our preliminary research, this feature should tremendously reduce the amount of stress imposed by end-game raids.
It was in a topic talking about the possibility of a Roll Solver where Miqobot presented an analysis of Square Enix systems, and how it was indeed possible to predict the roll, but that the cost of the implementation of such a feature was close to the price of a space station.
Since no user agreed upon raising the Miqobot monthly fee to several millions dollars, Miqobot came up with an alternative solution, known today as the Combat Assist.There is a reason to why this myth exists.
In theory, it is indeed possible to predict the outcome of a random roll.
But in practice, it would take some tremendously expensive equipment which is comparable to spaceships in price.The root of this myth is that random numbers in games are not random.
They are pseudorandom.It means that Random Number Generator uses a clearly defined pattern which is built in such a way that it looks random to an outsider. The simplest generators can be defined with a single formula:
Xn+1 = (214013 * Xn + 2531011) mod 232
This gives a sequence of numbers X1, X2, X3, …, which seems very random but in fact it is not. And yes, of course it is calculated server-side.
Final Fantasy probably uses more complex algorithms, but it’s not the only obstacle here.
The main problem is that random numbers are generated in enormous quantities.For battle, every single hit is randomized (+ or -).
For monsters, their idling behaviour is randomized.
For crafting, lots of abilities have a success rate, and it’s randomized.
For gathering, every hit on the node is randomized.The list may go on. Considering that all the players are doing all these things together at the same time, the ingame RNG must be producing more than 1,000,000,000 numbers per second. And in order to be able to predict them, we’d have to calculate even faster.
Basically, in order to implement the RNG solver, it is required to:
Find out the exact formula that game server uses. At the very least, we could purchase the source code from game developers themselves.
Connect to the server hardware and take readings of server processor cores – in order to determine the current state of RNG. This would probably require a direct channel and some sort of API provided by game developers.
Perform calculations at a rate faster than RNG does. Preferrably around 1,000 times faster. Which brings us somewhere in the range of supercomputers.So as alluring as this idea sounds, unfortunately we have to set this request aside.
But still, thank you for bringing up such an interesting topic 🙂P.S. In order to solve the problem with grinding Lanner Mounts, we are planning to implement a Raid Grinding Bot.
It will require a very complex AI, and probably a lot of testing.
But this way, nobody will have to cheat 🙂-
This reply was modified 5 years, 2 months ago by Carl Arbogast.
Triple triad is rng and the games are fast, theres no reason you cant play that yourself.
if you want triple triad stop trying to argue the usefulness of each and go make a triple triad thread because youre not changing my mind here.
Fair enough, I will end it by just telling you that for some NPCs, it can take beyond 30 hours of non-stop game to get the drop you want, this is beyond sanity, way beyond, and this bot was created to remove those insane mind numbing grinds from the players.
And Triple Triad never ends, there’s always new NPCs and cards added, new achievements added, new rewards added, that’s the reason why users are never done with it, it’s always relevant and useful.I apologize if you felt I kidnapped your thread.
-
This reply was modified 5 years, 2 months ago by Carl Arbogast.
Miqobot will use Battle Voice only when all your party members are in range of its effect.
That’s an excellent feature, particularly useful in current Eden 03 Savage, when the second BV gets available, half of the party is out of range, being on the opposite platform, and so far Miqobot was wasting this BV there on half the party, which was the reason why I was using it there manually during Week 1 of Eden Savage prog.
Now it means that Miqobot will trigger it only when the middle of the arena is available again, and that the party meets there. Really good feature.The first attempt to implement the GCD queueing system is planned after the next version release. But if this attempt is not successful within a reasonable time frame, it will be pushed further into the future. We will make no promises at this moment, but we will do our best.
This is excellent news, I hope your first attempt will cause you guys the least trouble possible, as I said it before, I take this as no promise at all, just a tentative and appreciable transparent information.
When it comes to scheduling expectations, we always recommend to consider only the features available today. If the ETA is crucial to your project, then please do not expect the GCD queuing system to be released at all. We sincerely apologize, but at this stage of development we are not ready to take on additional responsibilities.
You gave me exactly the kind of information I was looking for, I’ll put my project on hold, I now know there’s some slight tiny little chance I might be able to do it soon enough, and some chance I might have to push it back indefinitely, this helps me to manage different projects I have with FFXIV, thank you.
Queuing is a nice DPS increase, but it also goes beyond its DPS utility, that’s why this is such a good feature and why I’m glad you’re trying to implement it, considering what you achieved in the past already, I have lots of faith in you, and if it doesn’t work out, then so be it, not the end of the world, to the impossible, no one is bound.Triple Triad support is not asked by Miqobot users for MGP gain or tournament, it is asked because unlike LoV it get updated in FFXIV in every patch, and people want a way to collect rare cards from NPCs, some have drop rates so low, it’s a real pain and a waste of player time to farm them, and it never stops, it’s always updated and relevant.
No one feature a LoV bot, because it isn’t really useful when you think about it, SE abandoned it, and it’s truly a big game in a game, so much that it cost to SE a huge amount of development time for little return. It’s a really complex game, many rules, many variables, it’s not a Gold Saucer mini-game, it’s a full game, this would indeed require a long and complex development, for again little return.
I strongly recommend for people after the challenges, rewards and achievements, to consider using Arc or clementxd method, and to find a friend (or dual box) to win trade. It doesn’t take long, and after that LoV has nothing left to offer (other than being an interesting game to play without a bot).
That update definitely was worth the wait.
I usually never ask for any ETA, but I just find myself in a project that I need to schedule around a Miqobot future feature, the combat abilities queuing system.
What I’m looking for right now, is to understand where the combat abilities queuing is currently schedule, like is it for the update right after the first Trust dungeon update, or right after the update featuring all level 80 abilities, or even later during raid support updates?I’m not looking for an exact date, just something I could use to estimate if there’s a chance to see it released in a month, or two, or before the end of 2019, or before 5.2 in February. And I know that any rough estimation should only be taken as tentative, not as any promise, priorities can shift, etc.
I’m trying to understand if that queing feature is a challenging one to code, or a normal milestone in the continuous combat updates.
It’s the feature I’m waiting the most currently, and any rough estimate would help me to schedule my project accordingly.
Thank you
-
This reply was modified 5 years ago by
