mojira.dev

Arcensoth

Assigned

No issues.

Reported

MC-168457 Container's loot table `LootTable` loses entity context `this` when invoked via `loot` under a `minecraft:contents` entry Confirmed MC-167201 Invisible glowing entities do not respect their team color Fixed MC-151082 Loading chunks creates irrecoverable lag (restart required) Awaiting Response MC-136112 /forceload cannot be run by functions or command blocks Works As Intended MC-128565 Function tag ordering is inconsistent across reloads and does not respect datapack ordering Fixed MC-113882 Output log calls loot table "resource table" Invalid MC-106510 Long structure names (over 64 characters) do not fit in the Structure Block GUI Fixed MC-95680 /stats (CommandStats) doesn't work for MinecartCommandBlocks Invalid MC-89880 Spawner with weight 0 crashes game Fixed

Comments

Can also confirm for 20w14a, and that linked worlds have worked fine for years up until this point.

Here's an excerpt of the warning from the game log:

Failed to read level <WORLD> data
java.nio.file.FileAlreadyExistsException: C:\Users\<USER>\AppData\Roaming\.minecraft_snapshot\saves\<WORLD>
    at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:81)
    at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
    at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
    at sun.nio.fs.WindowsFileSystemProvider.createDirectory(WindowsFileSystemProvider.java:504)
    at java.nio.file.Files.createDirectory(Files.java:674)
    at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
    at java.nio.file.Files.createDirectories(Files.java:727)

The ability to teleport entities into the void has been a common technique for years. Having it removed from the game and failing with an error is a significant breaking change for commands/datapacks.

I'd suggest a new "super kill" command that immediately disposes of entities without any of the aforementioned side-effects, but that still wouldn't fix all of the outdated datapacks.

Affects 1.15-pre6 as well. The problem is that the game is not seeding the village chests. They should have their `LootTableSeed` set based on the world seed and coordinates, or some other hashing method based on the world seed. You can verify the absence of this tag by using `data get block` on a village chest that has not been opened.

Agreed with Fabian. Marking it was "WAI" will mislead posterity into believing this is how enchanting is meant to work, which, as per Cory's comment, does not seem to be the case. Not to mention these changes were never officially announced, causing great confusion for survival players.

This is still a problem in 1.14.2-pre2.

I looked at the advancements generated by the server, and I think the problem is that the advancement uses invalid trigger data.

Here's what the relevant portion of the working minecraft:nether/create_beacon looks like:

{
  "trigger": "minecraft:construct_beacon",
  "conditions": {
    "level": {
      "min": 1
    }
  }
}

And here's what the bugged minecraft:nether/create_full_beacon looks like:

{
  "trigger": "minecraft:construct_beacon",
  "conditions": {
    "level": 4
  }
}

I'm guessing the level predicate should use min instead of a number.

I think there is some overlap in the symptoms, but the meat of that report is focused on single-player and doesn't necessarily suspect chunk-loading to be the cause. I believe I've narrowed down the culprit of this report to be server-side chunk-loading specifically.

Yeah sorry, I wasn't very clear with my original comment because at the time I wasn't sure about the distinction between the two problems.

@luigiofthebakery That sounds like a viable cause, given that we have to load/unload chunks for the issue to occur. I've been running a 1.14 server for a small group of players that's limited to a 17x17 chunk playing area via worldborder, and have had no issues so far... presumably because there is very little chunk-loading occurring.

Do you still have the crash reports, and would you be willing to attach them - or at least the interesting bits - to the bug report?

Indeed, I intended MC-151082 to be focused on the server-side lag. I agree it would be better to have separate reports, even if they seem like symptoms of the same underlying problem.

@violine1101 Thanks for linking the new issue, but I think we should split this into at least two separate problems: (1) server-side chunk-loading and (2) client-side rendering issues. The report I created was aimed at (1) the former; perhaps this issue should be re-opened (or another created) to address (2) the latter.

Edit: Looks like MC-151084 was created to more-accurately extend this report (MC-149178), whereas MC-151082 addresses the lag in particular.

@dexto No worries, JIRA definitely has its own issues. πŸ˜‰

I'm not sure which report is for rendering specifically, apart from the original MC-149178 which was marked as "fixed" (even though it is very clearly not fixed).

My goal with this report was to limit the scope to the server-side lag that's caused by (whats seems to be) chunk-loading. However it looks like the tracker mods are redirecting traffic from MC-149178 to here, so hopefully it doesn't just turn into the same generic "lag" report we already had.

Edit #1: I left a comment on MC-149178 regarding the distinction between the server-side lag (outlined in this, new report) vs the client-side rendering issue you demonstrated (outlined in MC-149178).

Edit #2: Looks likeΒ MC-151084 was intended to be for the client-side rendering, but it got resolved as a duplicate of this report. I think it would be better to have separate reports, even if they seem like symptoms of the same underlying problem.

@dexto Can you (or a mod) please remove the screenshot attachments from the report? This report is about the lag caused by chunk-loading, not the rendering issues, and they are cluttering the attachments section. Thank you.

Also your screenshot should ideally be a link or a thumbnail, and not embedded directly in the comment, as it is taking up the entire screen.

This issue is not entirely fixed, and 1.14.1-pre1 continues to have significant problems with chunk-loading.

As recommend, I created a new MC-151082 with debug reports and a video demonstration to contribute my findings. I imagine there are several other people doing the same thing.

Hopefully this helps Mojang find and fix the underlying problem for 1.14.1, because otherwise vanilla multiplayer servers will continue to experience game-breaking lag after players load so many chunks.

Nice! πŸ˜ƒ This opens up a bunch of new possibilities for functions. Thanks!

Still affects 1.14 full release

Still affects 1.14 full release

Indeed it is a duplicate. The current work-around is to supply SpawnPotentials explicitly:

/give @p minecraft:mob_spawner{BlockEntityTag:{SpawnCount:15,SpawnRange:3,MinSpawnDelay:1,MaxSpawnDelay:40,RequiredPlayerRange:1,SpawnData:{id:"minecraft:chest_minecart"},SpawnPotentials:[{Entity:{id:"minecraft:chest_minecart"},Weight:1}]}}

Confirmed for 18w11a, see screenshot.

[media]

Confirmed for 1.12-pre5. Also happens with structure blocks.