U
/u/cocco1c
Guest
Posting this mostly because the disable path is the part admins actually care about, and I would rather you hear about it from me than find it in a log.
I maintain OptiPlus Anchor, a client-side Fabric mod with about 19k downloads. When a player sets off a charged respawn anchor, it clears the block to air on their client immediately instead of waiting for your block-update packet, so the spot is free to build on again without the round-trip stutter. There is a smaller companion mod that does the same for end crystal placement.
Worth being precise about what that does and does not mean. It is latency compensation, not automation - no auto-clicking, no reach changes, no altered timings on the wire. Your server stays authoritative for every outcome. If you reject the interaction, it is still rejected; the client just showed a provisional result in the meantime and reverts it.
If you would rather not have it on your server, it is one plugin message on player join. The payload body is ignored, only the channel identifier matters:
- optiplus:disable - disables both
- optiplus-anchor:disable - anchor only
- optiplus-crystal:disable - crystal only
Paper/Spigot, registered once and sent on join:
server.getMessenger().registerOutgoingPluginChannel(plugin, "optiplus:disable");
player.sendPluginMessage(plugin, "optiplus:disable", new byte[0]);
The flag lasts for that session and resets on disconnect, so it needs re-sending on each join. Velocity and BungeeCord can forward the same channel to the backend.
Anchor: https://modrinth.com/mod/optiplusanchor
Crystal: https://modrinth.com/mod/optipluscrystal
Happy to answer questions about exactly what is and is not predicted. If there is an opt-out mechanism you would rather have than a plugin channel, I am open to adding it.
submitted by /u/cocco1c
[link] [comments]
Continue reading...
I maintain OptiPlus Anchor, a client-side Fabric mod with about 19k downloads. When a player sets off a charged respawn anchor, it clears the block to air on their client immediately instead of waiting for your block-update packet, so the spot is free to build on again without the round-trip stutter. There is a smaller companion mod that does the same for end crystal placement.
Worth being precise about what that does and does not mean. It is latency compensation, not automation - no auto-clicking, no reach changes, no altered timings on the wire. Your server stays authoritative for every outcome. If you reject the interaction, it is still rejected; the client just showed a provisional result in the meantime and reverts it.
If you would rather not have it on your server, it is one plugin message on player join. The payload body is ignored, only the channel identifier matters:
- optiplus:disable - disables both
- optiplus-anchor:disable - anchor only
- optiplus-crystal:disable - crystal only
Paper/Spigot, registered once and sent on join:
server.getMessenger().registerOutgoingPluginChannel(plugin, "optiplus:disable");
player.sendPluginMessage(plugin, "optiplus:disable", new byte[0]);
The flag lasts for that session and resets on disconnect, so it needs re-sending on each join. Velocity and BungeeCord can forward the same channel to the backend.
Anchor: https://modrinth.com/mod/optiplusanchor
Crystal: https://modrinth.com/mod/optipluscrystal
Happy to answer questions about exactly what is and is not predicted. If there is an opt-out mechanism you would rather have than a plugin channel, I am open to adding it.
submitted by /u/cocco1c
[link] [comments]
Continue reading...