VitaminMCP

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:

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.