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:
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.
session_start {"session": "lobby", "port": 25577, "mcpPort": 25585, "token": "..."} session_start {"session": "survival", "port": 25577, "mcpPort": 25586, "token": "..."}