FlashTeens

I can still reproduce the issue on the recent Release 26.1.

For the questions provided by [MCQA] EmA:

1. Here’s the screenshot for Quality and Performance settings:

2. I upgraded the previously tested 1.21.11-pre3 map to 26.1 format without additional modifications, and the issue still happens in the same way.

• I haven’t checked if it still happens when I created a new and clean world save (with default terrains rather than superflat) and follow the repro steps again. I’ll also check it soon.

3. I placed the rails and the surrounding structures via some /clone commands like:

/clone x0 y0 z0 x1 y1 z1 x0 y0 ~
(where x0<x1, y0<y1, z0<z1; on the following context we assume the )

• The cloning source (x0..x1, y0..y1, z0..z1) is a section of railway tracks within the force-reloaded chunks. The section includes the rails, the floor that supports the rails, and (optionally) glass-made walls and ceilings.

• To help build faster, I first put an “Always Active” impulse command block → paste the command above → Ctrl + middle click to obtain the fast-cloning command block. Then, I repeatedly put the fast-cloning command block onto the south side of the tracks, so I can extend the tracks southward very fast.

4. The commands should be accurate. For the units, I assume that 1 meter = 1 block, and the gameplay is configured to be 20 ticks per second (the default settings).

• If you can’t reproduce the issue yet, here’s a Google Drive link for the map that I used to reproduce this bug in Release 26.1.

5. To better demonstrate whether or not the chunks are loaded, here’s a screenshot for the visualize_chunks_on_server status (enabled by opening the F3+F6 settings). When the bug happens, the chunk loading status is like below:

In this screenshot, the player appears to be at the edge of the range of loaded chunks.

And at the moment when the bug happens, we’re still riding the minecart, but I failed to remove the debug tag from the minecart using the following command:
/tag @e[type=minecart,distance=..100,sort=nearest,limit=1] remove debug

By this observation, we can say that the distance target selector is out-of-sync with the current player’s position when this bug happens.

And if I remove the distance constraint from the target selector, then it does remove the debug tag:
/tag @e[type=minecart,tag=debug] remove debug

However, under this situation, even though we removed the debug tag, then the chunk loader did not load any further chunks. The player is still moving along the tracks, and we still cannot even let the player leave the minecart by merely pressing the Left-Shift key. We have to press F3+N to switch to Spectator Mode in order to let the player leave the minecart and let the chunk loader finally working again.

I can still reproduce this bug in 1.21.11-pre3 with modified repro steps:

• After placing the two command blocks in Steps 2-3, use /forceload add ~ ~ to ensure that the commands can be executed anywhere.

• Keep the same repro steps for the rest.

It still happens on 1.21.6.

Please note that the phenomena as mentioned in this bug report is different from another chunk loading bug that we found a few years ago: MC-190836

This bug (MC-297378) can happen only after 1.21.2 (inclusive), and we suspect this one to be a side-effect from the minecart improvement update (as said in my previous comment)

On the other hand, the MC-190836 one seems to also happen on some earlier versions after 1.14, and we consider it to be more likely to depend on hardware performance.

Therefore, please investigate the root cause of these two bugs separately. We do NOT consider these two bugs as duplicates. Thank you.

Similar issue can be reproduced in 25w20a, as shown in Phoenix SC’s video on YouTube: https://youtu.be/WFf-kUsIXPg (5:46-6:07 of the video)

Added the debug info using the /jfr command while reproducing this bug again today. It did happen in the same way.

I have tried replacing the Command #2 from the description:
/execute as @e[type=minecart,tag=debug] at @s run data merge entity @s {Motion:[0.0,0.0,1.0]}
with any of the following equivalences:

• /execute as @e[type=minecart,tag=debug] at @s run data modify entity @s Motion set value [0.0,0.0,1.0]

• /execute as @e[type=minecart,tag=debug] at @s run data modify entity @s Motion[2] set value 1.0

But none of these alternatives help; I can still always reproduce the same issue.

So, I still guess it could be a chunk loader issue instead of anything to do with syntax changes across Minecraft versions.

Though I did not use the experimental minecart improvements to reproduce the bug, could it still be the culprit why the chunk loader does affect non-experimental gameplay? (since this experimental feature was also introduced in 1.21.2.)

I have created a new bug report with much simpler reproducing steps, which can lead to the same problem without involving any commands or datapacks.

Here's the link for the new bug report: https://bugs.mojang.com/browse/MC-176240

If the new bug is confirmed, please help me mark this old bug report as a "duplicate". Thanks. 🙂

Attached the debug report using the command "/debug report".

The source map for reproducing this bug is available on my Google Drive:
https://drive.google.com/open?id=1W3C3VppoR1WN-ksif-raRWqqu_TcBAch

Thanks for your demonstration. It's indeed the condition that I encountered as well. 🙂

I'm one of his coworkers on Minecraft map projects. Let me add some comments to the description:

1. The command he mentioned above should be revised as:
execute as @e[type=minecart,limit=1,sort=nearest] at @s positioned ~ ~ ~ run tp @s ~ ~ ~1
and he intended to run this command every tick (i.e. 20 times a second), so the minecart is expected to run at a speed of 20 m/s.

2. For some low-end computers, such scenario may easily cause chunk loader to work incorrectly, and it could also freeze the map and prevent the player from getting off the minecart. If the minecart were teleported even faster (say 5 block per tick, or 100 m/s), then most computers may have this issue as well.

3. This issue only occurs on version 1.14.x (including 1.14.4), while we didn't find the same scenario on 1.13.2 or earlier versions.

Thanks for the correction. I didn't know that the attribute was technically renamed. Sorry for that.