diff --git a/content/index.typ b/content/index.typ index a6cc9b14..13a8540b 100644 --- a/content/index.typ +++ b/content/index.typ @@ -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. diff --git a/content/interference-causes.typ b/content/interference-causes.typ index b87fbd16..ac17f01d 100644 --- a/content/interference-causes.typ +++ b/content/interference-causes.typ @@ -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 -#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 diff --git a/content/interference-fixes.typ b/content/interference-fixes.typ index a901effa..474a1cc5 100644 --- a/content/interference-fixes.typ +++ b/content/interference-fixes.typ @@ -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