zero318

Additional crash when height is any low value. I've tested 1, 2, and 8 which gave the same crash, appearing similar to the one for height <1.

Json:

^Crash: 

This isn't a bug and the model is used. It's the inventory model for chorus plants and is referenced from assets/minecraft/models/item/chorus_plant.json

This feels like some sort of floating point precision error more than anything, though I don't know why such a thing would suddenly start happening when it hasn't previously. Perhaps the underlying movement handling code has changed and introduced an accidental rounding step too early in the process.

This behavior makes sense because of how datapacks can reference files that might be modified by other datapacks.

For example: Datapack A adds a tag that references the "minecraft:impermeable" tag and datapack B modifies the "minecraft:impermeable" tag. If datapack B is enabled/disabled, it makes sense to reload datapack A as well in order to make sure that the tag it added is properly updated.

Another example would be a datapack that functions as a "base" that other packs can expand upon. Such a pack might add an empty function tag that other datapacks can add their own functions to, then the base pack can still retain control over when that function tag is executed.

It still doesn't give as many ingots as could be obtained by crafting the maximum nugget drop from fortune, but it's slightly more reliable since even a max fortune pick tends to yield ~6. Makes it a much more interesting decision for which enchantment to use.

Could not reproduce any of the server crashing effects. The player can definitely outrun the render distance, but then they just stop instead of crashing/freezing the server.

I can't seem to reproduce this. Can you provide more detail and potentially screenshots?

Could a "minecraft:airs" block tag be added to contain air, cave_air, and void_air? That would easily allow commands to test for air blocks while still allowing a distinction to be made when trying to detect where a player is.

MC-153454 seems to be someone misunderstanding that the XYZ line of the debug screen corresponds to the player's coordinates as an entity (which logically starts with -0 when between 0 and -1) and not the coordinates of a block (which would not make sense to start with -0). However, there's still an underlying bug in the F3 menu related to a true -0 in the XYZ line, so I've added a comment to that issue.

With that in mind, this issue is different because it's about conformance to IEEE floating point specifications rather than about whether something is possible or makes logical sense for any specific data tag.

Regarding usefulness, while it may not be a useful distinction in vanilla, it'd be quite useful for datapacks to be able to set an otherwise impossible NBT value that doesn't cause immediate errors like Infinityd or -Infinityd (possible via setting the value to 1.79769313486232E+308d). This could potentially be used as an error condition or something similar if it's possible to test for 0.0 vs -0.0

Edit: Also, I apparently have no idea how to properly link an issue.

While it isn't what the original reporter meant, there is an inconsistency related to -0 in the F3 menu that could warrant reopening this issue.

Teleport commands can specify -0.0, which results in the F3 menu displaying -0.000 instead of 0.000 in the XYZ row. However, checking the player's NBT data reveals that their position is 0.0d, not -0.0d.

Since the debug menu is seemingly intended to accurately represent the player's current position as stated by the NBT data, it should read 0.000 in that situation instead of -0.000.

Initially I thought this was caused by the texture being changed to support separate left/right arms/legs, but a quick edit of the texture reveals that the left arm/leg are just reusing the right arm/leg textures.

Still relevant in 1.15.1, though the items only clip into blocks visually. Using F3+B to show hitboxes reveals that the items don't actually clip into the blocks above them, which is why they can still be collected.

Are the particles still rendered/processed but merely invisible? I ask because it feels like bubble columns don't cause nearly as much lag as they used to, which might be related.

Confirmed for 1.14.1-pre1

Well, nevermind. Despite my best efforts to search for duplicates before submitting a report, this seems to be a duplicate of MC-102403 since that bug was fixed in 1.13-pre2 and this issue is no longer occuring.

As noted in the description, this bug could potentially be abused to play a sound in a way that a user cannot easily stop. Any kind of sound could be put in a resource pack attached to a world or set on a server. For example, an unsuspecting user could download an "adventure map" from an unreliable source and suddenly find their computer blaring painfully loud high frequency noise. Most people would immediately close the world and expect the noise to stop, but sounds played with this bug would not.

Edit: It's also not clear whether or not this could affect older versions or whether it is related to 1.13. If it only affects 1.13 and is fixed before any release then there likely wouldn't be a problem.

Edit2: Just realized that I might not know what kind of bugs are usually kept as private. If this doesn't really meet that criteria, it can likely be public. I just figured it'd be better to err on the side of caution when I created the report.

Try removing the resource pack entirely by placing it in a different folder. Minecraft still has to read the contents of a resource pack in order to generate the resource pack list, thus causing the crash regardless of whether the pack is enabled or not.

This is also happening to my singleplayer world in 18w01a. It affects more than just servers.

Edit 1:
After a bit of testing I can trigger this bug in a superflat world by following these steps:
1. Create a new superflat world
2. Place an item frame
3. Fill a map
4. Place a copy of the map into the item frame
5. Use the mouse to pick up the original map in your inventory
6. The game immediately crashes with this crash report and continues to crash whenever that world is opened

Edit 2:
Removing the item frame by editing the world NBT allowed the world to be loaded again without crashing.

Edit 3:
The crash doesn't occur if the map has had tag:{map:} stripped out of the NBT.

I can confirm that this bug affects the new ^ notation as well, making it much harder to use with players. Since the rubberbanding affects player rotation, this causes players to be unable to change where they are being teleported if a local teleport is run on a clock. This doesn't seem like the intended behavior that ^ was stated to have.

Confirmed for 1.11.2.