LDPlayer setup for Viking Rise

LDPlayer is one of the two Android emulators BotDaddy drives. Get this part right and most automation problems never happen; get it wrong and you'll spend your time chasing symptoms.

Running MuMu Player instead? See MuMu Player setup for Viking Rise. BotDaddy runs one emulator per install, chosen in Settings → Emulator.

Install LDPlayer

Download LDPlayer from ldplayer.net and install it. Both LDPlayer 9 and LDPlayer 14 are supported — BotDaddy works out which you have from the path you give it in Settings.

Before anything else, make sure hardware virtualization is enabled in your BIOS/UEFI — without it LDPlayer either refuses to start or runs unusably slowly. If Windows is holding the virtualization layer through Hyper-V, see Hyper-V and virtualization errors.

Create your instances

Instances are created in LDMultiPlayer, not in BotDaddy. Open it from the Windows Start menu, its desktop shortcut, or the Multi-player button on a running LDPlayer window.

• New player makes a blank instance.
• Clone player copies an existing instance including installed apps. We don't recommend it: a clone can carry its original's identity over and cause login problems. Make new players instead, and let BotDaddy fill them in (below).

Instance management — Settings, Remove, Backup/Restore — is unavailable while an instance is running. Close it first.

Let BotDaddy install the game

This is the single most common avoidable setup problem. Installing Viking Rise yourself — from the Play Store, or from an APK you found — very often puts the wrong build on the instance. The bot then fails in ways that look like bot faults rather than an install problem: screens it can't recognise, actions that never complete, accounts parking themselves.

BotDaddy downloads and installs a build it knows works. Use Update / Install Game — the game controller icon on an account's row, or the same button on the bulk toolbar once you've selected several accounts.

Skip the first-login download. The first time an account logs in on a new instance, the game downloads about 2.2 GB more. In the install window, pick an instance that has already logged in under Copy game files from, and each new instance gets those files right after its install, so its first login takes about a minute and a half instead of 5 to 9.

The Rebuild tool also reinstalls the game as its last step, so a rebuilt instance comes back with the right build already on it.

Configure the instance too. Installing the game is only half of preparing an instance — the Configure / Check Instance button on the same row writes the settings BotDaddy expects (resolution, CPU, memory and so on). Do both once per instance before its first run.

Log in by hand, once

With the game installed, log in manually at least once, all the way to the city view, and get through any first-time tutorial the game insists on.

Doing this by hand once is worth it. It's the cheapest way to be certain the account is in a normal, playable state before automation ever touches it — and a half-finished tutorial is a common cause of an account that mysteriously does nothing.

Set the game to English if it isn't already. The bot reads the screen, and it reads English.

While you're there, fill in that account's credentials. They're what the bot signs back in with if the game ever logs it out.

Supported game versions

BotDaddy tracks a supported version range, and an instance outside it is parked rather than driven blind. Neither case updates itself — both tell you what to do:

• Older than the minimum — the account stops, names the installed version and the minimum, and tells you to press Update Game on that instance.
• Newer than supported — the account stops, names both versions, and asks you to keep the game at or below that build until BotDaddy adds support.

That range moves when a new game version is tested and a BotDaddy update ships, so keeping the app up to date is what keeps the range current.

Keep instance settings consistent

The bot recognises the game by what's on screen, so instances that differ from one another in resolution or DPI are instances that behave differently for no good reason. Use Configure on every instance rather than setting each one up by hand.

Performance

Every running instance is a full Android VM competing for the same CPU, RAM and disk. The single biggest performance lever is how many you run at once, not per-instance tuning — see Running multiple accounts.

An SSD matters more than you'd guess. Instances boot, load and screenshot constantly, and on a mechanical drive that's where the time goes.

If your fleet spends minutes just starting up, turn on Parallel Boot.

Rebuilding an instance

LDPlayer instances degrade. They accumulate cruft, and occasionally a virtual disk corrupts outright and the instance stops booting or starts failing in ways that make no sense.

BotDaddy's Rebuild Instances tool wipes and recreates instances with the recommended profile and reinstalls the game. It's the right answer when an instance has gone bad, and the wrong one when you haven't established that it has.

Two things to know: it is destructive — anything on that instance is gone, including the game's saved login — and it only runs while the bot is stopped. Your account bindings survive; BotDaddy repoints them at the recreated instance.

Reach for it when one instance fails repeatedly while its neighbours are fine. That asymmetry is the signal: a problem affecting every account is almost never an instance problem.

The same card can also copy game files into instances without rebuilding them (Seed Selected) and name instances after their accounts (Rename Selected). Every button is explained in the Rebuild Instances guide.

Troubleshooting

An account says the game isn't installed and it clearly is. Usually the instance's connection dropped while the bot was checking, and it retries. If it persists, run Configure on that instance, then Update / Install Game.

The game updated itself in the emulator. It may have moved past the version BotDaddy supports. The account parks with a message naming both versions rather than running against an untested build.

An account's row shows N/A for the version. The bot hasn't read that instance yet. It fills in after the account runs.

Installing fails repeatedly. Rebuild that instance. A corrupted instance is the usual cause, and the rebuild tool exists for it.