mojira.dev

GrantGryczan

Assigned

No issues.

Reported

MC-274013 Modifying trident/item entity to have 0 durability doesn't delete it Works As Intended MC-273578 Interaction entities position passengers incorrectly Fixed MC-273327 The "convertable_to_mud" block tag misspells "convertible" as "convertable" Community Consensus MC-273197 distance, dx, dy, and dz don't work outside -8388608 <= y < 8388608 Won't Fix MC-273079 `/return run execute <fork>` stops forking early Works As Intended MC-272808 Step height steps too high when there's a gap the player can fit through Fixed MC-272410 A collection matcher's `contains` field passes unconditionally for nonempty collections Invalid MC-272409 Item entity's name ignores `item_name` component Fixed MC-269005 Player heads from previous versions cause game crash and/or are converted incorrectly Fixed MC-263234 Waterlogged candles generate in ancient city Duplicate MC-257669 Using an End portal in the Nether generates an obsidian platform at y=49 instead of y=48 Duplicate MC-254833 Entering water in spectator mode makes you stop sprinting Duplicate MC-245479 Arrows become invisible after hitting a fixed item frame Duplicate REALMS-5452 Upon uploading a world, the string "world" in all file paths is replaced with the Realm name Confirmed MC-195328 Piglins can pick up items tagged Owner Duplicate MC-143952 data/chunks.dat isn't saved if the most recent /forceload command failed Fixed

Comments

Confirmed in 1.21.5.

It appears this is fixed in 1.21.5.

Oh wait, I just realized I was mixing this up with count. Durability 0 never deletes items, so this is probably WAI.

Confirmed in 1.21. Also, relates to MC-273578.

Confirmed in 1.20.6.

I don't think this is MC-267441. That issue says stepping fails under certain conditions. This issue says it works but steps too high. But if it was fixed by the fix for that issue anyway, cool.

@unknown I don't think this has any relation to MC-209. This isn't related to blocks persisting item data.

Ah, apparently it's supposed to be items, not item, even though https://www.minecraft.net/en-us/article/minecraft-java-edition-1-20-5 says the opposite.

@unknown It sounds like that use case could be addressed if Minecraft instead saved all item components in the tile entity, right? Similarly to MC-174496 but for more than just display name.

Confirmed in 1.20.3 😞

Confirmed in 1.19.3. Can someone please update the title and description to actually be accurate? The issue has nothing to do with whether it was one chunk or multiple chunks. The title should communicate that data/chunks.dat doesn't save if the most recent /forceload command failed at the time of saving. The first comment's reproduction steps and code analysis would be good to replace the current inaccurate description.

If appropriate, I wouldn't mind taking ownership of this issue and making these edits myself.

Duplicates MC-143952. This was unknown before because it was unclear that both issues were caused by the same thing.

To add more specific details, normally entering an End portal creates an obsidian platform at Y=48 and teleports the player to Y=49, but if you create an End portal in the Nether (e.g. using creative mode or `/setblock`), it instead creates the platform at Y=49 and teleports the player to Y=50. The X and Z coordinates are the same.

An example of why this is a problem is that it leads to builds around the platform appearing to be offset depending on which dimension you enter from (which is irritating for me as a mapmaker trying to use all three dimensions–I have to use commands to fix this in my map).

Never mind, I just found that this is a duplicate of MC-252361.

@railgun290 12 (and probably 13) blocks works fine for me in 1.19.2 if I'm not in the boat when it falls.

It is not `more mob heads v2.9.2.zip` that causes this issue. Adding that file fixed it for you because it overwrote whichever other pack had this issue. More Mob Heads doesn't touch the yellow shulker box loot table.

This also happens with advancement loot rewards. Should that be added as part of this issue, or should there be a new issue for that?

Why is this working as intended? How are creative players supposed to tell how many blocks they broke, as they would expect to from the statistics screen?

Oh! Never mind, this is a duplicate of MC-101723.

Agreed with the suggestion in the previous comment. Currently this issue can't feasibly be worked around in many use cases. In those cases, the performance cost is necessary given the way that data packs work. And generally, that cost is negligible anyway, since they are instances which only run once to load a single chunk, spawn an entity in it, and assign some data to the entity that we only necessarily have access to for one tick, which requires selecting it in the same tick it's summoned. Then it never runs again. It's not really an issue for performance to only run one synchronous chunk load per data pack during the world's entire lifetime.

Another use case this makes less feasible is chunk pre-generation. We can use the `/forceload` command for that in 1.16, but in 1.17, recursively spreading outward with `/forceload` commands throughout a very large area (of variable size) in order to generate chunks would take an extremely long time due to being asynchronous, with each iteration waiting for the previous iterations to finish, and there being tens of thousands of iterations.