121 lines
5.7 KiB
Typst
121 lines
5.7 KiB
Typst
#import "/lib.typ": note, tip, todo
|
|
|
|
= Causes of Interference
|
|
|
|
We need precise control over the entity age and ID for this to work, so sources of interference are
|
|
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].
|
|
|
|
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
|
|
the same game tick, all the items are created in the same tick phase, so player inputs and world
|
|
events cannot affect it. See @timing for details.
|
|
|
|
== Singleplayer (before 26.2) <singleplayer>
|
|
|
|
In singleplayer worlds, there are separate execution threads for the renderer and game world. The
|
|
game world ("server thread") contains the item entities we care about for the purposes of EID
|
|
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
|
|
(#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 that patches the game to use a separate counter for the
|
|
client.
|
|
|
|
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>
|
|
|
|
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.
|
|
|
|
#todo[Paper compatibility list][figure out exact version compatibility list.]
|
|
|
|
== Unloaded Chunks
|
|
|
|
When a chunk unloads and reloads, all entities contained within it are destroyed and recreated with
|
|
new entity IDs. Therefore any information encoded in the ID group offsets is destroyed.
|
|
|
|
#tip[
|
|
When a chunk containing an EID Wireless receiver is reloaded, every in-progress transmission
|
|
*MUST* be discarded.
|
|
]
|
|
|
|
The best thing to do is to use a reload detector and lock the receiver output for one full cycle
|
|
after a reload.
|
|
|
|
#todo[Reload detector designs][frost walker, sculk sensor, ???]
|
|
|
|
== Lazy Chunks
|
|
|
|
Entities in lazy chunks do not age or move, and their IDs are preserved. However, the redstone
|
|
circuitry will continue to function. If a chunk becomes lazy while a transmission is being
|
|
processed, the detection circuits will not observe the right drop delays and so the transmission is
|
|
corrupted.
|
|
|
|
#tip[
|
|
When a chunk containing an EID Wireless receiver becomes lazy, every in-progress transmission
|
|
*MUST* be discarded.
|
|
]
|
|
|
|
Further, depending on the receiver design, there is a small chance the items become clipped into
|
|
blocks. When the chunk becomes entity-processing again, the clipped items will fly out of the
|
|
machine instead of being recycled.
|
|
|
|
The best thing to do is to use a chunkloader to prevent the receiver ever being lazy-loaded. If
|
|
chunkloaders cannot be used, a lazy-chunk detector can be used to lock the outputs while the chunk
|
|
is lazy-loaded and for one full cycle after it becomes entity-processing.
|
|
|
|
#todo[Lazy chunk detector designs][falling entity, ???]
|
|
|
|
#todo[think about lazy conditions by cases]
|
|
|
|
|
|
#todo[wip comment on discord][
|
|
The problem with unloaded chunks is that when the chunk reloads, all items are recreated with new
|
|
entity ids and the transmission information is destroyed. There is no hope for recovery, so the
|
|
only solution is to discard the first cycle.
|
|
|
|
The problem with lazy chunks is that it's impossible (or at least very hard) to synchronize entity
|
|
movement. The redstone, droppers, and hoppers all continue to tick in lazy chunks. If you have
|
|
multiple items in each slice, then every cycle in lazy chunks spaws an item. When you the chunk
|
|
ticks again, the hopper can onl pick up one of the items, and the rest sit there. You can't
|
|
control when in the cycle the chunk ticks again either, so it may tick with the trapdoor already
|
|
open, or just about to close.
|
|
|
|
Quite often, things will be desynchronized such that the trapdoor closes clipped into an item
|
|
while the hopper is on cooldown. In that case, the collision flings the item out of the
|
|
measurement chamber. If you only have one item, then the hopper can never be on cooldown while the
|
|
item would collide with the trapdoor, so it always gets recycled and can never be flung out.
|
|
|
|
However because you can't control the timings, you can't guarantee the mod 4 optimization was
|
|
actually applied or if the items are just falling through the already-open trapdoor. So you still
|
|
have to discard the message.
|
|
|
|
If you have a lazy chunk detector, you can stop the clock while in lazy chunks, then simply resume
|
|
the clock on the next cycle after ticking again.
|
|
|
|
But since you also need to lock the output for reloaded chunks, it's just easier to do that every
|
|
time.
|
|
]
|
|
|