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

wip lazy chunk notes from discord

Browse Source
This commit is contained in:
David Allemang
2026-07-06 10:57:34 -04:00
parent 5e95f52848
commit 246333684f
1 changed files with 43 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
content/interference-causes.typ
View File

@@ -8,8 +8,9 @@ generally unexpected entity spawns that mess up the ID.
== Other Entities == Other Entities
Recall that *any* entity spawning will increment the ID counter, and the full list of entities is Recall that *any* entity spawning will increment the ID counter, and the full list of entities is
surprising. An exhaustive list is available at surprising. An exhaustive list is available at #link(
#link("https://minecraft.wiki/w/Entity#Types_of_entities")[The Minecraft Wiki]. "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 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 chance for other entities to spawn in-between. For example, by spawning all items with droppers in
@@ -52,8 +53,10 @@ which breaks EID Wireless.
When a chunk unloads and reloads, all entities contained within it are destroyed and recreated with 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. 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 #tip[
*MUST* be discarded. ] 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 The best thing to do is to use a reload detector and lock the receiver output for one full cycle
after a reload. after a reload.
@@ -67,8 +70,10 @@ circuitry will continue to function. If a chunk becomes lazy while a transmissio
processed, the detection circuits will not observe the right drop delays and so the transmission is processed, the detection circuits will not observe the right drop delays and so the transmission is
corrupted. corrupted.
#tip[ When a chunk containing an EID Wireless receiver becomes lazy, every in-progress transmission #tip[
*MUST* be discarded. ] 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 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 blocks. When the chunk becomes entity-processing again, the clipped items will fly out of the
@@ -79,3 +84,35 @@ chunkloaders cannot be used, a lazy-chunk detector can be used to lock the outpu
is lazy-loaded and for one full cycle after it becomes entity-processing. is lazy-loaded and for one full cycle after it becomes entity-processing.
#todo[Lazy chunk detector designs][falling entity, ???] #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.
]