This is definitely not a dupe. The opacity of the particles has nothing to do with the order in which they are rendered. Additionally, it's a relatively new problem while the linked ticket is years old.
To prove that this has nothing to do with "ordering", start a void superflat world, travel away from the stone platform, and setblock some stained glass. Break it. The particles are still opaque and ugly, even though there's nothing for it to be ordered with.
Confirmed for 1.13.x and 1.14
@Jay Eff, correct, chunks within a certain radius of the player (2-3 chunks, iirc) are always run on the main thread, and other chunks run off-thread.
Code cause: In ChunkRenderDispatcher (or the class that has a ThreadFactory making threads called "Chunk Batcher N"), the constructor only adds one buffer to the queue of available buffers, essentially forcing all chunk rebuilds to be serialized, run one by one.
So we get a glimpse of what it would be like if we went back to pre-1.8 non-multithreaded chunk batching 😛
hey guys
this is just a note that the original forge fix I made that was posted above is buggy, and I have made a more correct fix here: https://github.com/MinecraftForge/MinecraftForge/pull/4830.
Marcono's comment is correct but is not the best way to fix the issue, because the client player should lose all of its attributes when it's recreated due to a death. But the client doesn't know whether a given respawn packet is due to a teleportation or death.
The optimal fix is to resend all attribute modifiers after a non-death dimension change, which is what the new forge fix I've linked does.
Confirmed for 1.12
That wouldn't work because the call to onImpact happens clientside. The problem is that thrower
is not synced to the client so ignoreEntity is never set clientside. The ideal solution is to sync the thrower.
I submitted a fix for this to Forge in the meantime https://github.com/MinecraftForge/MinecraftForge/commit/ba875418fd2cb23ad45c6f78e7ef1afb4d1e9ac5
Cannot reproduce on 16w41a either
Confirmed up to 16w32b
This was fixed a long time ago...
yup MC-12013 (caused directly by this issue) was fixed in 1.8.1
Confirmed to latest snapshot (November 18).
This would really really be a good (re)addition to combat. Please fix it!
It's just syncing one more field back to the client.
Thanks
Yup, still there. Please reopen
Devs, compare to 1.7.10 for proper behavior (actually probably 1.6, their behavior was already weird in 1.7)
Confirmed tup to 15w46a. Please fix.
@Early Reflections abd other recent commenters:
This issue is only about entities being invisible clientside/not being sent to the client. In all cases they are still there serverside, can still attack you, be identified by testfor, etc.
No doubt your issue is also severe, but I think there's another ticket that better suits it (permanent disappearances)
Unless there's some weird case where it disappears both client and serverside, then reappears on login. Then that'd be really weird 0.o
Although this is a good fix, there is probably a good reason why those values are int's. Floats and doubles take noticeably more network bandwidth to encode and transmit. Scale that up to 50 players at once and your network is struggling to keep up.
You do realize any kind of change like that would break worlds. And mojang strives to NEVER breaks worlds.
It's unused for a reason.
It was two separate blocks in the 1.5 snapshots, but was changed to one block with multiple metadatas. The only reason this is still here is legacy/to not break the worlds of those who used the 1.5 snapshots. It is completely unneeded.
These were found by examination of the code. The bound checks are off-by-one (e.g. checking <= width instead of < width). It affects the game since at any time it can cause the JVM to crash completely without the usual exception and stacktrace (since it's a native crash not a Java crash). Not to mention it's highly unsafe and could be a security vulnerability if a read somehow extends past the NativeImage buffer and reads sensitive data next to it in the native heap.