Geyser Plugin Menus: What to Test on Java and Bedrock

Before accepting a custom Minecraft plugin for a Java–Bedrock community, verify that both editions can complete the same actions, cancel safely and receive an accurate result. Connecting through Geyser and seeing an inventory menu is not enough. Agree the supported devices and input methods, then test the complete journey with ordinary player permissions.

For an owner commissioning a team selector, lobby menu or event registration feature, the deliverable should be a usable interaction on each supported client. It need not look identical. The example below is a proposed acceptance exercise, not a test performed by Mineando.

Find gestures that carry two meanings

Ask the developer to list every action hidden behind a click type, keyboard shortcut or chat interaction. Geyser's current limitations include distinguishing left and right clicks in inventories, clickable chat links and detecting typing or tab completion while the player is in the chat interface. Treat these as design constraints when reviewing the proposed interface.

A menu specification such as “left-click the banner to inspect the team; right-click to join” therefore needs another interaction path for Bedrock. Do not accept “Geyser compatible” as an answer to how players reach both actions. Ask for a demonstration from opening the menu to checking the resulting team membership.

Write down actions in player language: inspect, choose, confirm, go back and cancel. This separates the purpose of each step from the gesture currently used to trigger it. The general plugin acceptance guide covers the wider delivery agreement; this check focuses on the interface across editions.

Choose one explicit interaction design

There are three useful options to discuss before implementation:

Design	What to request	What still needs testing
Shared inventory menu	Separate selectable entries for different actions	Reachability and meaning on every supported input method
Java menu and Bedrock forms	Two interfaces calling the same application rules	Equivalent validation, cancellation and results
A documented command path	A short, discoverable alternative for essential actions	Real device usability and normal permission checks

Bedrock forms are a development option, not an automatic conversion of an existing Java menu. Geyser documents Cumulus access through Geyser or Floodgate, with SimpleForm, ModalForm and CustomForm types. Its forms documentation also distinguishes valid responses, closure and invalid responses. The developer must define the corresponding application behaviour.

Request a small prototype of the riskiest journey before building every screen. If joining a team is awkward on a controller, polishing ten more menus will not resolve that decision. A command fallback is only useful if a participant can discover and enter it on the intended device.

Record the actual support boundary

Specify the Java server build, plugin release, Geyser build and Floodgate build where used. Include proxy software and protocol translation components if present. Check the supported versions documentation when scheduling the rehearsal; save the versions actually used with the results. A previous demonstration does not establish compatibility after components change.

Name each agreed client and input combination: Java with mouse and keyboard, Bedrock with touch, and Bedrock with a controller, for example. This is a sample matrix, not a requirement to support every device. Test actual target devices where platform differences matter. A controller connected to a computer does not prove that a console participant can complete the entire connection journey.

Use the public entry route, a participant account and the languages promised for the event. Record interface scale when text readability matters. Administrator permissions and a developer's familiar shortcuts can hide a route that ordinary players cannot use.

Worked example: choose a team without accidental entry

Suppose an event has two teams. Participants may read a team's description, request entry, confirm or cancel. Teams can fill while somebody is reading the menu. The following are proposed rules to agree with the developer:

1. Opening a description changes no membership. Closing that screen also changes nothing.
2. Choosing “Join” opens a confirmation that names the selected team. The previous screen must not silently commit the choice.
3. Confirmation checks the current team capacity and the player's eligibility on the server. Information shown earlier may be stale.
4. Success appears only after the membership change succeeds. An unavailable place produces an understandable refusal and a route back.
5. Repeated input does not create a second membership or repeat a reward attached to joining.

For Java, the prototype could use separate “Details” and “Join” entries. For Bedrock, it could use buttons followed by a confirmation form. These are design suggestions, not a claim that a particular menu plugin already implements them.

Keep a before/after record of the membership during each case. If a player sees success but staff still see no team, the case fails even if the menu animation looks correct. Where accounts can be linked, add the separately agreed Floodgate identity checks rather than assuming the interface establishes which profile owns the result.

Rehearse the awkward exits

Repeat the journey on each supported combination. Close the menu before confirming, press back, reconnect with a confirmation pending, and attempt to confirm after staff close registration. Also have another participant take the last available place while the first menu remains open. Perform these exercises in a controlled rehearsal environment.

Agree the expected result for each interruption beforehand. For this example, reopening should show the current membership, and an obsolete confirmation should never bypass a closed registration or a full team. Avoid reopening a cancelled screen endlessly: the player needs a clear way to leave the flow.

Save a short screen recording, the release identifiers, the action sequence and the resulting server state for failures. A screenshot alone cannot establish whether a tap selected, confirmed or cancelled an action. Do not include private account details or credentials in evidence shared outside the team.

Make acceptance a clear decision

Approve the feature when all essential actions are reachable, cancellation is safe, the server result matches the message and the agreed device matrix has evidence. Record cosmetic differences separately. If one supported input method cannot perform an essential action, change the design or explicitly narrow the supported audience before launch.

For custom Minecraft development, bring the action list, device matrix and one worked journey to the scoping discussion. Mineando quotes paid projects individually; maintenance, future compatibility work and event coverage are agreed separately.