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.1.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.
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.
| Dependency | Kind | What it does here |
|---|---|---|
ProtocolLib | Hard | Required at load. The server does not run without it. |
floodgate | Soft | Bedrock login without a Java account, plus the platform detection the plugin routes on. |
Geyser-Spigot | Soft | Protocol translation and the Bedrock listener on port 19132. |
NuVotifier | Soft | Vote rewards. Degrades quietly when absent. |
Multiverse-Core | Soft | World management. |
WorldGuard | Soft | Region protection checks, consulted reflectively. |
Joining from Java Edition
Java Edition uses the default Minecraft port, so the address alone is enough.
- Open Minecraft: Java Edition on a version matching the server, which runs Paper
26.1.2. - Choose Multiplayer, then Add Server.
- Server Name: anything you like. Server Address:
blacklight-network.de. - Click Done, then double-click the entry to join.
On first join the server offers its resource pack. Accepting it gives you the custom models for forged tools, money notes and the rest of the custom item registry. Declining costs you nothing mechanically: no system on the server reads the pack, and every custom item carries its identity in its display name and lore as well as its model. The pack uses pack format 101, which is the 26.1 minecraft:select item model format.
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.
- Press Play, then open the Servers tab.
- Scroll past the featured servers to the bottom of the list and choose Add Server.
- Fill in the three fields below and save.
- Select the entry in your server list and join.
| Field | Value |
|---|---|
| Server Name | Blacklight, or anything you prefer |
| Server Address | blacklight-network.de |
| Port | 19132 |
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.
We do not officially support console joins. Both routes below are third party workarounds, they take patience to set up, and a console or partner-server update can break them without warning.
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:
- the exact name you typed;
- the same name with the Bedrock prefix in front of it;
- 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.
| Surface | What Bedrock gets |
|---|---|
Skill trees (/skill) | Native form, including Prev and Next buttons so paging works. |
| Ancient Ruins screens | Native form from the shared ruins view model; falls back to the chest screen if the form cannot be sent. |
Economy (/economy) | Native form built from the same cards, with the chest screen as fallback. |
Boosts (/boosts) | Native form, plus a chat path. |
Forge types (/forge types) | Native form and plain chat. |
| Writs | Native form. Paging is the known gap, see the last section. |
| Update delivery | Native form, and a chat line whose visible text is /updates, sent first so a failed delivery never costs you the notice. |
| Regional shop browse | A chat listing written for Geyser clients instead of the browse GUI. |
| Bank screens | Chest GUI where every action is a left click: preset amounts, plus and minus steppers, add held item. No typing anywhere. |
| Market board and listing creation | Chest GUI. Creating a listing uses a centred input slot and in-GUI price steppers instead of a chat round trip, and the item is returned to you on every close. |
| Job selection | Chest GUI. Selecting a job is a shift click on Java and any click on Bedrock. |
| Forge transfer, enchant station | Chest GUI only. Both take an item as input and a form cannot accept one; each has a typed entry point. |
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.
| Ore | Colour | Ore | Colour |
|---|---|---|---|
| Coal | Gray | Redstone | Maroon |
| Iron | White | Lapis | Blue |
| Quartz | White | Diamond | Aqua |
| Copper | Red | Emerald | Lime |
| Gold | Orange | Ancient debris | Purple |
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, with sand-yellow for suspicious gravel and sand, aqua for decorated pots and gold for treasure chests. 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.
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.
| Gap | What it means for you |
|---|---|
| The writ form does not page | It prints "Page 1 of 3" into the body and emits no Prev or Next button, so pages two and three are unreachable from the form. The skill form does emit both, which is why it is the reference. |
/updates screens have no Bedrock form | You get the Geyser-translated chest instead. Nothing is unreachable: update delivery uses the form path, and the command has a chat fallback. |
| Forms cannot take an item | Any screen that accepts an item as input is a chest GUI on both editions. That is the forge transfer screen and the enchanting station's book apply screen, each with a typed entry point. |
| Glow outlines | The Java glow colour override may not render through Geyser. The dust particles are the cue that is guaranteed to arrive. |
| Long form buttons | Button labels run up to roughly 1,600 characters because Bedrock has no hover and the detail has to go somewhere. Tall buttons are deliberate. |
| Chest GUI clicks | Click behaviour differs between editions, so every chest screen needs its own Bedrock check. Where a Java screen wants a shift click, the Bedrock path usually accepts any click. |
Much of the newer Bedrock work is marked in the project's own documentation as code-written and adversarially reviewed, but not server-verified. If a screen behaves differently from what this page describes, that is worth reporting rather than working around.