winsrewu/blog-stash#The Essential First Step to Mod4 Entity ID Wireless Redstone.md

## blog-stash#The Essential First Step to Mod4 Entity ID Wireless Redstone.md

      
    Raw
  

              blog-stash#The Essential First Step to Mod4 Entity ID Wireless Redstone.md
            
          
    Frequently Asked Questions

Q: What about stability?

A: Very high on the server, though not 100%. I haven't experienced a false signal caused by that reason in my life yet. For local (integrated) servers, stability is moderate, but a fix can be applied.

As the machine loaded, there's nearly always a false signal, which is easy to prevent.
Q: Can it transmit signals between dimensions?

A: No.
Q: Does it work in the Nether or the End?

A: Yes, but it requires more effort than in the Overworld.
Q: How many channels can I have?

A: Nearly unlimited, though tile tick limitations may affect performance.

(This number is already very large and may cause your game or PC to crash before you reach it.)
How Does It Work?

Basic

Everything begins with this code snippet from the ItemEntity class in Minecraft (Yarn mapping):
if (!this.isOnGround() || this.getVelocity().horizontalLengthSquared() > 1.0E-5F || (this.age + this.getId()) % 4 == 0) {
    // calculate next move!
}
Here’s what each condition means:

isOnGround() indicates whether the item entity is resting on the ground.
this.getVelocity().horizontalLengthSquared() > 1.0E-5F checks if the item is moving horizontally (above a minimal threshold).
this.age counts the number of ticks since the item was created.
this.getId() returns the entity’s network ID, which is auto-incremented—the first entity gets ID 0, the next gets 1, and so on.

The ! operator means "not", and || means "or".

Therefore, the condition can be interpreted as:

If the item is not on the ground, or it is moving, or (its age plus its network ID) is divisible by 4, then calculate its next movement.
Now, consider this scenario:

We create 5 item entities, with perfect timing, in sequence from left to right (A first, then B, etc.),
in the same tick and place them still on the ground.
Their ages are identical, and their network IDs are consecutive.
A(age: x, id: y) B(age: x, id: y + 1) C(age: x, id: y + 2) D(age: x, id: y + 3) E(age: x, id: y + 4)

Given that age is the same for all, and IDs are consecutive,
it's easy to see that items A and E will satisfy (age + id) % 4 == 0 simultaneously,
meaning they will always update their movement in the same tick every 4 ticks,
and if we remove the floor, A and E will start to fall at the same tick.
We can use micro-timing techniques (typically achieved with tile ticks)
to create precise synchronized items even over distances of thousands of blocks.
Point to Point Communication

To transmit information between a sender and a receiver, the receiver first generates 5 items:
A(age: x, id: y) B(age: x, id: y + 1) C(age: x, id: y + 2) D(age: x, id: y + 3) A'(age: x, id: y + 4)

and checks whether A and A' move together.
To send a bit, the sender inserts an item 'X' between D and A' at the moment the receiver generates them:
A(age: x, id: y) B(age: x, id: y + 1) C(age: x, id: y + 2) D(age: x, id: y + 3) X(age: x, id: y + 4) A'(age: x, id: y + 5)

Now A and A' no longer move together. The receiver detects this change and outputs the signal.
One-to-Many Communication

To transmit information between a sender and multiple receivers, each receiver first generates four items:
A_1 B_1 C_1 D_1 ; A_2 B_2 C_2 D_2 ; ...

The first receiver’s items end with "_1", the second with "_2", and so on.
If the sender wishes to transmit a bit, it inserts one additional item at the end of the sequence; otherwise, it does nothing.
Then, each receiver generates another four items:
A'_1 B'_1 C'_1 D'_1 ; A'_2 B'_2 C'_2 D'_2 ; ...

It can be easily shown that if the sender sends nothing, all corresponding A' and A movements will match; otherwise, they will not.
Globally Synchronized Clock

All daylight detectors update every 20 ticks in Minecraft.

This behavior can be used to create a globally synchronized 20-tick clock, but it only works in the Overworld.
The clock timing can be adjusted as follows:

A sender continuously sends signals, and a receiver advances its clock by 1 tick each time until it receives the signal,

at which point their clocks become synchronized.
However, cross-dimensional synchronization is not possible because dimensions are processed sequentially—the Overworld is calculated first, followed by the Nether, and so on.

This makes the necessary insertion operation between dimensions impossible to achieve.
Multiple Senders

While the methods mentioned above all support multiple senders, they may fail if multiple senders operate simultaneously.
For a solution, you can refer to https://en.wikipedia.org/wiki/Exponential_backoff.
Stability

On Machine Loaded

Nearly always a false signal.
Local (Integrated) Server

Due to MC-238384,
unofficial fix from local-server-entity-id-fix.
Normally, entities are synchronized to the client at the end of each tick, resulting in an item sequence like:
S_a S S S S_a C C C C C ...

We verify whether the S_a entries are synchronized, while client-side items (C) do not affect anything.

However, if the server or client experiences lag, and some client items are spawned between server item entity spawns, the synchronization will break, which may happen offen, like 1 ~ 2 per Minecraft day, depends on your world and machine.
Server

Chunk generation is handled by worker threads, not the main thread.
Some creatures are spawned during this stage as part of structure spawning—
such as village cats or cats in swamp huts. Refer to Structures.java for details.
If one of these entities is accidentally inserted into the item entity sequence, it will cause the system to break.
Fortunately, the likelihood of this occurring is very low.
No results found