me/wireless-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update content

Browse Source
This commit is contained in:
David Allemang
2026-07-12 19:46:46 -04:00
parent d901fc45d8
commit 6d339e1396
3 changed files with 26 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
content/interference-causes.typ
View File

@@ -8,9 +8,8 @@ generally unexpected entity spawns that mess up the ID.
== Other Entities
Recall that *any* entity spawning will increment the ID counter, and the full list of entities is
surprising. An exhaustive list is available at #link(
"https://minecraft.wiki/w/Entity#Types_of_entities",
)[The Minecraft Wiki].
surprising. An exhaustive list is available at
#link("https://minecraft.wiki/w/Entity#Types_of_entities")[The Minecraft Wiki].
In general, the solution is to spawn our item entities at nearly the same time, so there is no
chance for other entities to spawn in-between. For example, by spawning all items with droppers in
@@ -24,29 +23,32 @@ game world ("server thread") contains the item entities we care about for the pu
Wireless, as these are the entities we can detect with redstone. However, the renderer ("client
thread") *also* tracks some entities.
In versions before 26.2, there was a bug that caused the client thread and server thread to use the
*same* global ID counter. Therefore every entity might increment the counter twice: once when it
spawns in the server, and once when the client begins to track it. Because this depends on the
position and orientation of the player, and also on the unpredictable scheduling of the two
execution threads, it is impossible to truly compensate for these effects.
In versions before 26.2, there was a bug
(#link("https://report.bugs.mojang.com/servicedesk/customer/portal/2/MC-238384")[MC-238384])
that caused the client thread and server thread to use the *same* global ID counter. Therefore every
entity might increment the counter twice: once when it spawns in the server, and once when the
client begins to track it. Because this depends on the position and orientation of the player, and
also on the unpredictable scheduling of the two execution threads, it is impossible to truly
compensate for these effects.
The solution is to either use a dedicated minecraft server, so that the client and servers run in
separate processes, or install a mod which patches the game to use a separate counter for the
separate processes, or install a mod that patches the game to use a separate counter for the
client.
#todo[Singleplayer patch links][Grab links for these mods and figure out exactly which versions
they're good for.]
There are also several mods that fix this functionality in some versions before 26.2
- https://github.com/MESLewis/local-server-entity-id-fix
- https://github.com/Mikarific/EIDTracker
#todo[Singleplayer patch links][figure out exact version compatibility list.]
== Paper Servers <paper>
#todo[Paper compatibility list][Figure out which versions of Paper broke the thing.]
Most recent versions of Paper server are compatible with EID Wireless. However, Paper 1.16-1.17
included a *different* stationary entity optimization from Spigot
(#link("https://github.com/PaperMC/Paper/issues/6277")[Paper \#6277]) that corrupts this.
Most recent versions of Paper server are compatible with EID Wireless. However, there are old
versions of Spigot which include a *different* stationary item optimization which corrupts this. A
few versions of Paper erroneously included this old optimization (on top of the mod 4 optimization)
which breaks EID Wireless.
#todo[Broken Paper/Spigot code][Show the patch with the busted optimization.]
#todo[Paper compatibility list][figure out exact version compatibility list.]
== Unloaded Chunks