update content

This commit is contained in:
2026-07-12 19:46:46 -04:00
parent d901fc45d8
commit 6d339e1396
3 changed files with 26 additions and 22 deletions

View File

@@ -4,7 +4,7 @@
#diorama(
orbit: false,
"
"
p 0 0 0 dropper facing=up triggered=false
p 0 1 0 dropper facing=up triggered=false
p 0 2 0 dropper facing=east triggered=false
@@ -16,6 +16,8 @@ p 1 2 0 oak_trapdoor facing=north open=true half=top
Everything I know about Entity ID Wireless Redstone (EID Wireless) for Minecraft Java Edition 1.14+.
A written supplement to #link("https://youtu.be/81OV1BltMQ8")[iPlayGames's Wireless Masterclass].
#warn[
In versions 1.14 - 26.1, only multiplayer servers are supported.

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

View File

@@ -50,13 +50,13 @@ p 0 0 0
#todo[fix tileset naming. the tileset is the *structure*. the particular sequence is just one instance of that tileset]
A *tile sequence* is a chain of redstone components which all update in the tile tick phase.
A *tile sequence* is a chain of redstone components that all update in the tile tick phase.
The fundamental principle here is to use tile-tick priority (TTP) to set a global order.
#link("https://youtu.be/sLftwVwqPQE")[See Charlie's great video on TTP for details].
A *tile set* is a system of constructing tile sequences which enforce a particular global ordering.
A *tile set* is a system of constructing tile sequences that enforces a particular global ordering.
Components which activate later in the sequence have a stronger effect on the order, so to match our
Components that activate later in the sequence have a stronger effect on the order, so to match our
left-to-right reading convention, we diagram tile sequences so the signal flows right-to-left.
=== The Tile Tick Priority Queue