Bundled plugins

The bundled plugins

BakaLoader ships five small BepInEx plugins and installs them into your server at every start. They are what make the player actions, the item picker and the raised player cap work without you hunting for third party mods.

You do not install them and you do not manage them on the Mods screen. They are filtered out of the scan, and the removal dialog refuses them: "This plugin is managed by BakaLoader and cannot be removed here."

The five

Plugin	Folder in BepInEx\plugins	What it does
Commander	BakaLoaderCommander	Hosts BakaLoader's own RCON listener and answers the commands directly.
Item indexer	BakaLoaderItemIndexer	Reads the game's object database at runtime and writes BepInEx\items.json so the spawn picker knows your modded items.
Spawn helper	BakaLoaderSpawnHelper	Registers baka_spawn as a console command.
Kill all	BakaLoaderKillAll	Registers baka_killall as a console command.
Max Players	BakaLoaderMaxPlayers	Raises the player cap above the game's built in 10. Only installed once you set Max Players above 10.

The versions that ship with BakaLoader 1.1.0: Commander 1.3.1, Spawn helper 1.4.0, Kill all 1.5.0, Item indexer 1.2.0 and Max Players 1.3.0. You never fetch these yourself and you never update them yourself. Whatever the BakaLoader release carries is copied into each server the next time that server starts, so taking a BakaLoader update and starting the server once is the whole of the work. That is also how a fix to one of them reaches you, which is how the Valheim 1.0.12 spawn fix got out.

They are installed while the server is down, because BepInEx only picks up plugin files at launch. A copy that fails does not block the start. The server comes up and the feature that plugin powers is off until the next try.

Two of them report a failed install to you directly, in the condition bar and on the Mods screen: the item indexer and Max Players. A failure in the other three is in the app log only.

What stops working without each one

Without the Commander, and without the three third party mods it replaces, nothing that talks to the running server works: broadcasts, the restart countdown, heal, smite, teleport, kick, spawning, and live positions in the roster. This is what the missing mods banner on the Players screen is about.

Without the item indexer, the spawn picker falls back to a bundled vanilla item list. Modded items and creatures are missing, and so are mod supplied display names.

Without the spawn helper, spawning is broken unless the Commander is present, which it normally is. The alternatives both fail on a dedicated server: one crashes because there is no graphics device, and the vanilla command needs a local player, which a headless server does not have. Both it and the Commander build a spawn the same way, and both of them were broken by the Valheim 1.0.12 update until 1.0.9, which is the next section.

Without kill all, baka_killall is not available from the game's own console. The Commander still answers it over RCON. The two carry the same sparing rule now, players, tamed creatures and the Players, AnimalsVeg, Dverger, PlayerSpawned and TrainingDummy factions, so it does not matter which one answers. They used to disagree, and the console route killed pets the RCON route spared.

Without Max Players, the server runs at the game's own cap of 10.

Max Players can also be present and still decline to do anything. If the game's code is not the shape its patch expects, it refuses rather than guessing, and prints one fixed sentence on the server's own output:

BakaLoader Max Players: this server keeps the vanilla limit of 10 players for this start. The number saved in the settings is not in force.

BakaLoader watches for that sentence and raises it as a warning on the Log screen, through the same channel a plugin that failed to install uses, so it is not lost among BepInEx chatter:

Max Players could not be raised on this build of the game, so this server keeps the vanilla limit of 10 players. The number saved in the World hall is not in force for this session.

The World hall is the Settings screen. Both lines are worth knowing, because the number in that box is what you asked for, not proof it took effect. Filter the log to Warn after a start, or search it for "vanilla limit", if the cap looks wrong.

What the Valheim 1.0.12 update broke, and how it is fixed

Valheim 1.0.12 moved one member inside the game. PlayerProfile.s_bypassCheatChecks had been a static field and became a static property of the same name and the same type. From the outside nothing about the game looks different, and nothing about the game is wrong.

Both spawn plugins read that member to decide whether to stamp a freshly made object with the game's own cheated flag, which is what the vanilla spawn command does. They had been compiled against a field, and a compiled field read aimed at something that is no longer a field is not the sort of thing Mono skips quietly. It raises a missing field error while it is preparing the method that holds the read, and that method is the caller, one step above the method with the guard around it. So the guard never fired, and the spawn loop stopped after its first object.

What a host saw was a spawn that half happened. Six meads asked for and one mead on the ground. A two star boar asked for and a plain boar standing there. Everything at base quality with no level. The app said it had worked, because until 1.0.9 it took any reply at all as a success. The reason was in the server log the whole time, a "Field not found" line, once per spawn.

Since 1.0.9 both plugins ask the assembly that is actually running what that member is today. They look for a property first, then a field, they remember the answer, and if it is neither they return false, which marks the object cheated, which is exactly what the game does for itself when the bypass is off. Neither plugin carries a compiled reference to the member any more, so this shape of game change cannot take spawning down again.

The plugins were rebuilt against 1.0.12 for the release and they go into each server at its next start. There is nothing to install by hand and nothing to clean up.

The check that would have caught it

The build now carries a test that reads the five shipped plugin DLLs and resolves every member they name into the installed game's own assemblies. If one of them names something the installed game no longer has, the build fails, before there is a release for anybody to download.

The part that matters is that it checks the kind and not only the name. A field reference has to resolve to a field. A property wearing the same name is a failure, because that is exactly what happened here, and a check that only asked whether the name still existed would have waved 1.0.12 straight through.

It needs a dedicated server on the machine to resolve against. On a machine with none it writes "SKIPPED: no Valheim dedicated server Managed folder found" into the test output and passes rather than failing somebody's checkout, on the principle that a gate which checked nothing must not look like a gate that passed.

How BakaLoader talks to the server

BakaLoader talks to the server over Source RCON on 127.0.0.1 at the port in your settings, 25575 by default.

The server side of that is a plugin BakaLoader installs, the Commander, which hosts its own listener and answers the commands directly. Its config is rewritten from your settings at every server start. If a third party RCON mod has the port first, the Commander logs that and stays dormant, and the other one serves the requests, because both speak the same protocol.

A fresh connection is opened per command, because the listener closes the socket after every response. Connect and read both time out after 5 seconds. Commands are serialised, one at a time, since two overlapping callers would cut each other's socket.

Text on the wire

Both ends of that channel spoke ASCII until 1.1.0, and ASCII has no room for anything past the first 128 letters, so everything else arrived as a question mark. That is what turned a player named in Cyrillic, Japanese or Chinese into ??? in the roster and took the accents off Latin names. It also broke the actions aimed at those players, because the name BakaLoader sent back for a kick or a teleport was the question marks, and they match nobody.

From 1.1.0 the packet body is UTF-8 with no byte order mark, on both sides, and the length field in the packet is counted in bytes rather than in letters, because a letter outside the first 128 is two or more bytes and the length is what the reader at the other end trusts.

The server half of that is the Commander, which goes to 1.3.1 for it and is replaced at your next server start. Long replies are still split into packets of at most 4000 bytes, and a split now walks back to the last whole letter rather than cutting one in half: a byte of the form 10xxxxxx continues the letter before it, so a chunk must never begin with one. It gives up three bytes at most to find the seam, and the bytes either side are passed on as they are rather than decoded and re-encoded around it.

Plain English is byte for byte what it always was, so nothing that already worked changes.

Features that need RCON: every player action, in game broadcasts, the restart countdown announcements, live positions, and the console line on the Log screen. Player names, platforms and join and leave events do not, since those come from the log.

What the Commander plugin exposes

BakaLoader ships BakaLoaderCommander, which hosts its own Source RCON listener and answers a fixed set of commands directly against the game API. It replaces the third party trio of AviiNL-RCON, JereKuusela-Server_devcommands and JereKuusela-Rcon_Commands, which BakaLoader used to require.

The commands it answers natively:

broadcast center <message> shows a banner to everyone online. Also accepts side, topleft and top_left.

playerlist returns one line per connected player as {name}/{hostId}/{charId} (x, z, y). That exact format is what BakaLoader parses for positions, so it matters.

dmg <player> <amount> damages a player, or heals them if the amount is negative.

tp <player> <x,z,y | player> teleports a player to coordinates or to another player.

kick <player | hostId> disconnects someone.

baka_spawn <prefab> <x,z,y> [amount] [level or quality] spawns a prefab. Amount still clamps to 1 to 9999 and the fourth number still clamps to 0 to 10. What 1.0.9 changed is what that fourth number means, and it now carries the same two meanings the game's own spawn command gives it: on a creature it is the star level and it counts from 0, so 0 is a plain one and 2 is a two star; on an item it is the quality and it counts from 1, so 1 is a base item and 3 is a quality 3 tool. 0 leaves both alone. Spawned objects get the game's own cheat marking.

baka_killall kills every hostile character, sparing players, tamed creatures and the Players, AnimalsVeg, Dverger, PlayerSpawned and TrainingDummy factions.

Anything it does not recognise is forwarded to Console.instance.TryRunCommand with silent fail and the allowed check skipped, so a devcommands mod is not needed for the rest.

What the spawn plugins do with the fourth number

The Commander and the spawn helper finish a spawned item the same way, so it does not matter which of the two answered.

Quality is written first and durability after it, because the maximum durability of a piece of equipment grows with its quality. Done the other way round, a quality 4 axe would be handed out with quality 1 durability and arrive visibly worn.

The quality is clamped to that item's own maximum rather than to the vanilla 4, so a modded item that goes to 6 can be spawned at 6. An item whose maximum is 1, which is most things in the game, gets no quality written at all and its reply says nothing about quality, because there is nothing there to say.

An item that stacks is spawned as stacks. The number of objects is the amount divided by the stack size and rounded up, and each object takes as much of what is left as it can hold. Six meads is one pile of six. 150 wood is three stacks of fifty. Anything that does not stack, and every creature, is spawned one object at a time exactly as before.

The reply names what was actually made:

Spawned 6x MeadPoisonResist as 1 stack, placed at (…)
Spawned 1x PickaxeBronze at quality 3, placed at (…)
Spawned 3x Lox at level 2, placed at (…)

A quality that hit the item's ceiling says so, at quality 4 (the most this item allows), because a line that just read "at quality 4" after a host asked for 5 looks like the request was misread rather than met as far as the item allows. The spawn helper's console route has the same shape for a queued spawn: Queued spawn: 3x Lox at level or quality 2, placed at (…).

BakaLoader puts that line in front of you as it stands. See Players for the app side of a spawn.

How your mod could collide with it

On the port. Commander binds the configured RCON port, 127.0.0.1:25575 by default. If another RCON listener has it first, Commander's Start() throws, it logs "another RCON server likely owns it. Commander staying dormant.", and it stops. No crash, no retry. Whichever plugin won the bind serves every request. That is survivable because both speak the same wire protocol and the same command set.

On a console command name. Commander itself registers nothing with the game's Terminal. It intercepts its verbs inside its own RCON dispatch before anything reaches the Terminal. But two of the other bundled plugins do register real console commands, baka_killall from BakaKillAll and baka_spawn from BakaLoaderSpawnHelper. If you register a Terminal.ConsoleCommand under either of those exact names, you are in a double registration with them. Do not use the baka_ prefix.

Harmony targets to avoid colliding with

Commander, KillAll and SpawnHelper use no Harmony patches at all. Two plugins do.

BakaLoaderItemIndexer postfixes ObjectDB.Awake and ZNetScene.Awake. Both postfixes, both read only, so a collision is unlikely to hurt, but they are the targets.

BakaLoaderMaxPlayers is more invasive. It transpiles ZNet.RPC_PeerInfo to rewrite the admission cap constant, prefixes SteamGameServer.SetMaxPlayerCount, and transpiles ZPlayFabMatchmaking.CreateLobby and ZPlayFabMatchmaking.CreateAndJoinNetwork to rewrite the crossplay lobby caps. It only rewrites a constant whose value is exactly the vanilla one, 10 for the admission cap and 11 for the lobby caps, and logs a warning and leaves the method alone otherwise.

It also declares itself incompatible with org.bepinex.plugins.valheim_plus and Azumatt.MaxPlayerCount, because both patch the same constants. BepInEx will refuse to load it alongside either.

Max Players

It patches three places, all at plugin load, so a change to the count only takes effect at the next server start.

The admission cap in ZNet.RPC_PeerInfo is rewritten, but only if the constant it finds is still the vanilla 10. Otherwise it refuses, prints the sentence above and leaves the method alone, because something else has already changed it.

The Steam advertised capacity, through SteamGameServer.SetMaxPlayerCount, once the backend is known to be Steam.

The crossplay lobby caps in ZPlayFabMatchmaking.CreateLobby and CreateAndJoinNetwork, which are the vanilla 10 plus the server's own slot. Both now get the same number. CreateLobby was one short, so a full crossplay server had one fewer slot than a Steam one.

The three are not independent. The advertised and lobby caps are only raised once the admission rewrite has actually taken. Advertising slots the server then refuses at the door is the worst of both worlds: people see an open server and get bounced.

It declares itself incompatible with ValheimPlus and with Azumatt's MaxPlayerCount, because both patch the same constants, so BepInEx refuses to load it alongside either.

Lowering the cap below 10 works too.

Migrating off the old mod

If you used the third party MaxPlayerCount mod, BakaLoader adopts your count and takes over from it. The order matters and was wrong in 1.0.0: the bundled plugin is installed first, and only then is the old mod's folder removed. A copy that throws now leaves you with the working old mod rather than neither. Both being present for one start is safe, because the bundled plugin declares the old one as an incompatibility and BepInEx will not load them together.

The count itself is copied across before any of that, so nothing is lost if a later step fails. The old mod's DLL is locked while the server runs, so the removal finishes at the next start.

If you save a new count during that window, it can only be written into the old mod's config, since BakaLoader's own plugin is not installed yet. Whichever file was written last wins, and a tie keeps BakaLoader's. That is the fix behind the 1.0.1 note about a count saved while the old mod was still locked.

Where the plugin files live

The source and the built DLLs are in the repository under ValheimBakaLoader/Resources/, one folder per plugin, and they ship inside the release beside the app. One build script builds all five, and a verify script checks them against the live game assembly before a release: that every reference still resolves, that the console command constructor still takes the number of arguments the plugins were built against, and that the exact constants Max Players rewrites are still where it expects them. Since 1.0.9 the same ground is covered from inside the test suite as well, by the compatibility check described above, so a plugin that no longer fits the installed game stops a build and not only a release.

Questions people ask

Can I stop it installing these? Not from the app. Deleting a folder makes it come back at the next start, except Max Players, which is only installed once you raise the cap.

Do they slow the server down? The item indexer writes one file at startup. The Commander holds a socket on 127.0.0.1. Max Players changes constants once at load. None of them run per frame.

Do my players need any of this? No. All five are server side.

Valheim updated. Do I have to do anything about these? Update BakaLoader and start the server once. The release carries the rebuilt plugins and each server takes its copy at its next start. If a Valheim update ever does break one of them again, the fix arrives the same way.

I already run a third party RCON mod. Whichever binds the port first serves the requests. The Commander logs that it stayed dormant and steps aside. Both speak the same protocol.