mojira.dev

DrHenchman

Assigned

No issues.

Reported

MC-187833 Highlight players (spectators) key still doesn't affect any players other than yourself Invalid MC-135254 Selector text components in JSON are not resolved correctly in written books for non-ops Duplicate MC-129912 Player no longer spawned at highest level at world spawn Fixed MC-129664 Player spawns underground in a block in the superflat redstone ready preset Duplicate MC-126413 Entity conditions for advancements triggers which can only be one type no longer allow you do omit the type condition Duplicate MC-117419 Advancement conditions with nbt data do not work correctly for inventory_changed Fixed

Comments

The workaround I am using is to put an empty text component at the beginning:

[{"text":""},{"text":"actual text","color":"blue"},{"text":"More text"}]

Ah thanks. I misread the original ticket and was concerned that it had not been fixed correctly. Sorry for the busy work

As a datapack developer, this is a huge issue for me. For example, when a player joined a server for the first time, I wanted to provide a personalised book which was addressed to them (using @s). Instead, they were presented with a page of text. Similar I maintain a UHC datapack which (which is reasonably well used by the community), I tried to make use named armor stands to provide toggleable controls in a book. Awesome features were added in 1.14 to allow for selecting NBT from entities and using them in JSON text but I can't make use of them because of this bug.

I believe I have experienced this same problem. I have attached two debug profiles taken a few minutes apart. There was 3 people on the server at the time, and one person was in there based with around 30 pillagers (maybe 6 different patrols) spread around the loaded chunks near them.

This should be possible to fix in Minecraft 1.14 now with the new additions to the loot table. For example, you could add this condition to the magma cube loot table and it would then be able to be applied Magma Cube's of all sizes rather than conditionally to medium and large in the code

"conditions": [
  {
    "condition": "inverted",
     "term": {
       "condition": "entity_properties",
       "entity": "this",
       "predicate": {
         "type": "minecraft:magma_cube",
         "nbt": "{Size:0}"
       }
     }
  }
]

Confirmed still an issue in 1.13-pre2

Put another way:

chunkX -= this.maxDistanceBetweenScatteredFeatures - 1;

is the equivalent of:

chunkX = chunkX < 0 ? chunkX - (maxDistanceBetweenScatteredFeatures - 1) : chunkX;

which when simplified is:

chunkX = chunkX < 0 ? chunkX - maxDistanceBetweenScatteredFeatures + 1 : chunkX;

Looks like this is a duplicate of MC-125744 which was fixed in 1.13-pre2

Still a problem in 1.13-pre1

I have investigated this further. It seems that there is now a #minecraft:valid_spawn tag and it only has grass_block and podzol in it and this tag determines what is a valid spawn place. If you change the fill command in the description to be grass_block instead of dirt, it works like 1.12.2. Is this an intentional change that only glass and podzol are valid spawn blocks? It seems like other blocks like stone, dirt and sand use to work and occur naturally on the surface of a world.

EDIT: I think I misunderstand how the valid_spawn tag is used. If I use a datapack to override it it doesn't change where you can spawn. Also, podzol doesn't work as a replacement to dirt with the fill command in the description to reproduce the 1.12.2 behaviour.

This bug causes problems for map makers. I have recently been working on a map which had a lobby above the world. In previous snapshots you'd spawn when you logged onto the server in the lobby and now you spawn underneath it.