Avantir_Yihn

In what circumstance would you want to control that? Wouldn't you want it always to look like it's properly on top?

As a workaround for this, I've found zipped data packs load far faster than unzipped ones. My 10,000 function data pack takes 1-2 minutes to load unzipped, but only about 2 seconds to load when zipped.

This issue appears to be fixed in 1.14.4.

This appears to be fixed as of 1.14.4.

It's worth noting that this issue has not reoccurred for me since my last comment, and I was on the same version (1.13.2) for the vast majority of that time, including the times when it did occur.

Why are you asking me? Why are you making me go check something that takes all of 2 seconds instead of doing it yourself while you're already here? Why are you sidelining this issue until I eventually find time to check my email?

YES, it is still an issue in 1.13.2. This is the kind of bug that requires a very intentional fix anyways, so I would be very surprised if it was accidentally fixed without being marked as fixed in a snapshot/pre-release.

I was still experiencing this issue in 1.13.1, but it is definitely fixed in 18w43a.

Also, if anyone else is having this issue, you can workaround it with a data pack by checking for any phantom's AY tag being significantly below its own position. If it is, just set its AY tag to be some place a bit above the player's position.

Make sure not to do this modification on the same tick that the phantom is summoned however, or you will prevent it setting its default circling location and cause it to fly to 0,0.

Wait - Why does 1.13.1 count as a Future version? That's the current release!

It happened again. More details (My memory could be faulty):

The session before the issue occurred, I logged in, modified my data pack, reloaded the data pack, removed an item from my inventory via the creative inventory and ran the modified function (That contained a single /give command). I then quit the game normally. I completely closed Minecraft, and when I opened Minecraft and entered my world the following time, all scoreboard objectives were gone. Notably, I still had the item given to me by the function that I had modified.

The scoreboard.dat size is now 241KB - up 16KB in the last 3 days. Given that I only added 2 scoreboard objectives in that time (Both of which only apply to the player), that seems rather high. Is it possible that the scoreboard.dat size is being inflated by something, like dead entities aren't being removed or something?

The issue has occurred yet again. It is also worth noting that my scoreboard is relatively large. The scoreboard.dat file was >100KB when I first started getting the issue, and now it is >200KB (221KB as of this last wipe - I've started manually backing up the scoreboard so I can easily restore it when this happens).

I don't believe this is an issue anymore. In 1.13, the @e selector has arbitrary sorting by default. Getting it to prefer entities from the same dimension or adding a selector argument which allows sorting by dimension seems more like a feature than a bug fix.

I believe this issue also relates to MC-130053.

This issue has occurred again. Once again, the game was quit completely normally, but the scoreboard.dat file was wiped.

I'm experiencing this issue too. The server is just running slower than it should, and it's messing up the timings of everything. No client lag at all.

The lag from this bug is definitely not as bad in 1.13pre-2 but still not as good as it was in 1.12.

To add on to this: Lightning seems to only set mob's HurtTime to 9 in the 1.13 snapshots, unlike 10 for everything else. So if lightning lasts for 0.5 seconds, there is a 1 tick window after the first damage instance in which stuff can take damage again.

I believe this relates to MC-104870 and MC-21109.

That's not a bug though. JSON objects are, by definition

an unordered collection of name-value pairs

The issue is that the unordered name object is stored in a string, which is an ordered list of characters. That is a workaround to avoid quoting object keys, but creates this bug.

So this has now been labelled "Won't Fix"? Oh boy.

I've been waiting on this getting addressed for 3 and a half months now, so thank you for at least making your intentions clear. I should also say that I wasn't expecting this bug to be fixed anytime soon (Although I was hoping it would be), as a proper fix would require a rather major refactor of the way in which JSON is parsed and used throughout the game as a whole, just for something that many people would see as a "minor inconvenience".

I've been developing a custom map for 4 and a half years now. Naturally, I want to find ways to make development easier and to speed it up, avoid bugs due to inconsistencies, etc. So I've built a strings system that allows me to centralize all occurrences of the same text, and allows me to change it all throughout the data pack by just changing it once inside the strings. This has been incredibly useful, and has allowed me to do other useful things like having a loot table and give function for each custom item. 1.13 added a "set_name" function to loot tables, which is rendered completely useless due to this bug. The order of the keys in the generated JSON object are arbitrary by definition, so I can't know what the Name string will actually look like. Therefore, it is quite unlikely to be the same as the one created by the function (Which must be hardcoded, not generated), and I won't know what to look for in a command looking for a player holding that item. For instance, I cannot do "say @a[nbt={SelectedItem:{display:{Name:"{\"text\":\"stick\"}"}}}]" if the item was obtained through a loot table that uses the set_name function. On top of which, that is a fat wall of brackets, backslashes and quotes. When you have to test for dozens or hundreds of items all in different places, the bug is no longer a minor inconvenience. It's a gigantic pain in the butt.

I don't expect this to be fixed soon. Heck, I don't even know that I want it to be fixed soon (Opportunity cost and all). What I want is the "Won't Fix" resolution removed. Won't fix in the near future, sure, but this does need to be fixed eventually. Labelling it "Won't Fix" is equivalently to sweeping it under the rug and ignoring it until it comes back to bite you. This is a problem and it needs to be addressed, especially since it may get worse in the future.