Alluet

My 1.14.1 Pre-Release 2 server crashed for the same reason.

Report here: https://pastebin.com/QFrKRqAY

Entities outside of loaded chunks exist permanently in the world, just like in 1.13. The only change in 1.14 is that we cannot access them with @e, meaning that it's an easy way for functions to cause memory leaks.

The entities are certainly not unloaded, let alone written to disk. No region file will be created if one is not already present, and any existing region file will not be modified. You'll find the entity in the chunk you placed it in if you teleport yourself to said chunk, unless you close the world first, in which case the entity will be erased from existence (this behavior proves that the entity is still in memory).

Your example of teleporting the player to an unloaded chunk can be easily replicated if you run a function as your temporary minecraft:armor_stand, accessing the player through @a. Make sure to run kill @s once you are done, so you avoid causing a memory leak.

I personally think this behavior is acceptable, save for the fact that the entities are still loaded in memory. They should either be written to a point-of-interest file or discarded completely at the end of the tick.

This bug happens with my server with 6-10 players logged on fairly regularly, and it sometimes takes less than an hour. There are no new chunks being generated, however part of the world was generated in a Pre-Release. Noone has elytra yet, they're all just loading chunks I've already generated by foot or by boat.

According to what my players have said, I think the oceans might magnify the problem. The server had already crashed before; after I restarted it, I was in the ocean with one of my players (although there were others throughout the world), and the lag just kept increasing until I manually restarted the server. While I was offline, the lag returned and eventually led to this crash.

I have three data packs installed other than vanilla}}–two use the {{schedule command to tick, one uses a repeating command block in each dimension (loaded with forceload), and (as a temporary solution to a minor issue I encountered) they all hook into player damage through the advancement trigger minecraft:entity_hurt_player. Additionally there is a shared function that use schedule.

Attached is the result of a short profiling of the server during the excessive lag leading up to the crash described in this bug. Notably, 70.20% of overall ticking occurred in tick.levels.world minecraft:overworld.tick.tickPending.ticking.unspecified. I will attempt to get a profile over a longer span of time during the excessive lag.

Affects 1.13.2-pre1.

Confirmed for release 1.13.

Until this bug is fixed, rather than being a simple boon, pregeneration will be a mandate for all (even small) survival server owners who want their players to have a decent experience.

In previous releases, pregeneration was nice, but I hardly did it because my servers were mainly for a few people and we experienced no lag at all.

During my time playing on the Windows 10 Edition, I noticed a delay for multiple other actions. There's definitely some sort of delay hitting buttons, though I agree it's not as much as pick blocking.

Affects 1.13-pre4.

It appears the bug was recently closed as WAI and then reopened. While I don't want to disrespect the decision process, this gave me some motivation to list a reason here on the bug tracker that I had discussed with someone the other day about why I feel this bug really matters.

Presumably the only reason this bug exists is the fix of MC-50848. While that fix was welcome, even if arguably unnecessary for most scenarios, it introduces quite strange behavior when the life of the ender pearl is extended (which is very much a possibility even in Vanilla).

When an ender pearl is freshly thrown by a player with the intent of teleporting to where it hits in a few seconds, it can be regarded as a "temporary entity." If only viewed in this context, I could perhaps agree that it's undesirable for the pearl to work properly upon death. The cases that the pearl would be deleted from the world are fairly obvious. When the player dies in either singleplayer or multiplayer, the recently thrown pearl is deleted. Arguably, logging out qualifying as this is not the biggest issue either, assuming the "temporary entity" thing.

Before I move on, I wanted to introduce the possibility of comparing the ender pearl in this "temporary entity" context to other true temporary entities. Arrows, primed TNT, etc. do not get deleted upon death. I recognize that fireballs do, but that's a property of that subcategory as a whole. Though this is besides my primary point, perhaps the easiest fix would be to declare MC-50848 as WAI because the behavior of ender pearls described there actually fits in with the behavior of other temporary entities?--

Back to my main discussion: Extending the life of an ender pearl is fairly easy to do using redstone. And it's something Mojang appeared to support by fixing this bug in the past (before being reopened due to fix of MC-50848). If they wanted to, they could add a death timer to the ender pearl and drop support for ender pearl stasis chambers, but they did not.

So we have a case where ender pearl stasis is supported, yet logic upon death/logout is treated like a temporary entity. This logic has further negative implications. If the ender pearl is contained in an unloaded chunk, the ender pearl will be unaffected by the "temporary entity" logic, which was made with the assumption that the ender pearl would land before the chunk it was contained within was unloaded.

This causes the potential for strange inconsistencies in multiplayer. For example, normally a certain row of teleporters shared by a few players at the gate of their mansion is unloaded, as it's far enough from the mansion's living quarters. Normally, when a resident of the mansion logs out, the logic meant to kill the ender pearl does not happen. Even if the resident is killed, this logic does not occur! Only when a visitor is walking to the mansion or if one of the residents comes out of the teleporter might the logout or death event of another resident cause an ender pearl to disappear.

The reason this is so bad is because it exposes the effect of chunk loading and unloading to the user. Most of the systems in the game are made to avoid this. Mob spawners only work in close proximity of the player to avoid unreasonable expectations when the player goes far away. Mob spawning in general is centered in a spherical radius around the player, also to avoid unreasonable expectations. Even redstone tries to work fine across chunk boundaries. A line of redstone that goes through chunks is meant to work (if finished before autosave), therefore it loads chunks when needed.

This makes the disappearance of ender pearls whose lifetimes have been artificially extended by a player inconsistent with the behavior of so many other systems in the game with regard to chunks. I am not proposing to load chunks at every ender pearl in the world, rather I am simply proposing to somehow differentiate between a "temporary" ender pearl and a "permanent" ender pearl.

A fix could perhaps be done by adding a timer that counts down from the maximum time it would take an ender pearl to reach the ground with no special circumstances (and this timer would count down more slowly when the pearl is within water). I really don't think the fix needs to be too complex. In a normal PvP scenario described by MC-50848, a player does not have access to, for example, a TNT cannon or an ender pearl stasis chamber to artifically extend the lifetime of the pearl. Even if the player did, the way the ender pearl would end up landing would most likely be inconvenient for them. Therefore, the timer only needs to be short enough to weed out an "ordinary" and "temporary" ender pearl that potentially passes through water before marking it as "persistent."

An alternative fix: detect "combat" and spread this status to ender pearls thrown during combat, and use the current "temporary entity" logic to delete the ender pearls thrown in combat. This seems harder than using a timer, but may or may not be a cleaner fix.

Affects 1.13-pre2.

Affects 1.13-pre1.

Cannot reproduce on 1.12.2 using the post, Wyatt's comment, or Rob's comment; and I believe Nikolas' comment is a feature request for non-glitch chunk loading rather than a confirmation of the bug.

execute detect does not load chunks.
testforblock does not load chunks.

The only strange behavior I found was that entities I teleported to other chunks stayed loaded indefinitely (until I loaded them manually or restarted the world). The chunks themselves never loaded (testforblock and setblock did not work).

This bug happens on 18w15a. If you wish to test it, you'll have to import the structure in a 1.12 world and move that world to the snapshot.

When I talked to him a while back, Dinnerbone implied that the functionality implicitly encouraged by this bug would never be used in practice, but was still meant to be an option. Perhaps this issue is WAI, but I still feel like it deserves to be considered.

Ah, I see. Thanks for those details, the math checks out. It is definitely strange that anchored eyes would still apply after one use, but adding anchored feet between the first positioned and facing fixed the issue. I will be rewriting the description of this bug to reflect that.

I understand the functionality of facing. However, after I change my base position using positioned and local coordinates, I expected to be able to execute further subcommands from that position. Instead, the facing subcommand I executed appears to have treated the new position as if it was the eye level, and decided to go down to the foot level since that's where relative coordinates always run. However, this new position is meant to replace the foot level, and the anchoring should be reset correctly.

If you read the post, you'd see that I am using local coordinates. It's just facing some relative coordinates (which I only expect to be elevated after overwriting the position, not from the get-go).

I'd like to note that the workaround to this bug is using `as`, which is not something that should be required for anything related purely to position/rotation. Even if taking advantage of the `anchored` subcommand, the command executor should not be involved (store the height data in the command "source", separate from the executing entity. If there is no entity, make `eyes` the same location as `feet`). I'm not sure if the existence of `anchored` (and the fact that by default it's `feet`, in contrast to being a position) is the cause of this issue, but I did want to throw that out there.

Confirmed for 1.12-pre2, using the structure I created and linked in my previous comment, relative to my previous comment, relative to my previous comment.

Confirmed for 17w18a, using the structure I created and linked in my previous comment, relative to my previous comment.

Confirmed for 17w16b using the structure I created and linked in my previous comment.