Client versions and Bedrock

One server, three kinds of client: the current Java client, older Java clients, and Bedrock Edition. They share worlds, players and chat. Neither of the two others is a layer on top of the Java one: each has its own table in config/server.toml, with its own port and its own answer to how old a client may be.

Java: older clients#

The server speaks Minecraft 26.3 (protocol 777) natively. A client on an older version is translated at the edge of its connection: the worlds, the entities, the plugins and the tick loop never know there is more than one version. Translation is a chain of one step per neighbouring version, so a 1.21.6 client is brought up one version at a time.

/version prints the Basalt version, the Minecraft version and protocol, and the client versions the running server accepts. The start-up line says how many older versions it translates and the oldest one:

Done (4.2s)! Java on TCP port 25565 (online-mode) with 49 older versions down to 1.8-1.8.9 (47), and Bedrock on UDP port 19132 (...).

Each translated login is logged: Steve is on 1.20.3-1.20.4 (765), translated to 26.3.

When a block or an item exists in 26.3 but not in the client's version, the client is shown something similar instead, which is all that client can draw. With name-substitutes on, what stands in is also renamed to what it really is: a 26.2 block reads as Cinnabar (26.2) in the inventory rather than Red Sandstone. An item somebody named themselves keeps its name.

Choosing which versions may join#

These keys are in [network.java] of config/server.toml.

[network.java]
backwards = "all"
future-protocols = "refuse"
snapshots = "refuse"
name-substitutes = true

The native version is always allowed, whatever the list says. Anything other than "all" or a list of numbers is refused at start: config/server.toml: backwards must be "all" or a list of protocol numbers. A number the build cannot translate is warned about and ignored: server.toml asks for protocols this build cannot translate: ....

future-protocols defaults to refuse because a newer client cannot finish joining: when versions change, the packets of the configuration phase move and every block state number changes. Letting one in means it disconnects halfway with a decoding error instead of reading why. accept and warn are there for whoever wants to try the day a version lands, and warn logs <name> is on <version>, which this build does not know. Letting them in untranslated; anything may happen.

What a refused client reads#

Write your own wording once for all of them with outdated-client in messages.toml.

Bedrock Edition#

Phones, consoles and Windows Bedrock clients join the same worlds. It is on by default, on a UDP port of its own.

[network.bedrock]
enabled = true
port = 19132
prefix = "."
protocols = "all"
future-protocols = "warn"

A protocol you list that this build cannot speak is reported and ignored (server.toml asks for Bedrock protocols this build cannot speak: ...). The start-up line shows the port, the game version and the protocols in use: Bedrock on UDP port 19132 (<game version>, protocol 1001, 2168, 2169, 2193).

If the UDP port cannot be bound the server keeps running without Bedrock and says so:

Could not bind UDP port 19132 for Bedrock. Something else is on it, which is usually the last run of this server still letting go of it: try again, or change `port` under [network.bedrock] in config/server.toml.

A refused Bedrock client reads either This server runs Minecraft <version>. Update your game and come back. (too old) or This server runs Minecraft <version> and does not speak your version yet. (too new). The log has A Bedrock client on protocol N was turned away: ...; with future-protocols = "warn" it has A Bedrock client on protocol N is newer than this server speaks and was let in anyway; it may not get far.

How Bedrock players appear#

• A player's name inside the server is the gamertag with prefix in front, in lists, chat, commands and the log.
• Their UUID is derived from the XUID of their account, in a space of its own, so it never collides with the offline UUIDs Java derives from a name.
• The server list entry that a Bedrock client sees comes from the same server_list.toml profiles: the MOTD becomes its two lines, and the counts are the online and maximum player counts. In a condition, %basalt_player_host% is bedrock for such a ping.
• The tab list header and footer are Java only, because Bedrock has nowhere to put them.

What is not the same#

The whitelist, the bans and the player limit are checked when a Java client logs in. Bedrock players are admitted without those checks, so /ban, /whitelist and max-players do not keep a Bedrock client out. If you rely on them, set enabled = false under [network.bedrock].