Sollace

@unknown They do appear to be related (the double particles). I was searching for something relating to missing/misaligned particles and so didn't find that. This one has some technical details that may still be useful though.

A bit late, but just checked and this still affects 1.19.3

Appears to still occur in 1.19.2. I created an advancement with the following trigger that should only unlock for apples, but it will in fact trigger for any item.

"eat_apple": {
      "trigger": "minecraft:consume_item",
      "item": {
        "items": [
          { "item": "minecraft:apple" }
        ]
      }
    }

Issue is still present in 1.18. Nothing I can see has changed, code-wise. ModelPart#getRandomCuboid will still throw when called on a part with 0 direct descendent cubes.

@Bartosz Skrzypczah

Minecraft is binding already deleted VertexBuffers, which it internally assigns an ID of -1. This ends up changing mesa driver internal state in a way that always triggers a very slow code path for glGenBuffers.

I happened to land on this issue after searching for an issue I'm having that's somewhat similar, so I thought I would ask: Is it possible for this to crash GL11's own rendering pipeline?

I've been running the game on OpenJDK16, and ever since the switch away from Java8 I have been struggling to debug this occassional error where the game would have a REALLY intense lag spike, and then all rendering would freeze whilst sound and gameplay continues unabated.

@violine1101 Indeed that may be related to this.

I'd like to add that this crash can also be produced by using any output with count=0

I know this exception. I've encountered it before multiple times. It's due to a change in Java 11 that makes it so HashMap.computeIfAbsent will throw this exception, either if the call is nested, or if something else interacts with the collection whilst that method is being called.

map.computeIfAbsent(keyOne, a -> {
      ....
      return map.computeIfAbsent(keyTwo, b -> {
      }); // throws
});

Only solution I know of is to switch to using something like a TreeMap instead, which does not have it's own implementation of computeIfAbsent.

A slightly better fix: f838a4c05843

This one will check if there are any boxes, and if not, delegate to the child cubes, and if there's absolutely nothing to return, returns EMPTY_CUBE with no dimensions.

Encountered this today whilst working on mod code. Looks like the culprit is the addition of ".layering(VIEW_OFFSET_Z_LAYERING)" to the render layer used for armour, versus the one normally used for entities which continue to function as before.

Very strange that it would have this effect, though, because all that does is apply a minor scaling change. I guess this means someone was trying to fix z-fighting and forgot to update the two glint layers.

Fix implemented via Mson: 0a100debf87

Alright. I will come back to this if I see it happen again.

(btw, as it's rendering-related, I don't believe the server has any bearing on this issue)

Certainly. I've attached the resultant log to the issue.

comes back

First thing, you might want to change the one command to: "/scoreboard players add @e[r=5] a 1"

Otherwise you get spammed with objectives for every entity loaded in the world.

Also I can confirm the 'phantom' is a duplicate of the first 16 letters of the entities UUID and it does the same for any non-player entity. It's likely this is happening because the scoreboard has a limit on the maximum player length and since entity UUIDs are longer they get trucated when the world saves. Then when you load the game again the saved names will no longer match the entitie's actual name/UUID and it will create a new one.

Not sure if this a legitimate bug or working as intended though. I would say working as intended as the player type of scoreboard objective is only really intended for use with players, but the bug is that it allows you to create objectives for non-players (or things with names that exceed the limit). It should throw an error in the same way that the teams scoreboard does for long names.

Edit: Sorry, did not see your reply. I think what youa re saying is correct. It is a custom player that only exists within the scoreboard.

What I see:
In the third screenshot we have Rismotch (the player), that looks normal. We also have a UUID for the armour stand, that looks normal too.

But then the third one looks strange, it seems to be a truncated version of the armour stand's UUID. It could be a duplication in the scoreboard, or some other entity that really shouldn't be there. I'll do some tests to try and duplicate it and see what I can find.

I see what you mean. I completely forgot they changed it. After testing in 1.6.1 the bug does appear to be fixed.

Players appear to be jumping around because the game uses the same packet to mount and unmount entities.

Ive made some changes that appear to fix the floating players. I haven't experienced any players becoming invisible though.

In EntityPlayer add the following method:

EntityPlayer.java

public void mountEntitySpecial(Entity par1Entity) {
        if (this.ridingEntity != par1Entity) {
            super.mountEntity(par1Entity);
        }
    }

In NetClientHandler change the handleAttachEntity method:

NetClientHandler.java (Before)

if (riderEntity != null) {
        ((Entity)riderEntity).mountEntity(riddenEntity);
    }

NetClientHandler.java (After)

if (riderEntity != null) {
        if (riderEntity instanceof EntityPlayer) {
            ((EntityPlayer)riderEntity).mountEntitySpecial(riddenEntity);
        } else {
            ((Entity)riderEntity).mountEntity(riddenEntity);
        }
    }