Home › Wiki › Crossplay

Crossplay

Blacklight runs one server for both editions. Java connects directly, Bedrock arrives through Geyser and Floodgate, and everyone shares one world.

One server, both editions

Blacklight is a single Paper 26.2 server. Java clients connect to it directly. Bedrock clients reach the same server through Geyser, which translates the Bedrock protocol into the Java protocol, and Floodgate, which lets a Bedrock account log in without owning a Java account.

The platform numbers, each read from the build rather than from memory: api-version 26.2, built against paper-api 26.2.build.123-stable, targeting Java 25. The Geyser build that goes with 26.2 carries protocol 776 and reports the Java versions 26.1.1, 26.1.2 and 26.2, so a single Geyser build spans the versions either side of the move and no flag day was needed.

There is no separate Bedrock world, no mirrored economy and no parallel player list. You spawn in the same worlds, spend the same coins, join the same factions, read the same chat and appear in the same tab list as everyone else. A Bedrock player can own a regional shop that a Java player buys from, sit in the same faction, and stand in the same claim.

The plugin keeps its Bedrock handling in two helpers rather than duplicating it per system: one decides whether a player is on Bedrock and resolves their name, the other decides how a chat message is rendered for them. Everything else, jobs, factions, banking, forging, skills, is written once and used by both editions.

Geyser and Floodgate are soft dependencies. If Floodgate is not present, the detection helper returns false for everybody and the server treats every player as Java, which is a degraded state rather than a crash.

That is six soft dependencies and one hard one. Geyser and Floodgate sit in the soft list on purpose, so a server without them still starts.

Joining from Java Edition

Java Edition uses the default Minecraft port, so the address alone is enough.

1. Open Minecraft: Java Edition on a version matching the server, which runs Paper 26.2.
2. Choose Multiplayer, then Add Server.
3. Server Name: anything you like. Server Address: blacklight-network.de.
4. Click Done, then double-click the entry to join.

On first join the server offers its resource pack, and you should take it. The server's own settings require the pack, so a Java client that declines it or fails the download is disconnected rather than let in without it. Accepting gives you the custom models for forged tools, money notes and the rest of the custom item registry, and since the Garden shipped it also gives you the plant art: a Java client without the pack is quietly sent the plain vanilla crop in its place.

The pack declares resource format 88 for 26.2, written as a range from 84 to 88. If you have seen 101 quoted for this pack before, that was a number from the wrong register. A pack format is a bare integer and nothing in the file says which of the two questions it answers, so the project keeps the two apart by name: the pack you download is on the resource register at 88, while the server's datapacks are on the data register at 107.1. The majors never overlap, which is the whole point of splitting them.

Nothing mechanical depends on a model. Every custom item carries its identity in its display name and lore as well as in its model, which is also why the same items work on Bedrock, where the custom models do not exist at all.

Joining from Bedrock Edition

Bedrock on phone, tablet, Windows 10 or Windows 11 can add any server address by hand. This is the path that works without workarounds.

1. Press Play, then open the Servers tab.
2. Scroll past the featured servers to the bottom of the list and choose Add Server.
3. Fill in the three fields below and save.
4. Select the entry in your server list and join.

The port matters. Java uses the default port and Bedrock does not, so leaving 19132 out is the most common reason a Bedrock join fails with a generic connection error.

You do not need a Java account, a Java purchase, or a linked profile. Floodgate authenticates your Bedrock account and creates your player identity on the server. Geyser then translates every packet in both directions, which is why the first few seconds of a Bedrock join can feel slower than a Java one.

Consoles: the honest picture

Xbox, Nintendo Switch and PlayStation run Bedrock Edition, so the game itself is compatible. The obstacle is the interface. Those versions show only servers from Microsoft's partner list and give you no field to type an address into. There is no setting on our side that can add Blacklight to that list.

Route 1: a friend's Friends tab

If somebody you have added as a friend joins Blacklight from a phone, tablet or Windows Bedrock client, their session usually appears under Friends on your console. Selecting it drops you onto the server with them. The friend has to be online and in the server at the moment you look, and their privacy settings have to allow you to see and join their session.

Route 2: a DNS redirect

The other route changes the DNS servers in your console's network settings to a third party service that answers one partner server's hostname with a different address. You then pick that partner server from the featured list and land somewhere else. It works, and it has real costs: every DNS lookup your console makes goes through that service, you are editing network settings by hand, and the mapping is maintained by strangers.

Whichever route you take, you arrive as an ordinary Bedrock player. The server cannot tell a console client from a phone client and does not treat them differently.

Your name, and the leading full stop

Floodgate gives every Bedrock account a display prefix, by default a single full stop. A gamertag of Steve therefore exists on the server as .Steve. The prefix keeps a Bedrock gamertag from colliding with an identically named Java account, and it is part of the name the client itself matches.

You almost never have to type it. Name lookups go through one resolver that tries, in order:

1. the exact name you typed;
2. the same name with the Bedrock prefix in front of it;
3. a partial, case-insensitive match.

So /pay Steve 500 reaches .Steve, and so do /msg, /w, /tell, /profile, faction invites, teleporter links and market purchases. Those surfaces are on the standing test list precisely because the prefix must not break them.

Two places show the prefixed form on purpose. Nameplates and scoreboard entries use the full name including the prefix, because that is the string the client matches; an entry added under the stripped name would match nobody and the suffix would silently vanish. Where a screen wants a clean label instead, the display helper strips the prefix for presentation only.

Screens: forms, chests and commands

A screen can reach a Bedrock player in three ways, and most systems use more than one.

• A native Bedrock form. Built from the same view model as the Java screen and sent to your client as a real Bedrock menu. Forms are lists of buttons, so all of a row's detail is folded into the button label; Bedrock has no hover tooltip to put it in.
• A chest GUI, translated by Geyser. Every control is an item with a name, so nothing depends on hovering. If a form cannot be sent, the code falls back to the chest screen rather than leaving you with nothing.
• A command. Every order in the game is a command you can type, and the chat lines that name commands are written so the command text itself stays readable on Bedrock.

The rule the plugin holds itself to is that a capability with no click path is not shipped. Commands are the Bedrock fallback and never the only door, and a command that needs you to type a name into a GUI does not even count as a fallback, because you cannot type inside a GUI.

Help is a screen now, and the words are still there

Help used to be the one surface that broke the rule above. A command would open a screen when you typed it bare and print a wall of chat when you added help. An audit went through all 64 command blocks and classified every player-facing one: three whose help was already a screen, twenty-one whose bare form opened a screen while its help printed text, and thirty-four that correctly have no help surface at all, such as /ping, /pay and /msg, where a help screen would be worse than none.

Nineteen were converted in one pass. /x help now opens the same screen the bare command opens, which on Bedrock means a native form where the command has one and a chest GUI completed end to end where it does not. Two doors are still listed as pending.

The words were not deleted. /x help text prints exactly the lines the command printed before, out of the same supplier, and there is one spelling of that token across the whole plugin so no command invents its own. It is the path the console takes, because a console has no inventory, and it is there for a player whose screen did not open or whose subsystem is switched off. text also tab-completes on /farm, /apiary, /effects, /gardenshow, /grove, /gardencodex and /bank; three of those had no completion at that depth at all before.

Some answers stay in words on purpose. An unknown verb such as /apiary xyz still answers in chat, because a typo is not a request for a screen, and /faction help with no faction does the same, since a hub with nothing in it helps nobody.

Chat, clickable text and typeable commands

Every player-facing message on the server goes through a single messaging funnel. Java clients get the full interactive component with click and hover intact. Bedrock clients get the same text with the click and hover parts stripped, because those affordances either do not exist or do not survive translation.

That stripping is why command links are written the way they are. When a message offers you a command, the visible text is the command itself, wrapped in the click behaviour rather than hidden behind it. On Java you click it. On Bedrock the wrapper is removed and you are left with a clean line you can type or copy.

The failure mode this avoids is a label like [Accept] with the command tucked inside the click attribute. Strip the attribute and the command disappears, leaving a Bedrock player a word that does nothing. Faction confirmations, invite prompts, war and peace requests, help screens and vote links all follow the visible-command pattern, and vote links in particular are clickable on Java and plain text on Bedrock.

Two more details worth knowing:

• Server-wide broadcasts are sent per player rather than once to everyone, so each client receives the version built for its edition.
• Action bars carry no click or hover to begin with, so they read identically on both editions. Several confirmations are deliberately routed there for that reason.

What looks different in the world

Some visual effects do not survive protocol translation. Where that happens, the plugin adds a second cue that Geyser does carry, rather than letting the feature read as broken.

Ore Pulse and Relic Sense

The Miner's Ore Pulse (sneak and right-click with a pickaxe) scans a cube once on activation and marks the ore it finds. On Java the marks are glowing block outlines, colour-coded by ore. Geyser cannot reliably translate that glow colour, so on Bedrock the outline may not appear at all. The guaranteed cue on both editions is colour-matched dust particles at each marked block, and Bedrock also receives a chat radar listing what was found.

The scan has hard limits on both editions: radius 10 by default (15 with the Geomancer mastery), a cap of 40 highlighted ores, and a duration of 5 seconds. When the cap is hit, the scan stops there and the action bar and radar say so. Markers are cleared on expiry, on re-cast, when you quit, when you change world and on shutdown, so nothing is left glowing behind you.

The Archaeologist's Relic Sense (sneak and right-click with a brush) works the same way over the vanilla archaeology blocks, with sand-yellow for suspicious gravel and suspicious sand, and aqua for decorated pots. Those are the targets it has, and they are the same ones the profession earns from. It also gives a Bedrock chat radar, and it does not burn its cooldown when it finds nothing.

Item models

Custom item models are a Java-only mechanic. Bedrock clients receive the resource pack through Geyser, but the string ids the models key off do not exist on Bedrock, so a Bedrock player always sees the vanilla model regardless of whether the pack was accepted. Nothing mechanical depends on the model: forged tools, money notes and enchanted books carry their identity in name and lore, which render everywhere.

What Bedrock falls back to is not left to chance. All 99 base items in the pack declare the vanilla model verbatim as their fallback, so an unrecognised custom item renders as the sensible vanilla item it was built on rather than as a missing texture. The all-buildable self-check over the custom item registry reads 129/129.

The Garden on Bedrock

The Garden added a whole growing layer, and all of it is legible on Bedrock, but almost none of it through a model. Two mechanisms carry it, and both send their result to one viewer as a client-side illusion that changes no world state.

Custom blocks declare what Bedrock sees. A custom block is hosted on a note block, and a Bedrock client reads nothing of our pack, so each one has to name a vanilla block that stands in for it. That name is declared, never derived, and it has no default, because what a Bedrock player sees cannot be guessed from anything else: the Planter Box declares minecraft:composter, the Garden Trellis declares minecraft:oak_fence. Registering a block without naming one is a compile error rather than a report at start-up. The stand-in is re-sent at the three moments the real block would otherwise show through: when the chunk reaches you, when a break is cancelled, and when an interaction is denied. Without the second of those, a Bedrock player would watch their trellis turn into a note block by hitting it.

Plants and grove centres are painted per viewer. A planted crop sits on a reserved block state that the pack paints as the species. Bedrock has no pack, so a Bedrock player is sent the plain vanilla crop in its place; a grove centre shows an oak sapling the same way. The decision is one small function of three facts, and its very first line answers "no pack" for anyone on Bedrock, before anything else is considered. The natural mistake is to weigh the server's pack requirement first, since a Bedrock client on a server that requires a pack does receive a pack; that ordering was deliberately broken during review to watch the check fail and name the case.

One consequence is worth stating. Java players had a race at join: chunks arrived before the client's pack status did, so everybody was painted the vanilla stand-in, and nothing existed that would ever paint it back. That is what produced the reports of plants which only took their texture after a right-click or a growth tick. For Bedrock, nothing changed, because the answer for Bedrock was already correct and is permanent: you see the right vanilla stand-in from the first frame and are never repainted.

All of that is appearance. Yield, quality, genetics, pollination and growth time are read from the plot record and are identical on both editions, and identity lives in the name and the lore. The growing itself belongs to The Garden and Garden plants.

Holograms and graves

Floating text and armour stand displays sit at slightly different heights on the two clients. Graves already correct for this: the grave display offset is adjusted for Bedrock players so the marker lines up with the grave instead of floating above or sinking into it. Other holograms, such as regional shop signs, can still sit a little differently on Bedrock than on Java.

Known rough edges

Parity is a target, not a finished state. These are the gaps the project has written down rather than papered over.