Changelog

What we shipped,
and why.

Every BotDaddy release in plain English. Updates download automatically in the background — just quit and relaunch to get the newest version.

v1.4.10

Latest

Viking Rise 1.5.160, and the three releases before this one that never got notes — healing without opening a screen, and the bug that was closing your game every few minutes.

Viking Rise updated, which moves the addresses BotDaddy reads and would otherwise park every account. This build follows it, and fixes the one thing the update changed that the bot could not have guessed: collecting the friendly troops on the village map is a direct action now rather than a march, so Clear Villages would have kept sending marches that go nowhere. Three earlier builds went out without notes, so everything they carried is written up here too — most importantly the crash that was closing the game roughly twenty times every ten minutes, and healing your wounded troops without a screen.

Viking Rise 1.5.160

A full game update moves the internal addresses BotDaddy reads, and an account whose game is newer than the version we have checked is parked rather than run on guesses — that is deliberate, because a wrong address does not fail loudly, it returns a believable number. This build is checked against 1.5.160 and raises that ceiling. The check itself got better in the process: it now compares every class's methods as well as its fields, which is the only way to notice a function that keeps its name and quietly gains an argument — exactly what broke things last time. The result this time was unusually clean. Five addresses moved, every one of the three thousand four hundred and fifty-four fields we read stayed exactly where it was, and nothing the bot uses disappeared. If you are still on an older game version nothing changes for you; the bot supports both.

Clear Villages: the friendly troops are collected directly now

The village map has friendly troops standing about waiting to be collected — the ones beside the dragon lair gate the Dragon Cave. Collecting one used to mean sending a march at it and waiting for the march to arrive. The game changed that to a single direct action, and it arrived for most people as a quiet in-game patch rather than a full update, so this affects you whether or not your game says 1.5.160. Without this build Clear Villages keeps sending marches the game no longer accepts and those troops never get collected. It now collects them outright: no march slot spent, no walking, no waiting. Three of the four conditions it used to check before going were about whether a march could reach the place, and none of them applies any more — tested by hand on a real account, troops were handed over in regions marches cannot enter and before the fight that used to gate them. It still refuses to ask for one it has already collected, and if a collection does not go through it says which of the three things went wrong rather than going quiet.

The IGG Account button changed on fresh installs

Install the game fresh on the new version and the IGG Account button on the Switch Account screen is drawn differently — white icon and bold white text where it used to be dark. Update into the new version instead and you keep the old button. Both are out there at once, so this adds the new artwork rather than replacing the old one: an account that has been running for months is unaffected, and a freshly installed one can get past the login screen again. If you have been setting up new instances on the new version and watched them stall at Switch Account, that was this.

The game was closing every few minutes — v1.4.8

Reported as "the game keeps closing on all instances and it's an insane amount of errors", and the report was right about everything except the cause. Over two hours and sixteen minutes there were two hundred and six game deaths across thirty-one of thirty-four instances, at a flat rate of about twenty every ten minutes. It was the command BotDaddy uses to point the camera at a building. That command had been passing one argument short for months and getting away with it because the game never read it; the game update on 21 October started reading it, and from then on the command killed the game instantly — two hundred and sixteen times out of two hundred and sixteen. Every single outage had it as the last thing that happened. It is fixed, and it now takes that argument from the game itself so the same thing cannot happen on the next update. The suspected culprit when it was reported — the new character and IGG switching — was innocent: it ran five times, and thirty-one of the thirty-four affected instances never used it at all.

Healing wounded troops without opening a screen — v1.4.9

Healing used to mean flying the camera to the infirmary, finding the card, opening the page and walking the screen. It is a direct action now, and it does three things the screen version never did. It answers in one step on an account with nobody wounded, where the old way paid a camera flight and a page open to learn the same thing. It collects troops whose healing has already finished — nothing in the bot had ever done that, so finished troops sat in the queue instead of going back to your army. And it asks your alliance for help, which is free and shortens the timer. One account healed a hundred and twenty-eight wounded troops, asked for help and returned them all to the army in a single pass. It deliberately does not try to predict what a heal will cost: the game's own prices move with your buffs, so it asks, reads what was actually spent, and if the account cannot afford it the old screen path takes over and tops up from your inventory exactly as before. It will never spend Gems.

Use Buff works again, and without a screen — v1.4.9

Two things here. Use Buff had stopped finding the Buffs tab after a game update moved the artwork underneath it — the buttons look identical to the eye, which is why it took scoring the old and new pictures against a frame from before the update to prove it rather than argue about it. That is recut. Use Buff also no longer opens the inventory at all: it checks whether the buff is already running and uses the item directly. The check matters more than it sounds. A resource-gathering buff can be running from three sources at once on a developed account, two of them permanent, so the obvious question — is this kind of buff active? — answers yes forever and would have skipped every buff you own. It asks about the specific buff instead, and will not burn an item replacing one that is already ticking.

Resource Transfer stopped re-deriving something it already knew — v1.4.7

Reported from a real transfer: the account flew to the recipient, then worked out where it was all over again — once on arrival and once on the way home. Measured on the account that reported it, that was fifty-six seconds of a twelve-minute pass and forty camera moves, spent recomputing a number the bot had been handed as it set off. It was invisible in the log, because the expensive version left no trace — it showed up only as a twenty-second silence between two unrelated lines. It uses the number it already has now, and only works it out again if that number turns out to be wrong.

The relocator now matches the ground it is aimed at — v1.4.7

Relocating for a transfer picked a tile and then fired whichever relocator came first, and the game refuses a Territory Relocator aimed at neutral ground and a Fixed Relocator aimed at your alliance's. The switch to choose between them existed and nothing had ever set it, so its default decided every relocation the feature had ever made. It now asks which kind of ground the destination tile is on and uses the matching item. It also stopped telling you an item had been used when it had not checked — the two cases read differently in the log now, so "the relocation failed" and "the relocation failed and it cost you a relocator" are no longer the same sentence.

Why Train Troops was refusing on some accounts — v1.4.8

A barracks with nobody assigned to it does no work, and that is what was refusing the training on accounts with full stockpiles, every barracks at level 25 and hundreds of thousands of troops. The bot had been reading that refusal as the account's troop limit being full — a limit the game does not actually have, which is worth saying plainly because it sent people hunting for a cap that does not exist. It reads which buildings have a worker on them now and says so: "no Worker assigned to the barracks". The fix is yours to make in the game, but the message at least points at the right thing.

v1.4.6

Two new actions — Mercenary Guild and Distant Voyage — and Clear Villages stops marching away from fights it was winning.

Mercenary Guild buys instant troops from your village and Distant Voyage takes the day's free gift; neither one opens a screen. The fix most of you will feel is in Clear Villages, which could decide a fight was lost while its marches were standing on the target swinging at it. Resource Transfer can now move the sending city next to the recipient before it starts, which is where almost all of a transfer pass's time goes.

New action: Mercenary Guild

Your village's Mercenary Guild offers a handful of deals a day, each one 250 soldiers with no training time at all, and you get four hires a day. One pass reads today's board, works out what each offer costs this account, and hires every one it can pay for, cheapest first — so a thin stockpile still completes as many of the day's four as it can. No screen is opened and nothing is tapped. There is nothing to configure either: the board is rolled once a day and there is no reroll to buy, every hire gives the same 250 soldiers whatever it costs, and whether you can afford one is arithmetic the bot already does. A hire runs about three times what training the same soldiers costs in resources and buys back all of the training time — that trade is the whole feature, so switch it on only if you would rather spend resources than wait. The Guild has to be unlocked once per account by beating the Mercenary Leader on the village map; until that is done the action says so and skips, and it will not go and fight him for you.

New in Dailies: Distant Voyage

A new tick box in the Dailies action. It sets out on the day's free voyage and takes one of the two gifts it brings back, without opening a screen — which is why it runs first in the Dailies sequence, where nothing it does can disturb the screen walks underneath it. It always takes the first of the two gifts: the second is the one the game offers to sell you, so nothing here will ever spend your Gems. On most passes the day's voyage is already taken, the action does nothing and says so, and that is the normal result rather than a problem.

Resource Transfer can move the city next to the recipient first

About 92% of a transfer pass is marches flying, so the largest saving available was never inside the action — it was the distance. Resource Transfer can now relocate the sending city onto a free tile beside the recipient, run the transfer from there, and move it back afterwards. Five accounts went from 243–249 tiles away down to about 2.1 tiles, and four full round trips have since run on real players, every one of them landing back on its exact starting tile. All three settings default to the safe side: relocating is off, 0 in the distance box means "use the 40-tile default" rather than "always relocate", and moving back afterwards is off, because a farm that supplies the same account every cycle should not pay two relocators every cycle. It cannot fail the transfer — an unreadable map, no relocator in the bag or a refusal from the game all fall through to marching from where the account already is — and it will never move a city it did not move itself.

A march that had just come home was still counted as out

The free-slot count came from a cached copy the game rebuilds a few frames at a time, measured about six seconds behind the live list — so a march that landed a second or two before a send was still counted as busy, and a round with three slots free fired two. Polling it faster could not have helped, because the number was stale at the source rather than read too rarely. It reads the live list now, and re-reads it on the open panel immediately before the split instead of before the camera flight. Across four logs that was 4,451 rounds averaging 3.14 of 5 slots used, and the accounts it cost most are the ones whose marches are back in seconds — which is exactly the situation relocation creates, so the two changes belong in one build.

Clear Villages marched away from monsters it was beating

This is the one to read if you watched it happen. A wave standing on its target swinging at it looks, from memory, exactly like a wave standing at home doing nothing — both read as parked — and the check asking "is this fight over" could not tell the two apart. Measured across two consecutive fights, both marches read parked with the monster still standing for four and six seconds, inside round trips of 63 and 72 seconds; that check runs every ten seconds and wants two readings in a row, so any fight whose parked stretch spanned twenty seconds was written off as lost and the next objective re-pointed those live marches off it. Our own log said so three times in one pass: "the marches sent at a monster are gone", then seven seconds later, "re-pointed 2 marches already on the map". Only a wave that has actually left the map counts as lost now, a parked one keeps waiting, and a fight that genuinely stalls still gets ended after three minutes.

Four of its messages named a cause nobody had measured

Each of these is the sentence you were expected to act on, and each one sent you somewhere there was nothing to do. "The account cannot reach a monster yet" was often the game refusing the march because the target outclasses the account — Clear Villages now reads that warning and confirms it, which is where the missing second march had been going. "A bridge or a dock there has to be opened" was reported for a crossing that is a fort, i.e. a fight it was about to have anyway. "The march queue is full" came from a branch that had never once read the queue — four slots, nothing out. And the check for unexplored ground only ever ran for monsters, so villages, forts, towers and the taming area were approved on the region alone; every target is checked properly now, and each pass logs which parts of the map it can and cannot reach.

The Accounts screen gets out of the way on a big fleet

Six changes, all of them asked for. Any dropdown with eight or more entries now has a filter box — the instance picker above all, where typing three characters beats scrolling two hundred instances, but also the account and profile pickers in Apply actions, whose lists are bounded now so the choices underneath them stay on screen. The instance picker also widens while it is open: the row's own buttons fold into the overflow menu and the picker stretches across the space they leave, so a long instance name is readable without the row jumping about. Two saved profiles can be merged rather than one replacing the other — the picked profile's switched-on actions are added to the one you merged into, its settings win where both have the same action switched on, and the profile you picked is left untouched, so you can do it again. Switching an action off now moves it to the bottom under a "Turned off" line, so what the account actually runs reads at a glance. And the activity log says how long each account's pass took, as "Finished in 10m 24s".

Gathering marched at tiles another player had already taken

Accounts in the same kingdom share what they have seen of the map so they stop piling onto the same tile, and that shared map is what your own accounts last saw — it is not global truth, and a player outside it can take a tile without us ever hearing about it. Over 410 picks in one two-hour fleet log, tiles picked from a fresh read were refused 0 times out of 82, tiles from the shared map 1.1% of the time, and tiles far enough out that nothing ever re-reads them 7.4%. Gold was worst at 4.7%, because gold is scarcest and so falls into that last group most often — and a refused gold pick was enough to mark gold unfindable for the rest of the cycle on accounts set to chase whichever resource they are lowest on. Before marching on a tile it has not looked at recently, the bot now asks the game whether it is still free and picks a different one if it is not. If it cannot get an answer it marches anyway, exactly as before.

Install Game said "LDPlayer path not set" on MuMu Player

Reported with the toast still on screen, on an install whose emulator is MuMu. The install had been taught about MuMu throughout — the right adb, the right serial, the right folder — and the single check standing in front of it still demanded an LDPlayer path and refused the whole install without one. That check now asks which emulator you are actually using. Nothing changes on LDPlayer.

A running game was relaunched because one reply came back empty

On one user's PC, replies from the emulator were arriving prompt, correctly formed and short — two screenshots came through truncated while still reporting success, and at the small end the same fault returns an empty answer rather than a short one. Asked whether the game was running, an empty answer reads as "it isn't", so the bot relaunched a game that was running perfectly: twice in fourteen minutes, about eighty seconds and a fresh boot each time. Two probes 129 milliseconds apart on the same live process disagreeing is what proved it. The check now asks once more before concluding the game is gone, and only at the one point where that conclusion costs a relaunch; a healthy instance pays nothing, because a positive answer comes back on the first read. The underlying fault is on that PC rather than in BotDaddy — this makes it cost far less when it happens.

v1.4.4

Copying game files from one instance to another works again — it had been refusing every copy source since v1.4.0, so the instances downloaded the 2.2 GB themselves on their first login instead.

One fix, and it is the only thing in this release. If you use Rebuild, Seed Selected or Update / Install Game with a copy source picked, this is the build you want.

Copying game files off a source works again

Since v1.4.0, picking a copy source and running a Rebuild, a Seed Selected or an install ended with the row saying the copy had been cut short — every time, on every source. Nothing was damaged by that: a copy BotDaddy cannot vouch for is thrown away rather than used, so each instance carried on and downloaded the 2.2 GB of game files itself on its first login, exactly as it would have before the feature existed. It just meant the feature did nothing for you, and every instance paid that download again. v1.4.0 changed how the files come off the source, to stop the source's own disk growing: the new way asks the instance to count what it has just sent so the two sides can be compared, and on the emulator that count comes back far smaller than what actually arrived, so every copy failed its own check. This release goes back to the way that was working up to v1.3.3 — the files are packaged up inside the source and the whole package is brought across.

The instance you copy FROM grows again, once per game version

That is the cost of going back, and it is the thing v1.4.0 was trying to remove. Packaging the files up inside the source leaves about 2.4 GB in that instance's disk file, because an emulator disk never shrinks on its own after something inside it is deleted. It is paid once per game version rather than once per run, since BotDaddy still keeps the copy on your PC and reuses it, and on MuMu Player, Reclaim Space gives that room straight back. On LDPlayer nothing changes at all: it always worked this way, and there the room stays until that instance is rebuilt.

v1.4.3

Clear Villages now takes a fresh account all the way to the Odin Statue by itself — five accounts did the whole map end to end — and the activity log reads as English again instead of showing raw labels.

Clear Villages could already work a village map; what it could not reliably do was finish one. This release is the difference, and five fresh accounts were driven all the way through to prove it: six sentry towers claimed and scouted, all four sacrificial stones purified, the dragon cave opened, the dragon's lair emptied and the Odin Statue unlocked, with nothing done by hand. This entry also covers v1.4.1 and v1.4.2, which shipped without notes, so several of the fixes below have already been in your build for a few days — including the one that stops the activity log printing labels like feed.gather.sending_march instead of sentences.

Clear Villages finishes the map now, not just works on it

The action used to make real progress and then leave things behind — a sentry tower beaten but never claimed, the monster holding a sacrificial stone's clue still standing, chests left shut. Five fresh accounts have now been taken from a half-done map to the Odin Statue unlocked, and every one finished with all six sentry towers claimed, all four stones purified, the dragon cave open and the lair emptied. Two of them finished with no chest left on the map at all. Nothing about how you use it has changed: it is still one setting, still two marches is the right answer for almost everybody, and it still takes several passes because every objective is a real fight whose marches have to walk out and back. What changed is that the passes now add up to a finished map.

It stops waiting on fights that are already over

A pass could sit for seven minutes watching a fight that had finished — the marches had come home, the target was still standing, and nothing was going to change. From the outside the bot looked frozen. It now notices when its marches have come back and moves on to the next thing within seconds. The same family of fix stops three other kinds of waiting: a target the bot had already killed is no longer re-attacked because something else on the map happened to finish at the same moment, a sentry tower it has just claimed is not claimed a second time, and a march the game accepted is no longer written off as refused because it had not started moving yet. That last one had a real cost: one account stopped making progress entirely because a single bad reading was remembered, leaving the dragon standing in front of everything else.

Targets are picked by what killing them unlocks

The game itself says which fight opens which chest, which stone and which region — every point on the map names what it is waiting for. The bot was not reading any of it, so the monster holding a clue a sacrificial stone needed was treated exactly like a monster that unblocks nothing, and which one it fought first came down to an internal id. It now works out what each kill frees and goes for those first, while still putting forts and sentry towers ahead of everything because those open whole regions. In practice that means fewer passes where it comes back later for something it walked past.

The chests the statue's last step releases are collected, not stranded

Beating the Odin Statue's final boss is what makes the last three chests in that region claimable — and unlocking the statue is also what ends the action for that account forever. So the pass used to take the statue and leave in the same breath, with three freshly-available chests sitting there that nothing would ever come back for. It now does one last sweep for chests and clues on the way out. On the accounts it has run against this took two chests each on three of them and one on a fourth.

A full march queue is no longer read as an unreachable village map

Shipped in v1.4.1, which had no notes. If gathering or a rally already had all of your march slots out, Clear Villages would ask for a march it could not have, the game would refuse, and the bot concluded the village map itself was unreachable — then remembered that for every target, so the feed said nothing on the village map is reachable yet on an account whose map was completely fine. It now checks whether your march slots are simply all busy before blaming the map. Also from v1.4.1: the game restart that the sacrificial-stone purification asks for is no longer counted as a fault, so it stops buying an emulator restart as well; that was costing eighteen accounts a needless restart each.

Gathering stops offering a tile it is already farming

Also from v1.4.1. When a gather march went out, the tile it marched on was supposed to be marked as taken so it would not be offered again — but that only happened if the bot still had that tile in its cache, which on the fast dispatch path it usually does not. The tile came back looking free and could get a second march while your troops were standing on it. The record is kept independently of the cache now.

The activity log reads as English again

Shipped in v1.4.2, which had no notes. Every packaged build up to that point shipped without its English text file, so some activity-log lines arrived as their internal labels — feed.mine.building, feed.gather.sending_march, feed.use_buff.used — sitting in the feed next to perfectly normal sentences. The text now ships with the build, the build refuses to finish without it, and a line the bot cannot phrase itself is handed to the app to translate rather than printed raw.

v1.4.0

Two new actions take an account all the way to Resource Transfer on their own — Clear Villages unlocks the Odin Statue, Mystic Realm clears the floors behind it — and BotDaddy now speaks fifteen languages.

The chain this release finishes: Clear Villages unlocks the Odin Statue, the statue opens the Mystic Realm, and Floor 5 of the realm is what lets an account supply resources — so until all of that is done, Resource Transfer does nothing on that account no matter how high its Tribe Hall is. Both new actions do the whole thing without touching the screen. This entry also covers v1.3.1, v1.3.2 and v1.3.3, which shipped without notes, so a few of the fixes below have been in your build for several days already.

Clear Villages — the village map, worked all the way to the Odin Statue

A new action that works the village map fight by fight until the Odin Statue is unlocked. Each pass looks at the map, picks the single most useful thing it can do right now and does it: claim a sentry tower it has already beaten, collect clues and open chests, open a sacrificial stone, take the next step at the statue, repair a dock or build a bridge to open a region, or fight whatever is in the way. It reads the map and sends its marches through the game's own calls, so there is no screen to read and nothing to tap, and it does not matter where the account was when the pass started. One pass almost never finishes the map, and that is normal: every objective is a real fight whose marches walk out and back. The game remembers all of it, so the next pass carries on exactly where the last one stopped and repeats nothing. One setting — how many marches it may use — and two is the right answer for almost everybody. Needs a paid plan.

Mystic Realm — cleared until the account can supply resources

A new action that goes into the realm, works out which rooms on the floor are worth a key, walks the squad to each one, lets the fights happen, collects the crystals and takes the stairs. It runs until the game says this account may supply resources, then stops permanently — every later pass does nothing at all. It is a plain on/off switch with nothing to configure. Expect several passes: the floors up to the gate cost about twenty keys, you can hold eighteen, and they refill at one an hour, so no account gets there in one sitting. Nothing is wasted in between — a key you spent stays spent, a room you opened stays open, and the next pass resumes the same floor. Needs a paid plan.

BotDaddy in fifteen languages — experimental, and we want to hear about it

Every screen, button, setting and activity-log line is now translated into English, Simplified and Traditional Chinese, Hindi, Spanish, French, Arabic, Brazilian Portuguese, Russian, Indonesian, German, Japanese, Korean, Thai and Polish. Setup asks which one you want, already set to whatever language your Windows is in, and you can change it any time from Settings, Language — it applies immediately, nothing restarts, and the activity log already on screen is re-read in the new language. Existing installs stay on English unless you change it, and Arabic lays the app out right-to-left. These translations are new and we are calling them experimental on purpose: they have not been through a native speaker yet, so if a word reads wrong or a label does not fit its box, tell us on Discord and we will fix it. The Settings card says the same thing. One part is not optional: keep Viking Rise itself in English. The bot finds buttons by reading English text off the game's screen, so an account whose game has been switched to match the app will quietly stop working, with nothing in the log to explain why.

Open Inventory — chests opened and resource items banked

A new action that opens the chests sitting in your bag and, if you want, uses your resource and gem items so they land in your warehouse and balance. You tick which kinds it should handle — Staging Post chests, Manor chests, King's Gifts, monster kill chests, mount chests and ten more groups — and it opens every one of that kind you are holding, whatever the rarity. There is no bag to open and no reward window to close, so a whole stack goes in one request: 565 Staging Post chests in under two seconds on the account it was built against. Nothing is ticked when you switch it on, because opening a chest cannot be undone. Chests that make you choose a reward are left alone.

Gathering spent most of its time flying the camera to tiles

Sending a gather march used to mean opening the world map, flying the camera to the tile, waiting for the popup and tapping through it. The march is now created directly — no map, no flight, no popup, no tap — at about three seconds a dispatch instead of roughly fourteen, including one sent from the city with the map shut. In a 74-minute run, 331 of 334 marches went out that way. Three guards came with it: a pass with no free march slot stops instead of spending eight seconds finding out, an account with no heroes in the city is named as such instead of being reported as having no troops, and 72 false 'sent fewer marches than expected' warnings per run are gone. Anything the direct route cannot judge still falls back to the old flight-and-tap path, so nothing is lost.

Emulators opening and closing all through a rest period

If you set a rest period between cycles, the whole rest looked like a frozen fleet: 'No fleet progress for 180s', 'restarting the affected emulators' and 'Host recovered' repeating, with LDPlayer opening and closing behind it. A resting tab holds every account queued with its emulators shut on purpose, and the stall detector was counting that as work that had stopped. A tab that is deliberately resting is now left alone, per tab — so a resting farm tab cannot hide a rally tab that really is stuck — and the clocks it judges on are reset the moment work starts again, instead of counting the whole rest against the first second of the next cycle. A rest longer than fifteen minutes also used to tell you to restart your PC.

'Viking Rise is not installed' on accounts where it plainly was

Six working accounts were parked dormant inside two seconds because Android's package manager gave an answer BotDaddy did not understand, and that was read as the game being missing. It happens when several instances boot at once and the report comes back cut short. Deciding the game is absent now requires the package manager to actually name it as missing; anything else is 'could not check' and restarts the instance. Getting that wrong left an account sitting dormant until you noticed, so it now errs the other way.

Accounts showing their neighbour's Chief's Hall and tribe

On an emulator two accounts share, the Chief's Hall level, tribe name and resources were read at boot — before Account Switch had run — so they came from whichever character played last, which is the other account. Nothing is recorded for an account now until its own switch has landed, and the hall, tribe and stockpile are read the moment it does. A failed switch leaves the last good reading in place rather than writing the wrong one.

A whole tab skipped at start, with its accounts never queued

One slow answer from the emulator's instance list was enough to skip every account in the first tab — 155 of them in the run this was found in — leaving that tab with no workers while the rest of the fleet ran on without it. The list was read once per tab, so each tab was a fresh chance to fail, and the tab built first was the one that paid. It is read once for the whole fleet now, retried if it does not answer, and a start that still cannot read it is refused with a reason instead of quietly running on whichever tab happened to come second.

Resource Transfer sending nothing at all on some accounts

An account holding only a handful of one configured resource sent nothing — not less, nothing. The game refuses a whole march that carries a one- or two-unit sliver and debits none of it, so every march was refused while the run looked clean. A resource whose share of a march would be 50,000 or less is now left out, and the rest goes without it. Marches are counted properly too, and the activity log names the resources instead of printing numbers. Shipped in v1.3.2.

Tribe actions running on accounts that are not in a tribe

An account with no tribe answers every tribe-related call with a confident zero, which reads exactly like a member who has nothing left to collect — so seven accounts logged clean tribe gift and tribe tech passes at tribe level 0 of 100. Six tribe actions now ask the game whether the account is in a tribe at all, on one cheap read, before walking to a page that cannot be there. Two of them had no such check before.

Tribe tech re-aimed off the leader's pick, and officers never starting a research

A refused donation was read as 'this line is finished' and the whole tribe's research target was moved, so one member short of a resource could re-point the tribe for all 189 of them. It now only moves off a line it can prove is actually full. Separately, an account with no donation charges left was treated as having nothing to do here, which was never the same question as whether a fully funded research was sitting there waiting to be started. In one 70-account run the single officer never once tried.

Alliance construction relaunching the game over a building's refusal

When an alliance building refuses a march — a contended tribe mine, for instance — that was read as BotDaddy's own navigation having failed, and bought a game relaunch. One gold mine produced 411 failures across 24 accounts in a single run, and 16 of the 17 that escalated to a relaunch failed again straight afterwards. A refusal from the building is a clean 'nothing to do' now.

Upgrade Building can stop at a level

The targeted Chief's Hall gets a 'Stop upgrading at level' setting. Leave it at 0 for no limit, which is what every action you already have does, so nothing changes unless you set it. It drops only that one target — a clone with other buildings on its checklist carries on with them.

MuMu instances stuck with the game running but no window

On MuMu, a game whose window never appeared while its process stayed alive was relaunched over and over into a VM that had usually lost root, which turns every attempt into an E-42. That case restarts the emulator now instead, and root is re-asserted on every launch so a lost one stops cascading. Also on MuMu: Update / Install Game no longer fails with '[WinError 267] The directory name is invalid' — the install was running from the saved LDPlayer folder even in MuMu mode. Shipped in v1.3.1 and v1.3.2.

A game hung on the IGG logo took five minutes to give up

A game that stops on the publisher logo and never reaches the loading screen used to ride the full 300-second loading budget before anything was done about it. That boot ends after 90 seconds now, so the relaunch that fixes it comes three and a half minutes sooner, and the log says the logo is what it was stuck on. Shipped in v1.3.3.

The copy source growing 2.4 GB a run, and 'Nothing to free' on a disk that was full

The instance you copy game files from gained about 2.4 GB on every seeding run. The files are now streamed off it once per game build and the copy kept on your PC, so the source stops growing and later runs never even start it. Separately, Reclaim Space reported 'Nothing to free' on a disk holding 2.0 GB of dead space, because MuMu's shrink only counts the blocks its own trim marked. The disk is measured directly now, and space the shrink could not give back is reported as a failure with the amount, so you know to run it again.

The activity log repeating itself and crying wolf

Every action failure printed its reason twice — 'Action failed: gathering: no tile found: no tile found' — which had quietly been the normal case for every action since that suffix was written. And a game relaunch that an action deliberately asked for, like the one Clear Villages needs after purifying the sacrificial stones, was flagged as a Warning in both the log and the activity feed. It reads as the ordinary step it is now.

v1.3.0

BotDaddy now runs on MuMu Player, new instances can skip the game's big first download, and Upgrade, Account Switch, Smithy and more are fixed.

The biggest update in a while. BotDaddy can now run your accounts on MuMu Player as well as LDPlayer: pick one in Settings and your accounts follow. New instances can copy the game's files instead of downloading them on their first login, a whole group of accounts can switch profile in one step, and the fixes below come with it. If you run a large MuMu farm and MuMu stops starting instances, see Disable MuMu Player's remote service in our guides.

Run your accounts on MuMu Player

Settings has a new Emulator section: choose LDPlayer or MuMu Player, and BotDaddy drives that one. It uses MuMu's Android 12 instances, and if Android 12 isn't installed yet, one button installs it. Each account remembers an instance on each emulator, and when you switch, an account with none on the new one is put on the instance with the same number. Rebuild Instances, Update / Install Game and the antivirus exclusions all work with MuMu too.

MuMu instances that never finished starting with the monitor off

MuMu's Vulkan graphics can't start an instance while no monitor is connected, and switching a monitor off counts. A new Graphics setting under Settings → Emulator lets you choose DirectX, the default, which keeps working with the monitor off. On Vulkan, BotDaddy now spots it within seconds, holds new instances until a display is back and leaves the running accounts alone — nothing counts against their retries.

A MuMu ad covering the game and swallowing every tap

MuMu's built-in app store can put a full-screen ad for another game over Viking Rise, and while it's up, every tap meant for the game lands on the ad. Before starting the game, BotDaddy now switches off the store's permission to draw over other apps, which hides the ad at once, and hides or closes one that still shows. LDPlayer's store offer gets the same treatment.

Every new instance downloading 2 GB on its first login

A fresh install's first login downloads about 2.2 GB of game files before it reaches the city, and several at once slow each other down. Those files are the same on every instance with the same game version, so Rebuild Instances and Update / Install Game can now copy them from an instance that already has them, and the new Seed Selected button copies them without rebuilding anything. A first login then takes a minute or two instead of several. Works on LDPlayer 9, LDPlayer 14 and MuMu Player.

Rename instances without a rebuild, and get disk space back on MuMu

Rebuild Instances gains two buttons that rebuild nothing. Rename Selected gives each ticked instance the name of its account in about a second, on LDPlayer or MuMu Player, and never gives two instances the same name. Reclaim Space, on MuMu, shrinks each instance's disk file back to what it actually holds, without changing anything inside it.

Switching a group of accounts to another profile one by one

Tick some accounts, right-click, or use a group's header, and Switch profile moves every account that has the profile onto it in one step. Copies made with Add as a profile on each account stay linked even if an account renames its copy, and every account's Default counts as the same profile, so putting everyone back is one switch. Accounts without the profile are named and skipped.

Upgrade Building saying both builders were busy right after starting an upgrade

On the current game version, the building's window stays open after you confirm an upgrade and shows the new timer, and BotDaddy was waiting for the old screen. So it reported an upgrade it had just started as both builders busy, skipped your next pick, and never asked your tribe for help or used speedups on it. It now recognises the started upgrade and closes the building's window when it's done. If you have speedups switched on, expect them to be used again.

Account Switch signing in to the wrong IGG account

A button pressed twice in quick succession could land on the ID list beneath it and pick the account in that row, and the confirmation naming the account was accepted without being read. BotDaddy now waits to see each press take effect before pressing again, reads the IGG ID the game offers, and cancels rather than confirms one that isn't yours. In character mode it taps a character card twice before deciding it's already the active one.

Lost connections and 'isn't responding' popups ending in a restart

When the game loses its server connection, BotDaddy now taps OK and waits for the game to log itself back in, instead of pressing Back on the loading screen and force-stopping it. 'Viking Rise isn't responding' popups are cleared in the middle of an action too, not only during startup, and one broken instance no longer slows screen reading for all the others.

New accounts crashing right after their first login

Confirming the IGG ID on a fresh install makes the game reload, and BotDaddy could act on the game mid-reload, which froze or crashed it. It now waits out the reload and carries on once the city is up, and no longer mistakes the old new-player screen for a failed login.

Smithy stopping before all five monsters were done

BotDaddy wasn't closing the Treasure Obtained screens its claims open, and they covered the Create button for the next march, so passes ended early. It closes each one now. It also checks your energy before each monster and stops cleanly when there isn't enough, and never sends out more monsters than you have left for the day.

Commissions handing in a whole stockpile, or walking you to the Exploration map

Each pass now hands in at most five of any one material, across every commission that asks for it, and presses Submit All up to three times before working commissions one by one. Submit All itself is outside that limit. Before pressing Go, BotDaddy reads the open commission's requirement and never presses Go on one that says Explore.

Heal, Hall of Valor, Tribe Bank and Obtainables

Heal opens an Infirmary that isn't being upgraded, and tries another if a Heal button does nothing. Hall of Valor closes its summon page itself and retries a summon that didn't finish. Tribe Resource Donation switches the bank to the Donation Goal tab when it opens on another one, and stops waiting for resources your tribe didn't ask for. Obtainables claims once, since a second claim could freeze the game on a new account.

A once-a-day action running twice after you edited the account

Saving an account's actions sent back the run history from when you opened the screen, so a once-a-day action that had already run could run again that day. BotDaddy now keeps its own record of what has run. Also fixed: switching profile right after copying or removing an action could put the change in the wrong profile, profiles you aren't using now get update changes too, and an account's instance name updates as soon as you change it.

Setup insisting on LDPlayer

The installer's LDPlayer page is now Emulator Setup, with a Skip for now button for anyone using MuMu Player or installing an emulator later, and a missing LDPlayer shows as a warning rather than an error. The installer's warning and error colours, which were showing up blue, are fixed, and the virtualization page no longer cuts off its last paragraph.

Other fixes

Update / Install Game retries an instance that doesn't finish booting, up to three times, using your Android Booting Timeout, and no longer shows Install complete straight away on a second run. The bot won't start while Rebuild Instances or Install Game is running. Rebuilding with renaming no longer starts the next boot while an instance is still shutting down, and the instance picker no longer jumps back to the top while you scroll.

v1.2.33

Auto Rally joins as many rallies as your account allows, and event monsters are rallied again.

If Auto Rally was joining a single rally on some accounts instead of 15, or Initiate Rally stopped finding Lightflame Lizards after the 1.5.151 game update, this release fixes both. It also carries everything from the previous update, which went out without notes.

Auto Rally set to join just 1 rally

When BotDaddy switched the game's Auto Rally on for an account that had never used it, it left Number of Times Joined where the game had it — 1 — and kept it there on every pass after that, so those accounts joined one rally and stopped. BotDaddy now always sets it to the most the account allows (15), including putting it back up if it was lowered. Accounts that already had Auto Rally set up were unaffected.

Initiate Rally stopped finding Lightflame Lizards

Game update 1.5.151 brought the season's event monsters back as new entries, and BotDaddy's rally target lists predated them, so the Lizards on the map matched nothing. The lists are rebuilt from the current game, and Lightflame Lizards and the other returning event monsters are rallied again.

One checkbox per monster, however many times an event returns

When an event runs again, the same monster exists more than once. Each monster now has a single checkbox in Auto Rally's join targets, and ticking it covers every run — BotDaddy uses whichever one the game's Auto Rally page offers.

Snaketail Beast/Darktide Warship can be joined

It never had a checkbox, because four entries share that name. One checkbox now covers all four.

v1.2.31

Choose which tribe tech tree to feed — and stop ticking boxes to reuse a setup.

Tribe Technology can now be told which tree to research, instead of drifting into whichever line happened to be cheapest. Alongside it, action profiles finally have a home of their own: a Profiles button you can open any time, and a right-click on any account to apply or switch one — no more selecting rows you never meant to change. This release also carries everything from the previous update, which went out without notes.

Tribe Technology: choose the tree

A new Tech Tree Focus setting on the Tribe action. Leave it on Current tree and donations stay in whichever tree your tribe is already researching, pick a named tab to commit to one, or choose Any tree for the old behaviour. Trees your tribe has not opened yet are never picked as a target, and charges are still spent wherever they can be.

A Profiles button on the Accounts screen

Reusable action profiles now have their own window, open any time from the header. Create, edit and delete them without ticking a single account — and nothing you do in there changes an account.

Right-click an account to apply or switch

Right-clicking a row offers Apply actions, which opens the apply window already pointed at that account. If the account has profiles of its own, the same menu switches it onto one straight away.

Undo on applying actions

Every apply now offers an Undo for a few seconds afterwards, whether you got there by right-click or by Apply to selected. One press puts every account it touched back the way it was.

The activity feed says what actually happened

Actions used to report a flat “Finished” whether they had done the work, found nothing to do, or could not read the screen at all. The feed now names the real outcome for every action that reports one.

Non-English Windows could not read command output

On Windows installed in French, German and other languages, some of BotDaddy's own checks silently came back empty — which quietly switched off emulator port checks and stale-port cleanup. Those reads now work on any Windows language.

Faster troop training

Training was reading the barracks several times over for the same piece of information. It now reads it once and reuses it, which makes every training pass quicker.

Smithy no longer waits on marches it never sent

With no free march slot the attack was refused, but Smithy counted it as sent and then waited out its whole timer for a march that was never coming. It checks for a free slot first now.

Gathering with nothing ticked no longer restarts the game

A gather action with no resource selected was treated as a failure, so it relaunched a perfectly healthy game and tried again, every cycle. It now says so in the feed and moves on.

Mail could miss its own button

The mail badge was being tapped a fraction too early, before the home screen was ready to accept the tap. It waits for the screen to settle now.

The Prosperity Merchant explains itself

When the merchant refuses a purchase, the message now says when the weekly allowance resets. The allowance is weekly, so a fleet running in the hours before it rolls over can buy nothing at all — and now it tells you that is why.

Renewals no longer stop the bot

There is a short gap between a subscription renewal being charged and the confirmation reaching us. The bot used to stop during that gap; it keeps running now, and a real billing problem says so instead of blaming your network.

The “this PC needs a restart” false alarm

An account doing work that needs no emulator commands could trip a warning claiming the PC's whole connection layer was down — while the same message reported the emulator as online. The check now reads a signal that reflects the work actually being done.

The activity feed could stop updating

One unusual item in the feed could break the connection to every open window, and reconnecting ran into the same item again — leaving the app looking connected with a feed that had quietly stopped. It drops the single bad item instead now.

v1.2.29

Emulators that stopped coming back — and the repair that was causing it.

If you have watched instances stop booting partway through an overnight run and never recover until you restarted the bot, this release is why that happened — and it was BotDaddy's own repair step doing it. Alongside it: tribe tech donations that were banking nothing on half of all passes, account switching that cancelled itself at the last dialog, and a whole class of failure on fresh Windows Server and VPS machines where everything that reads text was silently dead. Nothing here needs re-configuring.

Emulators stopped coming online, and only restarting the bot brought them back

Before launching an instance, BotDaddy clears anything it thinks is still holding that instance's network port. LDPlayer leaves a small networking process behind for a few seconds after an emulator shuts down, and one that was taking longer than expected was being read as leftover junk and killed. Killing it is what broke the instance: VirtualBox then has no network service for that emulator, so every later launch brings the virtual machine up with nothing connecting the bot to it. Two overnight runs on one PC agree to the number. On the accounts it happened to: 113 boots before the first kill, none failed; 314 boots after, 80.6% failed. The 45 accounts it never happened to: 591 boots, 0.3%. Median 90 minutes stranded, 20 of 32 never came back at all, roughly 10% of that run's entire capacity gone, and every one of its five fleet-wide pauses. Killing it produced a working boot zero times out of 32. A release earlier this month added a grace period so this only fired on a process that really was taking too long — that stopped the false alarms and left the assumption underneath untested, and the assumption was wrong. The process is now recognised, noted in the log and left alone. Only leftover headless emulator images are still cleared.

Tribe tech donations banked nothing on half of all passes

Reported as the bot not moving on to another tech when the recommended one is full. When the recommended line refuses, BotDaddy searches the tree for one that will take a donation — and it was searching in the worst possible order. It went through lines nobody had put points into first, reasoning that an untouched line cannot be full. True, and the wrong question: a line nobody has donated to is overwhelmingly a line nobody can donate to, because it is still locked. So the search spent its whole budget proving locked lines were locked and never reached the unlocked ones just past them. Over 24 hours on one fleet: 1,108 passes, 552 of them banked nothing at all, and 9,935 donation charges left unspent. 495 of those failures were one single recommended line across 21 accounts, 18 of which banked nothing all day. The clincher was two emulators each running two characters — the one whose tribe recommended the dead line went 29 attempts, 0 banked; its neighbour on the same PC in the same minute went 29 attempts, 20 banked. Lines that already hold points are searched first now, because a donation that has landed is proof the line is unlocked. Measured on a live fleet after the fix: 122 passes, 2 of them empty, 1,802 donations. Separately, the table the bot reads to tell whether a skill's energy bar is already full was being cached the first time it was asked for, which on a game that has just started is only partly built — so those lines read as unknown for the rest of the session and were attempted anyway, costing six seconds and an in-game refusal message each. It re-reads now when a line it needs is missing.

Re-pointing the tribe at a different tech had never once happened

R4 and above can change what the tribe recommends, and BotDaddy is supposed to do that when the current target stops taking donations. It had never fired — not once, across five logs and two fleets. Two reasons stacked on top of each other. Most accounts are R1 and cannot do it at all, and the bot said nothing about that, so "we chose not to, you are R1" and "this is broken" produced exactly the same silence in a log. It now says which rank it has and which it needs. The second was a real bug: it only considered re-pointing after it had gone looking for a fallback line, and the case that matters most is not a fallback — the recommendation is a skill whose bar is full, and the research line beside it still pays out — so the tribe stayed pointed at the dead one. Now live on an R4 account: the recommendation moved off the full skill onto the research line that had just taken all nine charges, confirmed by reading the field back afterwards. It cannot thrash, because after the move the line it just paid into is the recommendation.

Account switch cancelled itself at the final confirm, then worked next time for no reason

Reported in those words, and it is a race, which is why it looked random. The bot taps Confirm on the "Play using IGG ID?" dialog and hands straight off to the boot loop, whose job is to clear whatever popup is covering the home screen. The boot loop does not know popups by name — it finds a close X and taps it — and the popup it found was the confirm dialog we had just committed to. Four switches in the log, four identical shapes: Confirm, then a close X three quarters of a second later. Three of those landed after the game had already torn the dialog down and did nothing at all. The slowest, 0.830 seconds, landed while it was still up: the login was cancelled, the bot dropped back to the login page, spent 47 seconds on a screen it could not name, and paid a full retry. This is new in 1.2.28 — the sixth close-button image added in that release is the first one that can reach that particular X, and nothing before it could. The image is right and stays; the handoff was wrong. BotDaddy now waits for the confirm dialog to actually go away before handing off, and re-taps Confirm if the press was swallowed.

Everything that reads text was dead on a fresh Windows Server or VPS

On one customer's PC, everything BotDaddy does by recognising pictures worked perfectly all night, and everything that reads text failed — 2,347 attempts, 2,347 failures, not one success, in a run where that was 98% of all errors. Account switching is where it shows first: the bot reaches the screen where it has to pick your ID, cannot read the list, waits out its budget in silence and gives up. 33 switches, 33 failures, no successes, which is what got reported as getting stuck on the credentials screen. The cause is a missing Microsoft Visual C++ Redistributable — free, on essentially every normal Windows desktop already, and absent from bare server images. Installing it fixed that customer immediately. BotDaddy checks at startup now and writes a plain warning naming what to install. The same fault had a second and more expensive symptom: the check that decides whether the game's text is rendering correctly reads "no text anywhere" as a corrupted font cache, so it ran its repair sequence 272 times and asked for a game relaunch 34 times on games that were perfectly fine. It asks whether text reading is available at all before blaming the game.

Popups during boot now close without having to recognise a picture

Every popup the game throws up while an account is loading used to be closed by finding its X in a set of reference images. That works right up until the game draws one we do not have — and then the bot presses Back, which some popups swallow, decides it is lost on an unknown screen, and relaunches the game. That is exactly what last release's new close-button image was for. BotDaddy now asks the game which windows are actually open and closes them by name, with the image sweep still sitting behind it as a fallback. Across 101 boots on a live fleet: 123 popups closed this way, the image fallback used zero times, and not one boot where the bot failed to get an answer. It also covers the second login of an account switch, which the old path could not reach at all — three switches, three post-switch logins, all three cleared this way.

A failing boot took three minutes to give up, and then got the wrong repair

Two separate things, both on the boot that has already gone wrong. First: when an emulator did not answer, BotDaddy widened the wait on each retry — 120 seconds, then 150, then 180 — on the theory that a slow machine needs longer. Measured across 763 successful boots on a real fleet, it does not hold. Half answer in 22 seconds, 99% within 41, and the slowest that ever worked took 42.8. Every one of the 255 failures in that same run sat past 121 seconds. A boot answers in about 43 seconds or it is in a state no amount of waiting fixes, so the widening never rescued one — it just made 166 of those verdicts cost three minutes instead of two. It is gone; there is one boot budget again, the one in Settings, applied the same way to every attempt. Second: BotDaddy picks between relaunching the game and restarting the emulator by matching on why a step failed, and a change two releases ago moved which layer reports one of the boot steps. The label it started reporting matched none of those rules, so a boot where the emulator never answered fell through to relaunching the game — which cannot fix an emulator you cannot reach — and then rode the relaunch ladder for six recoveries before parking the account. The rules name the step now rather than one particular spelling of it. A second recovery rule turned out to have been unreachable entirely for the same reason, and fires again.

A third of the fleet stopped responding for hours and nothing said which accounts

BotDaddy already watches for the whole PC's connection to the emulators going down. That check asks one question — is this PC's emulator connection alive at all — and a single healthy emulator answers yes. So on a run where 26 of 71 instances were unreachable for hours, it never fired once, because the other 45 kept it looking fine. What you saw instead was the fleet pausing five times and holding for fifteen minutes with nothing naming a single instance. There is a separate check for exactly this now: an emulator that has been tried recently and has failed every attempt for ten minutes straight gets reported by index, with how long the worst one has been out and what to do about it. An account nobody is currently driving is parked, not broken, so it is never accused — the check needs real failed attempts, not silence.

Tribe Mine kept relaunching the game over a mine it cannot reach

Three accounts spent every cycle doing the same thing: fly to the mine, wait for the troop panel, never get one, fail, retry twice, relaunch the game, retry three more times. The mine is behind a map gate. The game refuses to open the panel, says so in a toast, and makes no other statement — no panel, no error, no button — and nothing was reading that toast, so a permanent fact about the account was being treated as a timing problem and retried forever. 130 successful dispatches against 18 of these in one run, always the same three accounts, always the same resource. BotDaddy reads the toast now, ends the pass cleanly with the reason on it, and moves on. It cannot fix this one and you can, so it says so rather than burning a relaunch on it.

New — BotDaddy shows you which folders Windows Security should skip

An emulator reads its entire virtual hard disk every time it boots, and BotDaddy writes logs and screenshots the whole time it runs. Windows Security scans all of it, over and over, and none of it is ever going to be a virus. There is a card on the Settings screen now that reads what is already excluded and shows you what is not — your LDPlayer folder, your BotDaddy data folder, and the install folder. One button adds them. That button is the only thing that ever changes your security settings; nothing is applied on your behalf, and on a machine where there is nothing to say the card does not appear at all.

Disable Virtualization now tells you whether you actually need it

The tool has been there a long time and the only way to find out whether it applied to you was to run it. It reads what your PC is doing now and says so at the top of the card: green when no hypervisor is running and the emulator already has the processor to itself, in which case running the tool would change nothing — or amber when Memory Integrity or something like it is holding it. It reads what is actually running rather than what is configured, because a setting can be asked for and then refused by group policy, blocked by firmware, or left waiting on a reboot, and those are exactly the cases where turning something off appears to work and has not. Separately, if BotDaddy's engine cannot start because the processor lacks AVX2, the message now covers the case where it is a virtual machine rather than old hardware — one report was a Xeon well past our line, with the host hiding AVX2 from the guest, and the old message told that user to replace a machine their provider could fix in a settings panel. The log also records the processor, core count and memory on every launch, not only once something has already gone wrong.

v1.2.28

A popup the bot could not close, and the two daily actions that got stuck behind one.

Every one of these is the same shape: a window the bot could not get rid of, and an account that paid for it. A new event popup whose close button the bot did not recognise; a Hall of Valor tutorial that locks the screen until you tap through it; a reward popup Daily Quests was trying to dismiss by tapping 69 pixels below the right spot. In each case the bot ends up pressing Back at something that ignores Back, decides it is lost, and relaunches the game — and in the worst case parks the account entirely. Nothing needs re-configuring.

A new popup the bot would not close

The bot carries a small set of reference images of the close X, because the game draws that button slightly differently from one popup to the next and we would rather cover a family of them than ship a new image for every event. A recent popup's X falls outside that set. It is not that the bot could not find the button — all five reference images landed on exactly the right spot and all five scored just under the bar the bot needs to be sure, the best of them 0.834 against a 0.85 requirement. So the bot would not tap it, fell back to pressing Back, and on a popup that swallows Back that ends with the bot deciding it is lost on an unknown screen and relaunching the game. A sixth reference image now covers it and matches at 0.932. Checked against 3,000 real screenshots before shipping: it never once fired on anything that was not a close button.

An account stopped running entirely, and no restart could fix it

One account in an overnight run ended up parked. The cause was the skill summon tutorial — the one that puts an arrow on the Hall of Valor card and locks the screen until you tap through the dialogue. The bot has no way past that on this screen, so it sat there; the next daily action inherited a locked screen, reported it could not get back, and went through the whole recovery ladder — relaunch the game, restart the emulator, six steps of it — and none of it worked, because a tutorial is something the account is waiting on, not something a restart clears. Hall of Valor now recognises the dialogue and taps through it. Related, and the reason it got as far as parking the account: when a tutorial overlay is on screen the bot could read an absent Free Summon button as "already claimed today" on a screen that was not the summon page at all. It now says it did not reach the page and lets the normal retry handle it, while an account that genuinely has one summon type and no tabs still skips cleanly.

Daily Quests claimed one reward and then failed the rest of its tabs

Claiming a chapter reward raises a Treasure Obtained overlay that closes when you tap blank space. Daily Quests was tapping a fixed point 69 pixels below where that overlay actually asks you to tap — 24 times over 18 seconds — so the overlay stayed up and both remaining tabs then failed, because everything behind them was covered. It happened on every occurrence we have logs for. That exact coordinate had already been found and fixed on the Staging Post board months ago; it was still sitting in Daily Quests. Both Daily Quests and VIP now dismiss these the same way, by watching for the page to come back rather than tapping a memorised spot and hoping.

The Staging Post could freeze the game, roughly once in every 139 boards it opened

We have not found the cause yet, but we have narrowed down where it happens: it is always the first bounty opened on a board that had exactly one workable bounty on it — 11 times out of 126 such rounds, against zero out of 552 rounds with more than one. Every one of those fired within about a tenth of a second of the bot reading the board. This release makes the bot wait until the board has been on screen for two seconds before opening the first bounty. It is a guess at the cause, and it is written into the code as one. It costs almost nothing: about 89% of bounty opens are already well past that point and wait for nothing at all, which across a whole fleet run came to roughly three minutes. If freezes carry on regardless, that tells us the timing was the wrong theory, which is worth knowing.

Log files you can actually read the date off

Backend logs and the optional screenshot folders were named like backend_20260916_220905.log, which is a date and a time but does not read as one. They are now backend_2026-09-16_22-09-05.log. They still sort into chronological order in the folder, so nothing about finding the newest one changes — it is just easier to pick the right one out when you are asked for the log from when something broke.

v1.2.26

Your whole fleet now boots in parallel — plus the 1.5.151 update and a round of Auto Rally fixes.

The game updated to 1.5.151: the new build is on the Tools page, and the bot now finds its own way back to reading the game directly instead of waiting for us to ship a fix. The bigger change is Parallel Boot — if you have ever set 15 instances running and watched the first account finish before the last one opened the game, that is what it fixes. The rest came from watching live accounts: Auto Rally drifting further from your city with every rally, emulators that stopped coming online until the bot was restarted by hand, a login screen the bot could get stuck on, and Dragon Cave skipping smelts without saying so. Nothing needs re-configuring — Parallel Boot is the one new switch, and it is off until you turn it on.

You set 15 instances and never saw 15 of them running

BotDaddy has always started emulators one at a time: launch one, wait for it to finish booting, then launch the next. An emulator takes somewhere between 40 seconds and two and a half minutes to be ready, so on a 15-instance fleet the last one was not opening the game until around 18 minutes in — by which point the first account had often finished its work and shut down. Parallel Boot, new in Settings under Runtime, starts them a few seconds apart and lets them boot at the same time instead: 5 instances go from about 6 minutes to about 20 seconds, 10 from about 12 minutes to about 45 seconds, 15 from about 18 minutes to about 70 seconds. A stuck instance also stops holding up everyone else's launches, because nothing is waiting on it any more. It is off by default and applies on the next start, so save, then stop and start the bot — and turning it off puts everything back exactly as it was. The gap between launches is yours to set: 5 seconds is the default, 2 or 3 suits a strong PC with a fast SSD, and 10 or 15 is the fix if instances start failing to boot once you switch this on, because accounts restarting instead of working is what a host running out of CPU and disk looks like. It does not let you run more instances than before — that is still the instances number in Settings — and Fast Boot has no effect while Parallel Boot is on, since its job was deciding how far into a boot to wait and Parallel Boot stops waiting for the boot at all.

Emulators stopped coming online, and only restarting the bot brought them back

Before launching an emulator the bot checks whether anything is still sitting on the network port it needs to talk to that emulator, and clears it — a leftover process from an earlier run can hold that port for hours and block every launch after it. What the check could not tell apart was a genuine leftover and the emulator's own networking process from the run that just ended, still shutting down. LDPlayer reports the emulator as stopped before that process is gone; it usually clears in about three seconds, and sometimes it takes longer. Killed inside that window, the emulator is left with no networking service at all, so every launch after it brings the emulator up with nothing for the bot to connect to — and restarting the emulator, the bot's normal recovery, could never fix it, because the emulator was never the broken part. In the two runs that reported this, six boots before the kill connected in 64 to 75 seconds and the sixteen after it never connected at all, across three accounts and 27 minutes, until the bot was restarted by hand. The bot now gives anything on that port up to fifteen seconds to leave on its own before deciding it is a leftover, and that wait happens before the emulator starts, so it does not come out of the launch's own time budget. This was most likely to bite on emulators running several accounts, because each handoff between them is another chance to catch that shutdown halfway.

Rallies drifted further from your city the longer an account ran

After launching a rally the bot left its view of the map sitting on the target it had just hit, and the next search both looked from there and ranked what it found by distance from there. So every rally picked something near the last one and walked steadily away from home: measured on two accounts over one two-hour run, march round trips climbed the whole way — 23 seconds to 162 on one, 26 to 197 on the other. The view is now returned to your city before every search, and the bot waits for the map around it to finish loading before it picks, which turned out to matter as much as returning the view: searching too early found nothing at all and sent a march 44 tiles out, on an account that had 14 targets loaded nearby with the nearest free one 4.7 tiles from the city. When there is genuinely nothing within 30 tiles it now looks in all four directions and takes the closest to your city, instead of taking the first direction that happened to have something. Same two accounts after the fix, about two hours each: no upward trend at all.

Long gaps between rallies, and sometimes an emulator restart for no reason

Two things sat between one rally and the next. If someone else in your tribe had already rallied a target, the bot had no way to tell — it had checked when it picked the target, not when the game refused it — so it kept trying the same one: live, that was the same target refused six times, ten seconds apart, with three march slots free the whole time. It now asks the game whether the target has been taken at the moment it gets refused, and moves to the next one instead, up to three swaps before it gives up on the pass. And when troops came home it only checked every 20 seconds, so it could sit through most of that before noticing — by which point something else had usually taken the free slot, and the next rally could not start at all. It checks every two seconds now, and checks before it waits rather than waiting first; resetting the Auto Rally participation count used to happen in that same gap and costs about six seconds on screen, so it now runs immediately after a rally launches, where there is time to spare. Measured afterwards across nine cycles on both accounts: troops home to the next rally out in 19 to 27 seconds, and all of that is real work. Separately, the code that waits for a march slot to free up had a bug that took the whole pass down as an error rather than ending it cleanly, and an errored pass earns an emulator restart — so a busy fleet could cost you a reboot on an account that was working perfectly.

The bot sat staring at the login screen, then restarted the emulator

It typed your email and password into the form without checking whether either one landed, and pressed Login regardless. When an emulator is under load those typing commands can fail — 18 of them did in the run this came from — so the bot submitted an empty form, saw the form still sitting there, and concluded the game had rejected the credentials. That verdict is treated as final: it skips the two login attempts it had left and goes straight to restarting the emulator, six times in that one run, which on an already-busy PC only makes the next attempt likelier to fail the same way. The credentials were never wrong — seven accounts in the same run logged in fine, several of them only after failing this way first. The bot no longer presses Login on a form it did not fill, and a form still showing after a submit it is not sure of is retried rather than called a rejection. The typing itself retries once when it can tell nothing was typed; if a command times out part-way it abandons the attempt instead, because re-sending could put your email in twice. None of this makes a slow emulator faster — it stops a dropped keystroke costing you the login and an emulator restart.

Dragon Cave stopped smelting on some accounts and never reported a problem

If an account had a finished conversion waiting, the cave opened on the conversion claim screen instead of the smelt screen, so the bot found nothing it could stage and moved on. It looked like a quiet no-op every pass, which is why it could run for a long time unnoticed — we found one account where the conversion had been sitting unclaimed for seven days, losing every smelt in that window. Dragon Cave now claims a finished conversion first and then smelts as normal. Nothing about how you configure it changes, and Convert is still yours to drive.

A game update used to take the bot's fast path down until we shipped a new build

The bot reads the game directly rather than only looking at the screen, and that reading is anchored to addresses inside the game that move whenever the game is rebuilt. Until now a rebuild meant those anchors were wrong and the fast path was simply gone until we found the new ones and released an update. It now detects that state and finds the new addresses itself: on 1.5.151 every one of the five moved, and the bot re-anchored in 12.5 seconds on the first launch. You do not need to wait on us for this any more.

Four actions would have broken on this game update

The self-recovery above re-finds several addresses, and one of them was being looked up in a way that could never match, so it quietly kept the old one instead. That was harmless for as long as the old address was still correct — and wrong the moment a game update moved it, which is exactly when the recovery is supposed to run. Left alone it would have broken Upgrade Building, Academy Research, Divination and Hall of Valor on 1.5.151, all four of which have no screen-reading fallback to fall back on. Found and fixed before the release went out.

Stopping and starting the bot sent every tab but one back to the top of its list

Start offered to continue from the last completed account, but it picked a single account — the most recently finished one anywhere in your fleet — and that account sits in one tab. Only that tab picked up where it left off. Every other tab began again at its first row, so if you stop and start the bot often, those tabs kept re-running the same handful of accounts at the top while the ones further down never got a turn. Each tab is now asked the question on its own and resumes from its own most recently finished account, and the Start dialog names the account each tab will pick up from so you can see what will happen before you commit. Pressing Start on one account's row does the same for every tab that account is not in — pinning one account shouldn't cost the others their place. A tab that has never finished an account still starts at its top, and if the engine restarts by itself it keeps the choice you made.

Sending one account to another tab took its whole group with it

Right-clicking a single row inside a group and picking a tab moved every account in that group. The bot was holding a rule that a group had to sit in exactly one tab, so it expanded your pick to the whole folder — and that rule overrode the one gesture that can say "just this one". Now exactly the accounts you picked move, and they keep their group. A group with accounts in two tabs is drawn in both, each folder showing the accounts it has there, and the header count reads "1 of 4" so you can tell where the rest are. The move button on the group header is unchanged: it still takes every member across, including any you had sent off on their own.

Both game versions run while you update at your own pace

1.5.151 is now the version the bot installs and expects, but 1.5.140 is still accepted, so accounts that have not moved yet keep running instead of parking themselves. Install the new build from the Tools page whenever it suits you. One more thing you may notice after updating: the first launch of each emulator is slightly slower than usual, once, while the bot refreshes the helper it installs on them. Every launch after that is normal.

v1.2.25

Auto Rally now claims your free daily energy before it spends a single potion.

Two things this release. Auto Rally takes your free daily energy before it starts spending potions, and every account shows its Chief's Hall level and tribe on the list.

Auto Rally spent potions without claiming your free daily energy first

It went straight to your bag to reach the energy level you set. It now claims the free energy first and spends potions only on whatever gap is left, so most passes use fewer potions for the same result and some use none at all.

Free energy is held back when your energy bar is already full

Claiming at full burns the day's claim and banks nothing — we confirmed that on an account sitting at exactly full, where the request went through and not one point of energy landed. So Auto Rally holds the claim there and takes it on a later pass once rallying has made room, which is usually a pass or two. If you ever see it skip a claim, this is why.

You had to open each account to check its Chief's Hall or tribe

Both now sit under the name on the accounts list — "Lv. 29" and your tribe tag — so you can read a whole fleet at a glance. Hover the tag for the full tribe name. Open an account's settings and the panel at the top, now called Account, shows the same two plus the food, wood, stone and gold it last saw. All of it is read while the account is already running, so opening it costs nothing and starts nothing. An account with no tribe says so; one the bot has not managed to read yet says that instead, because those are different things.

v1.2.24

Four fixes from one user's logs — three of them errors that named the wrong cause.

Every one of these was the bot telling you something that was not true: a healthy account reported as timed out, a rebuild reporting a failure that had actually succeeded, a red error about a process behaving perfectly normally. None of them broke anything permanently, and all of them sent you looking in the wrong place.

Pausing the bot could kill an account that was mid-boot

A starting instance gets a time budget, and that budget correctly ignores time spent paused — pausing should not count against it. The layer above was not so careful and used the wall clock, so pausing for a minute while an instance was booting made that account overshoot and get killed, reported as a device timeout. Two unpaused boots in the same run finished cleanly, well inside the budget. The boot's own budget is now the only one that applies.

A failed boot could relaunch the game on an emulator that never came up

Fixing the pause problem above changed which layer noticed an overrun first, and the new one reported it in a form the recovery rules did not recognise — so instead of restarting the emulator, the bot relaunched the game inside an emulator whose connection had never come up at all. Underneath that sat a budget that had always been too small for what it covers: the check for whether the game is installed runs in the same phase, and nobody had added its time in. The budget now has that arithmetic written down, and it follows along if you raise the boot timeout in Settings.

Rebuild said it could not restore your settings when it already had

With "rename instances to their account names" switched on, the rebuild tool lost track of which row it was writing progress to — the row is tracked by the name, and the rename had just changed it. The settings had been restored a moment earlier and the rebuild was fine; only the progress bookkeeping failed, and it was reported as the work failing. Losing track of a row can no longer be reported as the job going wrong.

Red errors about LDPlayer's own process during a normal shutdown

Stopping an instance and checking its network port a fraction of a second later catches LDPlayer's own window still closing. The bot logged that at error level, called it "not an LDPlayer process", and said the instance could not be reached — all three wrong. In the reporting user's log that instance answered 74 milliseconds later. It is now an ordinary informational line with accurate wording. Nothing about which processes get cleaned up has changed.

v1.2.23

Three gaps closed in last release's fix — including one the fix itself introduced.

v1.2.22 stopped the bot relaunching games it should have left alone. Auditing that fix afterwards turned up three more things worth closing, and one of them was a problem the fix had created. If you are on v1.2.22 and it has been behaving, none of these will have been obvious — they are the edges.

An emulator could go quiet to the bot for half a minute after a connection blip

The last release added a limit on how often the bot re-opens its connection to an emulator, because repeatedly re-opening it was part of what overloaded the machine. But the limit was not lifted when the connection was genuinely rebuilt — which is exactly the moment it needs re-opening. So a routine blip could leave that emulator unreachable for up to thirty seconds, and the three actions that have no fallback (Upgrade Building, Academy Research and Hall of Valor) would fail for that window. The limit now lifts every time the connection is actually rebuilt.

Dragon Cave could restart a game that was running fine

When Dragon Cave checked what was in your inventory and that read did not come back, the failure escaped in a form the action did not recognise — and anything unrecognised is treated as a broken emulator, so a healthy game was force-closed and relaunched. The same thing happened in the Tribe Shop. Both now treat a read that did not answer as what it is: try again, leave the game alone.

An interrupted file transfer could leave an instance stuck until the next update

If the copy of the bot's helper onto an emulator was cut off partway, a half-written file was left behind. The repair added last release would have seen a file sitting there, fixed its permissions, and considered the job done — leaving that instance running a broken copy on every boot with no way back. A partial copy is now deleted rather than repaired, and the repair checks the file is the right size before it trusts it.

v1.2.22

The bot was relaunching games it should have left alone — burning more than two and a half emulator starts for every account it finished.

This one only affected some setups, and if you were on one of them you would have seen it clearly: emulators starting over and over, accounts taking far longer to get through, and the activity feed full of relaunches. Nothing was lost and no account was parked — but a lot of time was.

Emulators started over and over, and accounts crawled

The bot copies a small helper onto each emulator so it can read the game directly instead of squinting at the screen. If that copy was interrupted, the file could be left without permission to run — and nothing ever checked, so the bot believed it was there and working. Every time it failed, the bot relaunched the game to fix it, which it never could, and each failure also made it re-open its connection to that emulator, which loaded the machine further and caused the next copy to fail. On one affected setup that was 2.6 emulator starts for every account finished, against roughly one when healthy. The bot now checks the helper is actually usable, repairs it in place when it is not, and stops relaunching the game over something a relaunch cannot fix.

Memory and handles crept up the longer the app ran

Every time the app checked on its own engine — roughly four times a minute, all day — a network handle was left behind instead of being closed. It came from a bug in the Python runtime we build on, where one failing cleanup step skipped the rest. Those add up over a long run. They are closed properly now.

v1.2.21

Rebuilding or installing on an instance gave up about a minute in, on emulators that were perfectly fine.

If you tried to rebuild or install on instances and watched them fail seconds after booting — while `adb devices` and LDPlayer both showed them right there — this is why.

"Device never came online" on emulators that were running

The rebuild and install tools kept their own copy of the wait-for-emulator logic, and that copy still had a sixty-second limit that had been removed from the main path over a month earlier. Sixty seconds is below what a normal boot takes: the average is about forty, but one in ten takes sixty-five to seventy, and LDPlayer 14 is slower again. So the tools abandoned emulators that were seconds from ready — in one case at 62.6 seconds. The limit is gone; these now wait the same as everything else, and when something really is dead the log says which check proved it.

v1.2.20

Four fixes for problems the last release introduced — chiefly the Staging Post restarting games that were perfectly healthy.

If your accounts started relaunching the game over and over after the last update — or one of them got parked entirely — this release is why that happened, and it is fixed. That one was ours, and we are sorry for the disruption.

Accounts kept relaunching the game after updating

The Staging Post was treating a step that took too long as proof the game had frozen, and it had just been given the authority to act on that: it would force-restart the game, then the emulator, and eventually park the account — all on a game that was running normally. It now checks whether the game is genuinely still ticking before it makes that call, and if it is, it simply tries the step again instead of tearing anything down.

The Staging Post left quests on the board

A pass could finish and walk away with workable bounties still sitting there — quitting while your own marches were seconds from home and a slot was about to free, or waiting on a quest the game had accepted but that never actually had troops sent to it. It now follows your marches as they go out and come back, holds for a slot that is about to open, re-sends a bounty that never left, and takes one last look at the board before calling the pass done.

"Every N hours" drifted by an hour around a daylight-saving change

That frequency was measuring the clock on the wall rather than real elapsed time, so the spring change made it fire an hour early and the autumn one made it an hour late. It measures properly now, and nothing you have already set moves. Separately, when an action is held back by its schedule the log now says which rule held it and when it is next due, instead of saying nothing at all — that silence is why "my action never ran" was impossible to answer.

Account, tab and emulator names showed as a short code

The last release changed how log lines are written, and it was too aggressive with names you had typed yourself — an account, a tab or an emulator could appear in the activity feed as a short code instead of its name. They read properly again.

v1.2.19

Account tabs split your fleet into separate queues that run side by side.

The biggest release since launch. Tabs let you split your accounts into groups that each get their own workers and run at the same time, so slow accounts can't hold up the rest. Alongside them: a new Alliance Construction action, a handful of new options, and a long list of fixes.

Account tabs — one fleet, several queues

Tabs sit across the top of the Accounts screen. Every account lives in one of them, and each tab runs its own queue with its own share of your workers — all at the same time, under the one Start button. Put your rally accounts in their own tab and the farms can't crowd them out, and each tab laps on its own schedule instead of waiting on the slowest account. Main holds everything you haven't moved and is always served first. Every tab has an on/off switch, so you can park a set of accounts without disabling them one by one.

New action — Alliance Construction

Sends troops to your alliance's flags, fortresses and mines. Build mode picks the target for you and finishes whatever is closest to done. Reinforce mode lets you name the target yourself — by the bookmark your officers placed on it, or by its coordinates. You also choose how many marches a pass may send, and whether your weakest or strongest saved formations go first.

Account Switch can sign in with a different email

Tick "Change email" and the bot signs in with that account's saved credentials first, then picks your configured IGG ID out of that login's character list. The credentials come from the account's own Credentials action, so there's nothing extra to fill in.

Auto Rally gets a level ceiling and a march formation

Set a ceiling so it never starts a rally you can afford but can't win, and name which of your saved march formations to send. Leave either blank and nothing changes.

Resource Transfer runs until it is done

The one-hour cap on a transfer pass is gone — it now runs until the totals you set are actually sent. There's a new maximum run time box if you'd rather bound it.

The Staging Post is faster, and clears the board

Bounties are handled directly instead of by hunting for each pin and tapping it. The pass also collects your prestige chests and keeps going until the board is actually clear.

The installer speaks 14 languages

Every screen and prompt in the installer is translated into English, Simplified and Traditional Chinese, Hindi, Spanish, French, Arabic, Portuguese, Russian, Indonesian, German, Japanese, Thai and Polish, following whatever Windows is set to. The app itself is still English-only — and the game must stay in English, because that's what the bot reads.

BotDaddy finds LDPlayer on its own

If you'd never set the LDPlayer path, the Accounts screen was empty with nothing on it explaining why. It now detects an installed LDPlayer at startup, prefers the newest version when an old one is still lying around, and says so plainly when it genuinely can't find one. A path you set yourself is never touched.

Smaller additions

Defender Camp can now be picked as an Upgrade Building target. Importing from GnBots brings your Join Rally targets across instead of dropping them.

Fixed: the app could shut down a run that was working

When the app couldn't read the engine's status it assumed the engine had died, shut it down and closed every emulator — while the bot was still running perfectly. It now proves the engine is really gone before doing anything, and otherwise holds quietly and tells you your bot is still running. Restarting after a genuine engine restart is more patient too, and tells you the real reason if it can't.

Fixed: the Dragon Cave

Three separate problems, all fixed. The step that finds the cave was timing out before it could finish, so most passes did nothing and cost a game restart. A pass that collected a finished smelt would then refuse to start the next one. And accounts that haven't unlocked the cave burned minutes and a game restart every cycle, because a locked cave shows nothing at all — the bot now asks the game and skips it instantly.

Fixed: rallies getting stuck on the rally options panel

One unreadable entry part-way through the search abandoned the whole search, so every retry failed the same way on a page that had been open the whole time. The search also now gets the time it actually needs.

Fixed: tribe donations went to skill lines that were already full

It worked through every skill line before reaching any research line, so on most accounts the research tree was never reached at all. It now reads how full a skill bar is before spending anything on it.

Fixed: being logged out by another device

The notice sits on top of the loading artwork, so the bot kept patiently waiting for a loading screen to finish and hung there for minutes. It now notices the screen has stopped moving, reads it, and deals with it in seconds.

Fixed: two Chief's Hall problems

Past a certain level the game titles the upgrade window with the power tier your city is about to reach rather than the building's name, and the bot read that as having opened the wrong building and refused to upgrade. Separately, Academy Research could decide to upgrade your Chief's Hall as a prerequisite and simply start it, putting your builder on the most expensive building you own without being asked. That now only happens when you pick it as the target yourself.

Fixed: the rebuild tool stopped renaming instances

It declined to rename whenever more than one account was bound to an instance — which is the normal setup once you have two characters per emulator, so it quietly stopped working for almost everyone. It now uses the first account bound to the instance.

Other fixes

A frozen game spotted at the Staging Post no longer has the rest of the pass worked against it. Some accounts randomly reported having no Dragon Cave or no Skill Shop until the game was relaunched. Resource Transfer blamed its marches when it had simply run out of time. A long wait for marches to come home is no longer mistaken for a stuck instance. And three warnings that fired on runs that were going fine are quiet again.

v1.1.93

Village upgrades go to the village that needs them, not the one already ahead.

Village upgrades kept going to the same village

A Village Hall, Supply Hub or Market target is four separate buildings — one in each of your villages — and the bot was picking the highest-level one every time. That is the right choice when something in the city needs a building of at least a given level, and exactly the wrong one for a target you set in order to level your villages up: the most developed village won every cycle and the other three never moved. It now picks the lowest unlocked one instead, so your villages come up together, with ties going to whichever comes first.

v1.1.92

Two new actions, saved action profiles, and the Dragon Cave stops taking the game down with it.

Two things you couldn't automate before — paying into the alliance bank, and repairing your city wall. Alongside them: named action profiles you can switch an account between, creating accounts in bulk, groups that decide run order, and a fix for the action that was crashing the game more often than it finished.

The Dragon Cave was crashing the game more often than it worked

It picked the first item to smelt before the panel had finished drawing itself, and the game did not survive being asked. Across one full day of logs, 61% of Dragon Cave passes killed the game outright — and every single one of those failures was on the first pick, never a later one, which is the giveaway. It now waits for the panel to be built before touching it.

Resource Transfer barely sent any gold

Each march was filled one resource at a time in a fixed order, so food, wood and stone had to run completely dry before gold was reached at all — and the pass hit its hour limit long before that. With all four resources set to the same 500M, one account sent 179.4M food and 21.3M gold, and 4 of 10 passes sent no gold whatsoever. Each march is now split evenly across whatever you have configured, with anything a resource can't take handed to the others.

Every transfer march went out about 15% light

The amount staged into a march was measured against what would arrive after the alliance tax, rather than what the march would actually accept — so every cart left with roughly 15% of its space unused. No log could have shown this: an under-filled march reports a perfectly clean send. Marches now fill to their real capacity.

New action — Tribe Resource Donation

Pays food, wood, stone and gold into your alliance bank against the weekly quota. Set it to donate whatever each resource still needs, or give it your own per-resource amounts — leave one blank to skip it. It reads the remaining requirement from the bank itself, so the donation tax is already accounted for, and it never sends more than you hold. This is the alliance bank, not the tribe tech donation that lives under the Tribe action; the game gives both the same name and they share nothing else.

New action — Repair Wall

Repairs your city wall when it is damaged and off cooldown. There is nothing to configure: the repair costs nothing, the amount restored is the game's to decide, and the game itself answers whether a repair is available. It reports the durability it actually restored rather than assuming the request worked, and it runs without needing to be on any particular screen.

Switch an account between saved action profiles

An account can now hold several named action lists and swap between them in one click — a farming setup and a rally setup, say, without rebuilding either by hand. Your login details are shared across all of them, so switching never touches credentials, and an account you never make a profile for keeps behaving exactly as it does today.

Create many accounts at once

Create ▸ Multiple accounts adds a batch in a single step instead of clicking through one at a time. Creating a single account is still one click — there is no extra “how many?” step in front of it.

Groups now decide the run order, and show their combined stockpiles

Group cards and ungrouped accounts are one draggable list, so where you drag a group is the order its accounts actually run in — a group can sit between two ungrouped accounts. Expanding a group also shows its members' resources added up, and always names how many of them it could read, so a group nobody has a snapshot for says so rather than reading as broke.

Copy only the actions you pick, and import a config from an account

Bulk apply gained “Only apply selected actions”, so you can push two actions onto a hundred accounts without overwriting the rest of their setup, and it can now land a list on every target as a named profile instead of changing what they are running. The saved-config editor can also import settings straight from an account you have already tuned.

Tribe gifts and tech donation no longer walk the screen

Collecting tribe gifts used to open three tabs and the chest one at a time; it now claims the whole board in about four seconds without navigating anywhere. Tech donation had been quietly giving up on its fast path and walking the page instead on 232 of 606 passes — with 70 instances never once succeeding — because it was checking the wrong kind of ID. Those accounts had been paying for it in game relaunches every night.

Actions reported the game had refused them when it was only being slow

A request that had not finished yet was being read as a request the game turned down — 446 times in a single day's logs, every one of them a misreport, across the Dragon Cave, Skill Shop, Beast Pen and the village actions. A slow request is now waited out, and a genuine hang is reported as one instead of masquerading as a refusal.

v1.1.90

Your instances stay up — six fixes to launching and recovery.

If you set 7 or 11 instances running and watched it settle to 4 or 7, this release is why that happened. Six fixes across launching, stale connections, and recovery.

Instances kept dropping off

A single emulator that never came online froze launching fleet-wide for as long as it took to give up — in one four-hour run, that was half the run with nothing new starting. A stuck launch is now sidelined after two minutes so everything else keeps booting. It isn't punished or given up on; it just stops holding up the queue.

“Device offline” on instances that weren't even started

LDPlayer leaves a background networking process behind when an instance closes, and it keeps holding that instance's connection port — sometimes for hours. The next launch connects to a ghost and never gets a reply, which is why this got steadily worse the longer the bot ran, and why a PC reboot appeared to fix it. These leftovers are now cleared before every launch, including during Install/Update and Rebuild.

Instances that could never start because another program held their port

Some instance indexes collide with software like TeamViewer or Discord. These now recover automatically instead of failing forever — one such instance went from never booting to booting in 33 seconds.

Launch failures were silent

If an emulator simply never started, you got three minutes of nothing followed by a generic timeout. It now reports what actually happened, and says plainly when the instance isn't running.

Accounts quarantined for “out of retries” while perfectly healthy

On accounts with long action lists, three unrelated hiccups spread over an hour could stack up and retire the account even though it had completed actions successfully in between. Successful work now clears earlier strikes, so the limit means what it says: repeated failures in a row.

Wedged emulators were relaunched forever, never restarted

Some problems can only be cleared by restarting the emulator, and the recovery path had no route to one. It now alternates between relaunching the game and restarting the instance before giving up.

v1.1.89

A new Recall Troops action, plus a rebuilt Obtainables.

Recall Troops joins the action list, Obtainables moves onto direct game calls, and rally, training, village and boot detection all pick up fixes.

New action — Recall Troops

Recalls your marches on demand — everything, or a specific number — with an option to wait for them to arrive home before continuing.

Obtainables — rebuilt, more reliable

Obtainables now runs on direct game calls instead of screen navigation, making it faster and more reliable. That also fixes a bug where the bot could accidentally tap the Obtainables icon while trying to do something else entirely — claiming tribe help, say — leading to confusing follow-on failures in unrelated actions.

Rally fixes

Fixed a rare case where a rally actively out on a march could be misread as stuck, needlessly restarting its instance mid-flight. Also fixed the bot misreading your Battle Hall as level 0, which silently disabled part of the rally-arming logic on accounts with a high-level Battle Hall.

Train Troops speed fix

Fixed a slow, unnecessary step at the start of every Train pass that could cost 20–30+ seconds and, in some cases, drop the bot back to the older, slower training method entirely.

Village actions fix

Fixed Dragon Cave and Skill Shop both failing intermittently from the same underlying connection hiccup, and fixed a crash that could force-stop a healthy game while recovering from a failed Dragon Cave read.

Boot detection fix

Fixed the “waiting for game to load” step reporting an unhelpful generic timeout in some cases instead of diagnosing what actually went wrong — which in turn affected how the recovery was handled.

v1.1.88

Backend auto-recovery, plus critical Tribe Mine and login fixes.

This release fixes a critical Tribe Mine crash and a rare but serious login mix-up, and adds a self-healing backend supervisor so a frozen bot recovers on its own instead of needing a manual restart.

New — backend auto-recovery

BotDaddy's backend now has its own watchdog. If it crashes or freezes completely — which could previously leave every instance open and idle with no way to stop them — the app detects it, restarts it automatically on the same connection, and resumes your bot right where it left off. No more finding your PC idle for hours behind a frozen bot.

Critical fix — Tribe Mine crashes

Fixed a bug that could force-stop the game on a Tribe Mine pass. It had been happening silently since the recent Tribe Mine rewrite, and forced a game restart every single time it hit. Also fixed a related case where the bot could misjudge whether a mine needed reinforcing versus building, wasting a screen walk and a relaunch on gold mines that were actually fine.

Critical fix — wrong account login

Fixed a rare but serious bug where text recognition could misread two account IDs sitting close together on the login picker as one, causing the bot to log into the wrong account entirely. Login now verifies matches more strictly and logs exactly where it tapped, so this is both fixed and easier to catch if it ever resurfaces.

Diagnostics — slow screenshot warnings

“Slow screenshot” warnings now break down exactly where the delay came from instead of lumping it all together — which helps pinpoint whether it's your PC or the connection to a particular instance.

v1.1.87

Stops three actions from wasting whole cycles re-learning something they already knew.

Every fix in this release is the same mistake in a different place: the bot learned something about your account — no heroes free, every march out, a reading it could not take — and then threw that away and tried again anyway. Staging Post, Tribe Mine and Gathering all stop repeating themselves now.

Staging Post no longer retries monster quests with no heroes

When the game refused to send a march because no hero or no troops were free, Staging Post treated it as though every march slot was simply busy — so it waited, re-checked the march slots (which were free, because the problem was never the slots), and flew to every remaining monster and Niflung quest on the board to be refused all over again. On a board of nothing but combat quests that could repeat for the whole pass. It now recognises that answer for what it is, skips the combat quests for that pass, finishes any quest that does not need a march, and moves on. The activity feed tells you which of the two reasons it was.

Tribe Mine stops re-checking every resource when all marches are out

With Tribe Mine set to “Any” resource, discovering that every march slot was already out only retired the resource it happened to be on. It then walked the whole Resource Center again — tab, list, scroll, card, dispatch — for each remaining resource, to be stopped by the same full queue every time. Every march being out is a fact about the account, so it now ends the pass on the first sighting.

“Farm in tribe territory only” could silently do nothing

If the bot could not read your tribe’s territory at the moment gathering started — usually a brief hiccup just after the game loads — it correctly refused to gather (it cannot confirm a tile is inside your territory, and the in-game search cannot be limited to it) but said nothing at all. The result was a gather that ran for about two seconds, sent no marches and reported success, with free march slots sitting idle. It now retries that reading once before giving up, and if it still cannot be taken, it says so in the activity feed and tells you that unticking the option will let the account gather anywhere.

A failed territory reading no longer benches a resource for the whole cycle

Related to the above: when the territory reading failed, each resource it was checking got marked as “nothing here” for the rest of the cycle — the same way it is marked when the bot has genuinely looked and found no free tile. With all four resources hit in the same pass, gathering was skipped entirely until the next cycle. A reading that never happened is no longer mistaken for an answer, so the next gather tries those resources properly.

v1.1.86

Fixes an installer failure that blocked installing and updating.

A focused fix for the installer. If you saw “BotDaddy cannot be closed” or “Failed to uninstall old application files”, or auto-update kept failing, this release resolves it.

Installer could fail to install or update

Fixed a bug where choosing the top level of a drive (D: rather than a folder on it) as the install location produced a slightly malformed install path. The installer then failed to recognise that BotDaddy was already running, so it could not close it before updating — surfacing as “BotDaddy cannot be closed” and “Failed to uninstall old application files”, and causing auto-update to fail every time. Existing installs on an affected path are repaired automatically by this update.

Install location is now validated

The install-location page no longer accepts a bare drive root or an empty path, and browsing to a drive now produces a clean folder path.

Leftover background process cleaned up

If BotDaddy was force-closed or crashed, its background service could keep running and hold files in the install folder, blocking the next update. It is now shut down automatically on the next launch, and the installer closes it reliably.

v1.1.85

A major reliability release, led by a critical gathering fix.

This one fixes a gathering bug that could leave a worker stuck cycling one account for over 20 minutes doing nothing, plus a big batch of fixes across boot detection, resource transfer, and five recently-added actions.

Critical gathering fix — accounts getting stuck

Fixed a bug where Gathering could get stuck endlessly retrying on an account with no free march slots or an unreachable game state, running hundreds of times in a row without ever gathering or giving up — one affected account ran the check 237 times in 22 minutes. March slot availability is now checked correctly and instantly at the start of every pass, instead of being discovered the slow way mid-flight.

Boot reliability fix

Fixed an issue where the “connection trouble” recovery loop could reset its own retry counter every time a healthy frame appeared between failures. An account stuck in a repeating connection-error loop could tap the same “Wait” button dozens of times over several minutes without the bot ever recognizing it needed a full restart.

Resource Transfer fixes

Fixed three bugs that could cause Resource Transfer to silently send far less than configured — including one where sending “all 4 resources” only actually sent one, and gold could be skipped entirely even with plenty in the bank. Transfers now respect your actual warehouse balance and no longer get stuck if one resource runs out early.

Launch speed and reliability fixes

Fixed several accounts hitting a graphics-settings timeout on launch that was actually just running out of time by a slim margin. Also fixed Tavern Keeper and Skill Shop occasionally reporting shop data as briefly unavailable right after certain screens changed.

Action bug fixes

Smithy: monster kills are no longer lost when the board refreshes before rewards are claimed. Commissions: “Submit All” no longer stops the pass early while more commissions are still ready. Resource Transfer: fixed occasional failures reaching a distant tribemate. Use Buff: the bot no longer sometimes cancels a buff it had already correctly identified as active. Plus improved popup-closing reliability across several actions.

New — rally count

Auto Rally can now be configured to launch more than one rally per pass instead of just one.

v1.1.84

Routine Bug fixes and UI improvements.

This releases focuses on fixing some known bugs and issues across actions and the UI

Action Clone Bug Fix

Fixed a bug where action clone option was hidden behind the 'Send To Group' option when you right click on any action.

Action settings enable/disable bug

Fixed a bug where enabling/disabling multiple actions at once would only affect one action and the other changes would just get thrown away.

v1.1.83

New Feature - Account Groups, plus a batch of reliability fixes and improvements.

This release adds a new feature: Account Groups. It also includes a batch of reliability fixes and improvements across various actions.

New Feature — Account Groups

You can now create groups of accounts to manage them more easily. This allows for better organization and scheduling of actions across multiple accounts.

Smarter Academy Research Upgrade Handling

Research now detects Academy-level gates directly from game data. If every available research option needs a higher Academy and Upgrade Academy is enabled, BotDaddy can go straight to upgrading the Academy instead of wasting time opening and walking the research tree visually.

Cleaner Account UI

The account row avatar circle has been removed so account names have more room, and the old Windows-native dropdowns in action configs have been replaced with BotDaddy’s custom dropdowns. This fixes the ugly/unstyleable scrollbar issue and makes long options, like Tavern Keeper items, easier to read.

Direct Read Performance Fix

Fixed a major hidden slowdown in the new direct-read systems. Research and Train Troops were repeatedly re-reading internal layout data, causing huge silent delays in some runs. Research reads dropped from roughly 100+ seconds to a few seconds, and Train Troops direct reads are now much faster and better logged if they ever regress.

False ADB Conflict Fix

Fixed a rare false quarantine where BotDaddy could think dnplayer.exe had stolen an ADB port even though it belonged to the correct LDPlayer instance. Serial ownership checks now tolerate overloaded Windows command-line probes and require confirmation before failing an account.

v1.1.82

Research and Train speed fixes — a ~25x faster research pass.

Following yesterday's rebuild of Academy Research and Train Troops onto direct game calls, their first real run on live accounts surfaced two things worth fixing right away.

Academy Research — massively faster

Research was taking anywhere from ~1.5 to ~3 minutes per pass, because redundant internal lookups were repeated for every single research line on the board. The same pass now completes in about 4 seconds — a ~25x speedup.

Train Troops — also faster

Train Troops had a smaller version of the same issue, adding real and avoidable delay to every training pass. Also fixed.

Fixed: some accounts falling back to the slower method

A subset of accounts were silently falling back to the older, screen-based research method every cycle because the bot couldn't detect their Academy building. It now reads the Academy directly from account data instead, so the fast method works reliably across accounts.

v1.1.81

Train, Tribe Mine and Research rewritten — much faster.

A big reliability and speed pass — Train Troops, Tribe Mine, and Academy Research have all been rebuilt to run dramatically faster and more accurately, plus several important bug fixes.

Train Troops — rewritten, much faster

Train Troops no longer navigates screens to work out what to train — it reads and drives the game directly, making it significantly faster and more accurate at picking the right troop tier and promotions. Live-tested end to end.

Tribe Mine — rewritten, much faster

Tribe Mine now reads your tribe's mine data directly instead of navigating menus to find it — a full pass takes seconds instead of tens of seconds. It also correctly recalls your troops before attempting to build when reinforcing a mine.

Academy Research — rewritten, more accurate

Research reads and drives the game directly as well, and now claims a finished research before starting a new one so you don't lose progress. It also sends help requests to your tribe and picks the cheapest available research by time remaining.

More research fixes

Fixed a bug where the fallback search for an alternate research option almost never actually triggered, even though it looked like it should have. Also fixed a rare case where the bot could misread its own transitioning home screen as unrecognized, press Back at the wrong moment, and trigger an Android exit prompt — ending in a needless restart of a perfectly healthy game.

Commissions fix

Fixed a bug where the bot could mistake the board's Rules (?) icon for a commission and repeatedly try — and fail — to complete it, occasionally leaving the bot looking stuck on that popup.

v1.1.80

Eight new actions, plus a big batch of reliability fixes.

A massive update — eight brand-new actions, Quests folded into Dailies, a fully updated import tool, and a batch of reliability fixes across recovery, boot detection, and downloads.

New action — Beast Pen

Automatically hunts for mounts using Quick Capture, targeting Blue/Purple/Gold quality, with configurable recycling of lower-quality catches.

New action — Skill Shop

Buys skill items from the Village Skill Shop and uses your free refreshes automatically.

New action — Dragon Cave

Automatically starts material smelts in the Dragon Cave.

New action — Auto Rally

Tops up your Physical Power (energy) and configures/enables Auto Rally targets — and can start rallies on configured monster types directly, no manual setup needed.

New action — Smithy (Conquest Quests)

Automatically spawns and clears Conquest monsters for materials, claiming daily rewards along the way.

New action — Prosperity Merchant

Buys discounted resource packs from the VIP shop's Prosperity Merchant automatically.

New action — Tavern Keeper

Buys your configured item(s) from the Honey Tavern's gem shop.

New action — Resource Transfer

Automatically sends resources to a tribemate via Alliance Rss Transportation.

Quests added to Dailies

The Dailies action now also claims your finished Daily Quests and Quest tab rewards.

Import tool fully updated

The GnBots Auto Import tool now imports settings for every action above, plus Heal Troops, Staging Post, and two more Gathering options (Gather Remaining Ore, Tribe Territory Only) — so switching over brings your entire existing setup across, not just the original action set.

New — total connection loss detection

Fixed a rare but serious issue where, if your PC's connection to every running instance dropped at once (a system-level hiccup, say), the bot could quietly keep “trying again” for hours without ever flagging that something was seriously wrong — while still appearing to run normally. It now detects this specific situation and posts a clear alert telling you to restart your PC.

Action fixes

Train: promoting troops no longer accidentally promotes away troops you'd also configured to train at that same tier. Dragon Cave: the bot no longer endlessly retries — with a full game restart each time — on accounts where the Dragon Cave is still locked; it now recognizes this and skips it cleanly. Auto Rally: energy tops up first even if no rally targets are configured, so a top-up-only setup actually works. Hall of Valor: fixed the bot occasionally getting stuck when a new hero or skill reveal appeared during a summon. Tribe Mine: fixed a case where the bot could scroll to a mine, misjudge whether it had loaded, and report “no mine available” when the mine was right there.

Recovery and boot detection

Fixed an instance getting stuck relaunching into the same broken emulator when the game kept crashing right after boot — it now does a full instance restart after a second crash in the same cycle. Also fixed a rare case where the bot could spend several minutes checking on an instance that had already shut down instead of recognizing it needed a restart.

Rebuild progress and download integrity

The rebuild tool now shows detailed step-by-step progress (Preparing, Creating instance, Installing game, and so on) instead of a vague status. Also fixed a rare case where a resumed game download could silently merge with a full re-download, corrupting the file and forcing a costly redo. Plus additional reliability improvements across the newly added village-based actions.

v1.1.74

Full compatibility with the Viking Rise 1.5.140 game update.

Viking Rise's 1.5.140 update was a major one and broke advanced-feature compatibility across the board. That's fully fixed and verified end-to-end — existing instances need one quick step, below — along with more gathering fixes and much faster recovery from wedged connections.

Game update compatibility

Viking Rise's 1.5.140 update broke advanced-feature compatibility across the board. This has been fully fixed and verified working end-to-end.

Action needed on existing instances

Because of how this game update installs, you have two options to get existing instances working with the new game version: rebuild your instances (recommended — keeps disk usage low, same as a fresh install), or let the game update in place (works fine, but noticeably increases disk usage per instance). Either way you end up compatible; it's just a space-vs-convenience tradeoff.

Install reliability fix

Fixed an issue where a newer game install variant could silently disable advanced features on some setups without any visible error.

More gathering fixes

Fixed a bug where “Farm Lowest Resource” could get stuck repeatedly farming whichever resource it farmed last instead of actually tracking your lowest resource. Tile-occupancy checks are also faster, so gathering wastes less time confirming a tile before moving on.

Faster recovery from connection wedges

Fixed a case where a wedged instance connection could take several minutes to be detected and recovered from — it's now caught almost instantly.

Tribe Mine fix

Fixed the bot undoing its own scroll position while trying to locate the mine, which caused repeated wasted searches.

Staging Post fix

The bot now double-checks it's actually looking at a reward before tapping it, preventing occasional missed or wasted taps.

Fresh install language fix

Fixed a rare case where a fresh install could get stuck running in a non-English language, which broke bot detection entirely on that instance.

v1.1.73

Three new actions, plus gathering and bulk-apply fixes.

Commissions, Explorations, and Tribe Shop join the action list, gathering got a batch of accuracy fixes, and Use Buff is noticeably faster.

New action — Commissions

Fully automated: scans your commission board, hands in ready-to-submit commissions, and skips the ones still missing materials.

New action — Explorations

Sends squads to the best available island node automatically, picking the highest-grade material it can find.

New action — Tribe Shop

Automatically buys tribe shop goods up to their weekly cap, cheapest-first, using your available credits.

Gathering fixes

Fixed a bug where the bot could mistake the “Resume Search” button for the “Gather” button on an already-taken tile, causing repeated failed attempts and an unnecessary game restart. The bot now double-checks a chosen tile is still free right as it arrives instead of trusting an older reading, unrecognized dispatch failures move on to the next nearby tile instead of ending the run, and it detects another in-game message that blocks gathering in a locked map area.

Faster Use Buff

Use Buff now selects items directly instead of scrolling through your inventory, making it noticeably quicker.

Bulk apply fix

Fixed a bug where using “Apply to Selected” with the source account itself still ticked could scramble that account's action order and reset its scheduling.

v1.1.72

Village upgrades, smarter gathering, and a research fix.

The Upgrade Building action now covers Village buildings, gathering got a batch of accuracy fixes, and the bot no longer gives up on research when it just needed to scroll.

Village Building upgrades

The Upgrade Building action now supports Village buildings — Village Hall, Supply Hub, and Market — in addition to city buildings.

Smarter gathering, less wasted travel

Accounts in the same kingdom now share node data, so multiple accounts stop piling onto the same tile — no more marches arriving to an empty node because someone else got there first. Also fixed: repeated dispatches to far-away nodes when closer ones were available, a 20–30s wait that could pad some dispatches, and a case where the in-game search would occasionally grab the wrong resource type entirely.

Tribe-territory-only gathering

New option to restrict gathering to tiles inside your tribe's territory.

Research keeps looking instead of giving up

Fixed a case where the bot would get stuck and give up on research instead of scrolling left to find an earlier, unlockable tech — it now properly sweeps left when the current view has nothing available.

v1.1.70

Two new actions and faster, more reliable gathering.

Two new actions, a big gathering speedup, and fixes for LDPlayer 14 and Android 13+ notification prompts.

New action — Heal Troops

Automatically heals wounded troops at the Infirmary, with optional inventory top-ups and speedup use to finish healing faster.

New action — Use Buff

Automatically applies buff items (shields, boosts, etc.) from your inventory — correctly picks the right duration variant (8h, 24h, and so on).

Smarter, faster gathering

Gathering now reads resource node locations directly instead of relying only on on-screen search — it finds and dispatches to nodes faster and more reliably, especially on a busy map.

LDPlayer 14 reliability fix

Fixed a major issue where BotDaddy's advanced features would intermittently fail to activate on LDPlayer 14 instances, causing sporadic slowdowns and fallback behavior.

Android 13+ notification fix

Fixed the bot getting stuck in a loop between the game's notification prompt and Android's permission dialog on newer LDPlayer images — permission is now granted automatically at launch.

Stability improvements

Additional reliability fixes across boot and recovery paths.

v1.1.69

Fixes a serious instance-leak regression from the last update.

Hotfix for a regression that let instances stay booted after they were done or had failed, and support for a couple of new in-game popups.

Instance leak fixed

Fixed a major bug introduced in the last update where instances could leak and stay booted up after they were done or had failed, leading to excess RAM usage and eventually causing the host system to stop responding. Please update.

New event and notification popups handled

Added support for new event popups, and for the new game notification popup on fresh instances.

v1.1.65

LDPlayer 14 support and lower host CPU load.

BotDaddy now runs on LDPlayer 14, uses less host CPU per instance, and lands a batch of research, Staging Post, and stability fixes.

LDPlayer 14 support

BotDaddy now works on LDPlayer 14, not just LDPlayer 9.

Lower host load

Capped emulator rendering to reduce host CPU usage per instance — you can now run more instances comfortably on the same machine.

Research fixes

Fixed the bot getting stuck switching between similar research options, and fixed it giving up on locked techs instead of finding an earlier unlockable one.

Staging Post fixes

Fixed the bot getting stuck on a first-time player tutorial popup, and fixed it getting stranded on the board after a bounty round instead of properly exiting.

Stability fixes

Fixed a false alarm that could restart a healthy bot mid-way through a long action. Fixed research and upgrade actions stalling silently after a connection hiccup — they now retry automatically. Added detection for a new popup type.

Cloned actions land in the right place

Cloned actions now correctly append to the end of your list instead of jumping around.

v1.1.63

Faster input, lower CPU, and a validated production run.

A big performance and stability pass — faster taps, lighter CPU during OCR, quicker screenshots, and a real multi-hour production run to prove it holds up.

Faster, lighter input

Taps, swipes, and back-presses now go through a much faster input path, especially noticeable on instances under load. Buttons register more reliably as a result.

Reduced CPU usage

Fixed a source of unnecessary CPU overhead during text recognition (OCR) — the bot now scales to your system's core count instead of over-committing, noticeably lowering CPU usage during normal operation.

Faster screenshots

Fixed a bug where the bot could occasionally wait several seconds longer than necessary just to capture a screenshot — captures are now consistently fast.

Staging Post refinements

Fixed a timing issue where the bot could tap a building or action button before its menu had finished animating, causing missed taps. The bot no longer stops a Staging Post run early when only reward boxes are left on the board — claiming them often refreshes the board with new bounties, so it now keeps working.

Self-healing reliability

If a small internal component fails to install properly on an instance, the bot now detects and repairs it automatically instead of silently running in a degraded state.

Production validated

This build was stress-tested on a real multi-hour production run — fewer restarts, faster recoveries, and lower overall resource usage confirmed.

v1.1.60

New Staging Post action plus a big boot-reliability pass.

A brand-new Staging Post action, plus a major reliability pass focused on boot speed, recovery, and tap accuracy.

New action — Staging Post

Fully automated Staging Post bounty runs — claims rewards, dispatches marches, and works through the board for you. Tip: order it before Gathering so the monster and Niflung quests can be completed; otherwise Gathering leaves no marches idle and the bot skips them.

Faster, more reliable boots

Reworked how the bot distinguishes a broken boot from a slow one, cutting down on unnecessary instance restarts and getting accounts running faster overall.

Smarter recovery

The bot now only restarts a full instance when it's truly lost — everything else gets a lighter, faster game relaunch instead. Fixed a rare deadlock where a connection-recovery mechanism could get stuck holding the whole fleet idle. Fixed a case where the bot could mistake an Android system dialog for being "home," causing false restarts.

Research fix

Fixed an issue where unlocking a second research queue could get the bot stuck on a tutorial popup.

More reliable taps

Increased tap-hold duration for more consistent button presses, especially on slower instances — fewer missed taps.

Other fixes

Fixed several building-upgrade edge cases, resource-shortfall popup handling, and freeze-detection accuracy.

v1.1.59

Latency cut roughly 3x — the bot feels noticeably snappier.

A big latency improvement that cuts response time roughly 3x, making the bot feel about 2x quicker in making decisions, plus a few minor action fixes.

~3x lower latency

A large latency improvement lands across the board — the bot feels more responsive during actions and is expected to make decisions at least 2x quicker than before.

Minor action fixes

A few small bug fixes across various actions.

v1.1.58

Stability at high concurrency plus smarter worker assignment.

Bug fixes and stability improvements aimed at high-concurrency setups so scaling up doesn't change how the bot behaves, plus smarter worker assignment during upgrades.

High-concurrency stability

Bug fixes and stability improvements focused on high-concurrency systems, so scaling out doesn't affect how the bot works.

Fills in missing workers on upgrades

During building upgrades, the bot now assigns all available workers if one happens to be missing, instead of proceeding short-handed.

v1.1.55

Three new actions, smarter Dailies, and a big reliability batch.

This release adds three brand-new actions, merges your daily routine into a single smarter action, and lands a large batch of reliability fixes across the board.

New action — Hall of Valor

Automates your Hall of Valor summons, including free summons across each tab.

New action — Academy Research

Handles research for you, picking up where your tree left off and starting the next available tech.

New action — Upgrade Building

Automates building upgrades, including working through prerequisites.

Dailies just got smarter

VIP, Obtainables, and Hall of Valor are now merged into a single Dailies action, so you manage all three from one place. Your existing setups migrate over automatically — nothing to do on your part.

Smarter building upgrades

For accounts with several buildings of the same type (like multiple Infirmaries), the bot now picks the highest-level one instead of a random one. When an upgrade needs a prerequisite building that's busy, it searches for another path instead of giving up. And when a building is busy but Speedups are enabled, it now rides a speedup to finish the job and immediately queues the next task instead of sitting idle.

Taps that actually register

Fixed taps occasionally not registering on slower instances, making the bot noticeably more reliable at clicking buttons.

Never blindly confirms an unknown popup

The bot no longer blindly confirms a popup it can't identify — it now defaults to the safe option, preventing a rare case where an unrecognized popup could accidentally close the game.

Reliability & stability fixes

Fixed a bug where a stuck internal connection could cause repeated failures — it now recovers itself automatically, including after switching accounts. Significant improvements to connection stability mean far fewer dropped connections and false restarts. Also fixed: a bug that could lose track of pending tasks, a research bug where the bot could get stuck hunting for an alternate option, another where it misidentified which panel was open, and actions that need the home screen now reliably return there first instead of failing when left elsewhere on the map.

v1.1.48

New architecture, no more daily caps on Train and Divination.

The biggest release yet — a new architecture that unlocks a new generation of features, plus a major boost to boot reliability.

New architecture — major milestone

After a long R&D effort, BotDaddy now runs on a new architecture built with advanced, minimally invasive techniques. It's strictly read-only and changes nothing about how the game runs. This is a foundational milestone that unlocks a wide range of advanced features going forward — starting with the two below.

Train Troops & Divination — no more daily caps

Both actions now run on the new architecture instead of relying on the daily quest. That removes the daily cap on both — they can run as many times as you need.

New recovery mechanism — ADB Breaker

A new recovery system detects when connections are dropping across multiple instances at once and automatically restarts the ADB server to recover. The failure threshold that triggers it scales with how many instances you're running, so it stays reliable across different concurrency settings.

Higher action clone limits

Account Switch up to 25, Gathering up to 125, and all other actions up to 25.

Improved popup detection

Added detection and handling for additional popup types, so more interruptions are closed automatically and reliably.

Bug fixes

Fixed several bugs and added more rules and detections across Gathering, Login, and Tribe Mine to make them more robust.

v1.0.44

Smarter recovery, fewer false restarts, unstuck instances.

This is a reliability-focused release — a batch of fixes from a deep prod-log debugging session aimed at fewer false restarts, smarter recovery, and instances that don't get stuck.

Smarter recovery

When the game closes unexpectedly on a still-running instance, the bot now simply relaunches the game instead of restarting the entire instance — a faster, lighter recovery. Lost-bot situations are also diagnosed more accurately, so the right fix is applied for the right problem.

Failed accounts get another shot

Accounts that hit a snag (like a one-off boot failure) are no longer parked as dormant until you step in. They're automatically requeued for a later lap, since most of these failures are temporary. Only genuinely unrecoverable cases (e.g. game not installed) stay quarantined.

OneDrive compatibility fix

Fixed an issue where having your Documents folder synced to OneDrive could lock the bot's data files mid-sync and cause worker errors. Data now automatically steers clear of the synced folder, with existing data migrated over for you.

Faster detection of unresponsive instances

When an instance's connection goes unresponsive, the bot now detects it in seconds instead of grinding through minutes of timeouts before recovering — much less time wedged.

Better popup handling

Improved the bot's ability to escape unfamiliar event popups without getting stuck or overshooting, including handling for brand-new popups it's never seen before.

Bug fix

Fixed the Tribe Gift large chest being skipped during collection.

v1.0.39

Much smaller rebuilt instances, more reliable rebuilds.

Finally cracked how to keep LDPlayer instance sizes low when rebuilding them with the Rebuild tool — and on top of that, the Rebuild tool itself is now more reliable thanks to your feedback.

Much smaller rebuilt instances

Freshly rebuilt instances with the game installed now come in at just under 5GB — a 4GB reduction per instance compared to earlier versions.

More reliable rebuilds

The Rebuild tool has been hardened following user feedback for more consistent, dependable rebuilds.

Minor fixes

A handful of small action fixes have also been included.

v1.0.34

Faster image recognition, Rebuild tool timeout fixes.

This release is focused on more under-the-hood optimization and timeout fixes for the Rebuild tool.

Rebuild tool improvement

The rebuild tool was given revised timeouts so it performs just as well on a slow system as it would on a fast one.

Optimizations

Primary logic behind image recognition was changed, resulting in a 2.5x faster response time between detection and tapping, leading to faster action completions in development testing. Still needs to be tested by users to confirm reliability of results.

v1.0.32

Every-X-hours scheduling, better rebuilds.

This release adds a flexible new scheduling option and improves the rebuild tool, alongside some under-the-hood optimizations.

New scheduling rule — every X hours

You can now set an action to run every X hours from its last successful run, giving you finer control over how often actions fire.

Rebuild tool improvement

The rebuild tool now preserves the network settings from the instance being rebuilt, so your configuration carries over cleanly.

Optimizations

Some basic optimization of existing actions to reduce redundancy and keep things running efficiently.

v1.0.30

Auto Import from GNbots, live resource overview.

This release brings a powerful new import tool, a live resource overview, and several reliability and performance improvements.

Auto Import tool

Switching over to BotDaddy just got effortless. The new Auto Import tool automatically locates your GNbots settings file, pulls in the relevant account data, and imports everything into BotDaddy with a single click.

Resource overview

A new overview shows the combined total of each resource type across all accounts on the bot — updating live as it cycles through your accounts.

Tribe Mine improvement

The Tribe Mine action now builds the mine if it's still under construction.

Improvements & hardening

Hardened the LDPlayer boot pipeline for more reliable startups. Optimized Train Troops to find upgradable tiers faster and more efficiently.

v1.0.29

Divination, Tribe Mine Farming, saved configs, idle gaps.

This release adds two brand-new actions, two handy new features, and squashes a couple of important bugs.

New action — Divination

Automate your divination runs.

New action — Tribe Mine Farming

Farm tribe mines hands-free.

Saved Action Configs

Create and save reusable action configurations, then apply them to any account directly — no more picking another account as a source template.

Idle gap between cycles (user requested)

Set an idle delay so the bot pauses for a chosen amount of time once it finishes the current queue, then automatically resumes the next cycle.

Bug fixes

Fixed the Train Troops action. Fixed a license SSL certificate issue.

v1.0.28

Tighter startup, Train Troops live, log fix completed.

This release tightens up bot startup, finishes the logging fix from last update, and brings Train Troops fully online.

Logging fix — completed

Last update's fix for vague log lines turned out to be incomplete. It's now fully resolved — the generic "Hit a problem, restarting" message only ever appears in genuine cases where the code truly can't determine a failure reason.

Train Troops — now live

The Train Troops action is fully functional, with one caveat: it trains via the daily quest, so if that quest is already completed for the day, the action will skip training and log a clear message explaining why.

Start Bot fixes

No more limbo — the bot now validates instance selection and LDPlayer path up front, fixing the unstoppable stuck state. The "continue from last completed account" option is refreshed on every account completion, so you always see the latest resume point.

Obtainables fix

The Obtainables action no longer wastes time hunting for a button and restarting when it can't find it — saving precious runtime.

Cloning improvements

All actions are now cloneable. Cloning also includes an option to copy account credentials, carrying over email and password while leaving the IGG ID untouched (no two accounts can share an ID).

v1.0.27

Smarter gathering, clearer logs, snappier bot.

This release focuses on smarter gathering, clearer logs, and an all-around snappier bot.

Smarter tile de-duplication

Gathering now plays it safe when character recognition reads suspiciously similar coordinates on back-to-back tiles — instead of risking a duplicate, it resumes the search for a fresh tile.

Bug fixes

Fixed the Obtainable Resources action failing to run. Fixed actions that couldn't be cloned. (Only Gathering supports cloning for now.)

Clearer logs

User-facing logs are now far more descriptive. No more vague "Hit a problem, restarting" messages — you'll get a clear, specific reason for what's actually happening.

Snappier performance

Reduced latency between taps, action switching, and more. Comes with a brief peak CPU spike (~30%), but it's a short burst, not sustained load.

v1.0.26

Account switching, relocated app data, stronger LDPlayer connections.

This release introduces a major new feature alongside some important stability improvements.

New — account switching

The account switch action is now fully functional, letting you cycle between characters and accounts reliably during operation.

Relocated app data

Your app data now lives in your Documents folder for easier access and troubleshooting. Existing installs migrate automatically — no action required.

Stronger LDPlayer connections

Major improvements to connection stability with LDPlayer instances — a significant drop in failed connections, false restarts, and mid-operation bailouts.

v1.0.25

Train Troops and Account Switch enter testing.

Train Troops added (in development testing)

Action added but not yet operational — undergoing development testing.

Account Switch added (in development testing)

Action added but not yet operational — undergoing development testing.

Updates download in the background while you work. Just quit and relaunch the app to pick up the newest version.

What we shipped,and why.

v1.4.10

Viking Rise 1.5.160

Clear Villages: the friendly troops are collected directly now

The IGG Account button changed on fresh installs

The game was closing every few minutes — v1.4.8

Healing wounded troops without opening a screen — v1.4.9

Use Buff works again, and without a screen — v1.4.9

Resource Transfer stopped re-deriving something it already knew — v1.4.7

The relocator now matches the ground it is aimed at — v1.4.7

Why Train Troops was refusing on some accounts — v1.4.8

v1.4.6

New action: Mercenary Guild

New in Dailies: Distant Voyage

Resource Transfer can move the city next to the recipient first

A march that had just come home was still counted as out

Clear Villages marched away from monsters it was beating

Four of its messages named a cause nobody had measured

The Accounts screen gets out of the way on a big fleet

Gathering marched at tiles another player had already taken

Install Game said "LDPlayer path not set" on MuMu Player

A running game was relaunched because one reply came back empty

v1.4.4

Copying game files off a source works again

The instance you copy FROM grows again, once per game version

v1.4.3

Clear Villages finishes the map now, not just works on it

It stops waiting on fights that are already over

Targets are picked by what killing them unlocks

The chests the statue's last step releases are collected, not stranded

A full march queue is no longer read as an unreachable village map

Gathering stops offering a tile it is already farming

The activity log reads as English again

v1.4.0

Clear Villages — the village map, worked all the way to the Odin Statue

Mystic Realm — cleared until the account can supply resources

BotDaddy in fifteen languages — experimental, and we want to hear about it

Open Inventory — chests opened and resource items banked

Gathering spent most of its time flying the camera to tiles

Emulators opening and closing all through a rest period

'Viking Rise is not installed' on accounts where it plainly was

Accounts showing their neighbour's Chief's Hall and tribe

A whole tab skipped at start, with its accounts never queued

Resource Transfer sending nothing at all on some accounts

Tribe actions running on accounts that are not in a tribe

Tribe tech re-aimed off the leader's pick, and officers never starting a research

Alliance construction relaunching the game over a building's refusal

Upgrade Building can stop at a level

MuMu instances stuck with the game running but no window

A game hung on the IGG logo took five minutes to give up

The copy source growing 2.4 GB a run, and 'Nothing to free' on a disk that was full

The activity log repeating itself and crying wolf

v1.3.0

Run your accounts on MuMu Player

MuMu instances that never finished starting with the monitor off

A MuMu ad covering the game and swallowing every tap

Every new instance downloading 2 GB on its first login

Rename instances without a rebuild, and get disk space back on MuMu

Switching a group of accounts to another profile one by one

Upgrade Building saying both builders were busy right after starting an upgrade

Account Switch signing in to the wrong IGG account

Lost connections and 'isn't responding' popups ending in a restart

New accounts crashing right after their first login

Smithy stopping before all five monsters were done

Commissions handing in a whole stockpile, or walking you to the Exploration map

Heal, Hall of Valor, Tribe Bank and Obtainables

A once-a-day action running twice after you edited the account

Setup insisting on LDPlayer

Other fixes

v1.2.33

Auto Rally set to join just 1 rally

Initiate Rally stopped finding Lightflame Lizards

One checkbox per monster, however many times an event returns

Snaketail Beast/Darktide Warship can be joined

v1.2.31

Tribe Technology: choose the tree

A Profiles button on the Accounts screen

Right-click an account to apply or switch

Undo on applying actions

The activity feed says what actually happened

What we shipped,
and why.