mojira.dev

Zedadias Wick

Assigned

No issues.

Reported

MC-135989 Kicked for flying using trident with Riptide enchantment Fixed MC-115124 Outdated Server (17w13b - same version as client) Invalid MC-106419 Player-summoned ender dragon drops dragon egg after server reboot or close/open world Cannot Reproduce MC-54056 /scoreboard player set @p no longer works on dead players Duplicate

Comments

I've just ran a few tests using Mart's 1.12.2 test world.

I first loaded/upgraded it in 1.13, where none of the chest contents were wiped.

I then loaded/upgraded it in 1.13.1, where several halves of the double chests were wiped.

I then retried it in both 1.13 and 1.13.1, each yielding the same results as above. (with the exact same chest locations wiped in 1.13.1 as before).

I loaded the un-upgraded version in 1.12.2 and removed the opposite halves of the double chests, which are not wiped in upgrading to 1.13.1, leaving just the single chests which are usually wiped in the upgrade. When loading this in 1.13.1, they were not wiped.

 

Apologies, I had set it up a long time ago behind a bungeecord server. I simply updated it and started it without realising what I had experimented with previously.

This can be closed.

Confirmed for 1.11-pre1; modified provided rcon script to summon snowballs, server crashed almost immediately.

crash log: https://pste.me/#/uuRpZ

Agreed. It's infuriating having to retype messages all day, especially commands when working with command blocks.

It's not listed, so confirming this still exists in 1.9 and 1.9.2.

Thanks @unknown, have reposted my comment over there.

Have been seeing this a lot in my server's console since 1.9 and have realised that two reported missing horses, which I had already worked out were just invisible with non-functioning AI.

I have a pen with 3 horses, 2 of which are invisible and do not seem to have functioning AI. I can /tp to them, however, which is the only way I could confirm they were indeed there, and do not seem to move at all.

[16:04:52] [Server thread/WARN]: Keeping entity EntityHorse that already exists with UUID 8671f013-891f-45c8-af9c-cf8f786035a1
[16:04:52] [Server thread/WARN]: Keeping entity EntityHorse that already exists with UUID 8671f013-891f-45c8-af9c-cf8f786035a1

One of the three horses is visible and moving, the other two are invisible and not moving. I assume the two duplicates are just not being fully loaded because they have duplicate UUIDs.

I have seen the messages a ton since updating to 1.9, and just assumed they were resolving issues and would eventually stop - but if this is happening across the world then it' a pretty serious problem for many players, and indeed the server since many of these duplicate entities will likely just never go away.

I have what I thought to be this issue with a few certain mobs, but have discovered something I don't think has been mentioned so am not sure.

I have a pen with 3 horses, 2 of which are invisible and do not seem to have functioning AI. I can /tp to them, however, which is the only way I could confirm they were indeed there, and do not seem to move at all. I have been seeing plenty of "Keeping entity" messages in my server's console since updating to 1.9 and have realised two of these horses are included in that, both with the same UUID.

[16:04:52] [Server thread/WARN]: Keeping entity EntityHorse that already exists with UUID 8671f013-891f-45c8-af9c-cf8f786035a1
[16:04:52] [Server thread/WARN]: Keeping entity EntityHorse that already exists with UUID 8671f013-891f-45c8-af9c-cf8f786035a1

Confirmed by using /tp 8671f013-891f-45c8-af9c-cf8f786035a1

Render distance: 6

It seems strange that this feature would be solely available for mini-games, and not for survival worlds. Why can't we maintain scores for deaths, mob kills etc.?

In addition, vanilla survival servers have started to use scoreboard and command blocks in clever ways to replace plugins. Scoreboard not being updated to be based on UUIDs utterly breaks these servers.

Apologies, this is only applicable for @p, not @a. I am unsure if this ever worked in previous snapshots, I was likely using @a instead.