mojira.dev

williewillus

Assigned

No issues.

Reported

MC-181425 Item Pickup Animation is missing Duplicate MC-112891 Falling block entity drops block with metadata of item dropped when block would be mined causing malformed drops Fixed MC-73853 Damage wobble no longer shows direction of incoming damage Duplicate MC-72736 Scoreboard Health Tab List Incorrectly Handles Absorption Works As Intended MC-54032 No item pickup animation Duplicate MC-49579 Mounted entities disappear on relogin Duplicate MC-48577 Item and XP drops are sucked towards the player's feet instead of their chest/torso Cannot Reproduce MC-34815 Hearts do not blink when regenerating (Cause identified in code) Fixed MC-26691 Splash Potions do not give full time when hit at feet (Gameplay) Duplicate MC-26678 Damage wobble no longer shows direction of incoming damage Fixed MC-18042 Items jitter when manually tossed onto ground Duplicate MC-13094 Missing smoke particles when placing ender eye into end portal frame Duplicate

Comments

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.

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.

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.

MC-87792 is this problem, but this ticket is updated/valid for 1.11.2.

Cannot reproduce on 16w41a either

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.