Minecraft client help

Minecraft 26.1.2 changed how items and blocks register. Both Item.Properties and BlockBehaviour.Properties now require .setId(ResourceKey) to be called before the object is constructed. A jar built against an older Minecraft throws during registration, usually before the main menu appears.

Fix: use a mod jar built for 26.1.2, and make sure Fabric API is the matching +26.1.2 build. Mixing a new mod with an old API produces the same symptom.

Mixins are compiled against exact method signatures, so they break when the target class changes between versions. If the stack trace names a mixin class, the mod was built for a different Minecraft than the one you are running.

A known trap in this mod: @Shadow on an inherited method does not resolve reliably. The stable pattern is one generic ScreenMediaButtonsMixin using instanceof checks rather than one mixin per screen class.

Almost always the wrong folder. Fabric reads .minecraft/mods for the profile you are launching — if you use a custom game directory in the launcher, that is a different mods folder.

Also confirm you copied the built jar and not the -sources or -dev one that Gradle also produces.

That is Minecraft's missing-texture placeholder. Each item needs a client item definition JSON in assets/modid/items/. If you built from source and the resources did not get packaged, every item renders like this.

It is cosmetic — the mod still works — but it means the resource pack side of the jar is incomplete.

Two mixins are injecting the same buttons. Older builds shipped PauseScreenMediaButtonsMixin and TitleScreenMediaButtonsMixin alongside the generic one. Removing the duplicates and keeping a single registered mixin fixes it.

Open build/reports/problems/problems-report.html in a browser. Gradle writes a structured report there that is far clearer than the terminal spew.

When packaging source to share, send only src/ plus the three root Gradle files:

The website opens a TCP connection to 127.0.0.1:9010 every 5 seconds and sends {"type":"ping"}, expecting {"ok":true,"type":"pong"} back. Disconnected means that failed.

1. Is the website server running? Its console should show [bridge] listening on 127.0.0.1:9010 at startup.
2. Is something else on port 9010? Only one process can hold it.
3. Is Minecraft on a different machine? Then 127.0.0.1 is wrong — change bridge_host in config/config.json to a reachable address and allow the port through the firewall.

A disconnected bridge does not break the website. The arcade, calls and chat all keep working; only Minecraft-to-web events stop.

You do not need Minecraft to check the bridge. Any TCP client works:

If you see the hello line, the bridge is fine and the problem is on the mod side. If the connection is refused, the server is not running or the port is wrong.

Fire-and-forget clients that connect, write, and disconnect can only send. To receive pushed events you have to register and keep the socket open:

After that, keep reading. Pushed events arrive as additional lines whenever they happen. Full detail is in the protocol docs.

Classic symptom of assuming exactly one reply per request. Once you register, the server can write unsolicited lines at any time — an incoming call, for example — so a reader that pairs each line with the last request it sent will drift permanently out of step.

Read lines in a dedicated loop on its own thread and dispatch on the type field. Never block the Minecraft client thread on socket I/O.

Link from the Minecraft tab on your dashboard, not from inside the game. The website is the source of truth for the mapping.

The Minecraft username you enter must match the one the mod registers with, or the site will not know where to send in-game events. Matching is case-insensitive.

Three things all have to be true:

• The mod is connected to the bridge right now
• It sent register with a username, and kept the socket open
• That username matches the site account you are calling

When the push succeeds, the caller sees "Also rang them in Minecraft" in the call log on the calls page. No message means no registered client matched.

In-game voice uses javax.sound.sampled for device enumeration and audio I/O, relayed through the server connection rather than peer to peer. If Java picks the wrong input device, you get silence or a very low level.

Browser-to-browser calls on the calls page are a separate path using WebRTC, and are the better test of whether your microphone hardware is fine. If the browser call is clean and the in-game one is not, the problem is Java device selection, not your mic.