3.0.0

Full Changelog: 2.2.0...3.0.0

2.2.0

Full Changelog: 2.1.1...2.2.0

2.1.1

Full Changelog: 2.1.0...2.1.1

2.1.0

Full Changelog: 2.0.0...2.1.0

2.0.0

Full Changelog: 1.5.1...2.0.0

1.5.1

Full Changelog: 1.5.0...1.5.1

1.5.0

Full Changelog: 1.4.2...1.5.0

1.4.2

Two MCP sessions can now drive one server. Both failures below showed up the same way — one session worked and the other appeared not to connect — and neither said why.

Fixed

wait_for starved every other client. The agent served requests from four threads, and wait_for sits on its thread for up to a minute while a condition comes true. Four concurrent waits therefore held every thread the agent had, and each further request — from any session — queued until one finished. A second session's call never returned and its MCP client timed out.

Measured against a real agent, four waits in flight:

	idle	four waits running
before	0.08s	28.01s
after	0.08s	0.00s

Waits now run on a pool of their own, bounded at 32. Past that a caller gets 429 and a message saying so, rather than joining a queue and later reporting a timeout it never spent waiting.

A bot name already on the server evicted whoever held it. A bot's UUID is derived from its name — that is what makes Tester1 the same player every run — so two sessions using one name are one player, and the server admits a player once. It resolves the clash by taking the newcomer and kicking the incumbent.

Which side lost was a race. Often the second bot_spawn was rejected; sometimes it won and the first session's bot vanished with nothing reported, its own bot_spawn having already returned success.

bot_spawn now asks whether that player is online before connecting and refuses if so, leaving the existing bot alone. A rejection that still races through explains itself instead of arriving as the bare translation key multiplayer.disconnect.duplicate_login.

Upgrading

Give each session its own bot names. Lobby_Tester1 and Survival_Tester1 rather than Tester1 twice. Names are identities here, so sharing one across sessions was never going to mean two players — the difference is that it now says so instead of quietly dropping one.

Nothing else changes. session_start was never the problem: two of them against one agent both return in 0.53s, before and after.

1.4.1

A patch release over 1.4.0. If you are on 1.4.0, take this one — its jars are otherwise identical.

Fixed

initialize reported the wrong version. serverInfo answered 1.0.0-SNAPSHOT, hardcoded, and wrong since 1.0.0. It is what an MCP client displays for this server, so the one place you could read the version was the one place that never got updated — 1.4.0's own jar still calls itself 1.0.0-SNAPSHOT.

The number now comes from the jar manifest, which Gradle fills from the project version, so there is no second copy to forget. Running from a directory rather than a jar — an IDE or a test run — reports dev.

Upgrading

Replace the three jars. Nothing else changes: no tool, parameter or behaviour differs from 1.4.0.

Everything in 1.4.0 — several sessions at once for proxied networks, and the resource-pack hang fix — is in this release too. Read those notes if you are coming from 1.3.0.

1.4.0

Several servers at once. A BungeeCord network is more than one server, and until now connecting to the second one disconnected the first one's bots.

Added

session_start can be called more than once. Sessions coexist under a name, and starting one never disturbs another:

session_start {"session": "lobby",    "port": 25577, "mcpPort": 25585, "token": "..."}
session_start {"session": "survival", "port": 25577, "mcpPort": 25586, "token": "..."}

port is the proxy's port in every session — that is where a real player connects, and bots are real players. What distinguishes them is mcpPort, the agent inside each backend server. The default name is host:port@mcpPort for exactly that reason: behind a proxy every session shares host:port, so a default without the agent port would collapse the whole network into one entry.

Every other tool takes session. bot_spawn, bot_inspect, bot_run_scenario, and the proxied agent tools:

bot_spawn    {"session": "lobby", "name": "Tester1"}
command_exec {"session": "lobby", "command": "send Tester1 survival"}
state_query  {"session": "survival", "kind": "player", "target": "Tester1"}

Omit it and it resolves only while one session is open. With several it is an error naming them, rather than a guess — the sessions of a network differ by which backend they observe, so picking one for you would send a command to the wrong server and report success.

session_reset gained close. Each session holds a bot runner process, so there has to be a way to release one you are done with:

session_reset {"session": "survival", "close": "true"}

Fixed

A server that pushes a resource pack hung the bot until the login timed out. The push happens during the configuration phase and it is a configuration task: the server's queue does not advance until the client says what became of the pack. MCProtocolLib answers the other blocking packets of that phase for us — keep-alive, known packs, finish-configuration — but not this one. So the bot said nothing, the join packet never arrived, and connect() spent its full 30 seconds before reporting "did not reach the world" for a server that was only waiting for an answer it was owed.

Measured against Paper 1.21.8 with resource-pack set:

before	30.36s, did not reach the world within PT30S
after	1.07s, Tester1 joined the game

The bot declines the pack, because that is the true statement: it has no renderer and downloads nothing. Custom model data — the one pack-dependent thing a test asserts on — arrives in the item either way, so menu icon checks are unaffected.

Changed

Comments are now javadoc summaries only. Body paragraphs, block tags and every line comment are gone: 124 files, −3834 lines. Nothing else changed — the result was checked against a pre-strip snapshot for byte-identical string literals and identical non-comment tokens, so no behaviour moved with them.

Upgrading

Nothing to change. A single-server session_start behaves exactly as before, and tools called without session still resolve while only one is open.

If your server requires a resource pack, note that declining one marked require-resource-pack=true is a kick — the server's decision, arriving as its own disconnect reason. That is the honest outcome rather than the silent hang it replaces, but it does mean bots cannot join such a server. Turn the requirement off on your test server.