Tags
Creators
Details
3.2.1
Compatibility
Changes
Minecraft 26.2 and 26.3 servers can be inspected: the agent works on them, and session_start no longer fails because bots cannot join.
Nothing breaks against 3.2.0. The tools and their arguments are unchanged, and the server plugin is the same as 3.2.0's apart from its version number. Two answers change shape: session_start gains a bots object, and its minecraftProtocol is null when bots cannot join.
Added
Agent-only sessions. On a server bots cannot join, session_start used to fail outright and take logs, events and state down with it. It now opens the session for the agent tools, and bots in its response says why bots are unavailable. bot_spawn, bot_inspect, bot_view and bot_run_scenario refuse with that reason, and session_reset tries the runner again.
That is the state of 26.2 and 26.3 today. The agent was checked on Paper 26.2-134 and 26.3-200: it loads, captures events and logs, answers state queries and runs commands. Bots cannot join yet, because mineflayer and minecraft-protocol stop at 26.1. That is tracked in #4.
Fixed
Bots no longer join as 1.21.1 behind ViaBackwards. The runner pings in 1.21's protocol, and ViaVersion with ViaBackwards answers a ping in the client's own protocol whenever it can translate. On such a server bots joined as 1.21.1, through a chain of translations and with no error. Bots now follow the Minecraft version the agent reports, and when the ping disagrees session_start says so in bots.pingProtocol.
The same change covers a proxy that echoes the ping request's protocol. minecraftProtocol no longer has to be passed behind one, and it stays available as an override.
A runner that refuses to start is now reported with its reason, without the line-protocol framing around it.
Upgrading
Install as before; the server plugin can stay on 3.2.0. If you passed minecraftProtocol only because of a proxy, you can drop it. If you ran bots on 26.2 or 26.3 through ViaBackwards on purpose, pass "minecraftProtocol": 775. #4 explains what that translation does and does not show.
The 26.2 investigation in #3 by @jnelken is what this release builds on. Its probe is now part of the lifecycle test: node test/lifecycle.live.mjs <host> <port> <bot> <protocol>.
Full Changelog: https://github.com/Backas03/VitaminMCP/compare/3.2.0...3.2.1
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:6M4ubAZ5:kSpSwnFo"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:6M4ubAZ5:kSpSwnFo"
}
