Bedrock players reach a Paper server through Geyser, which translates Java protocol into Bedrock protocol. Most of PolaroidMail survives that untouched — the inbox, the items, the mailbox block, the chat. Two things do not, and both are handled automatically.
Install Floodgate on the server and nothing else is needed. Without it the plugin still runs; Bedrock players just get the Java screens, which is where the trouble starts.
Paper's dialog API has no Bedrock equivalent. A Bedrock player shown one sees nothing at all — not a broken screen, an absent one. That affects the two dialogs this plugin uses:
| Java | Bedrock |
|---|---|
| Write-a-letter dialog | A native custom form |
| Read-a-letter dialog | A native simple form |
The forms read their labels from the same menus.yml nodes the dialogs use, so a translated
config translates both. Bedrock forms are plain text, so colour codes in those labels are dropped
rather than shown as tags.
Bedrock has exactly two chest screens: single (27 slots) and double (54). Nothing in between.
The compose menu is 5 rows — 45 slots — and Bedrock cannot draw that. It arrives cut off, which on that particular screen means the attachment slots are missing while the button below them is still there. That is the "menu is incomplete, I can't add items" report.
A Bedrock player is therefore given 6 rows, whatever menus.yml says. The slot numbers do not
move, so the layout is the one you configured with an extra row of filler below it. Java players
get exactly what the config asked for.
The inbox is already 6 rows, which is why it never showed the problem.
/mail → drop items in the chest → "Write letter" → a Bedrock form → Send
Same steps, same result. Two differences worth knowing:
Bedrock players fall through to the Java screens. Chests mostly work; dialogs do not. If your server has Bedrock players, install Floodgate.
Every Floodgate call is guarded, so a version mismatch or a failed API lookup logs a warning and falls back rather than breaking the plugin.