mojira.dev

Nick Bastin

Assigned

No issues.

Reported

MC-241416 Server crash: Class ... does not implement the requested interface java.util.Iterator Invalid MC-241215 Unspawnable areas become spawnable in upgrade to 1.18 Invalid MC-237399 1.18 snapshot server crash on IllegalMonitorStateException Awaiting Response MC-193428 Enemy shulkers no longer have subtitles for open/close Duplicate MC-193424 Odd end city generation behaviour Duplicate MC-168488 Mining pillars pushes you off Community Consensus

Comments

Possibly/probably a duplicate/related to  MC-254614.

This change completely sucked - ruined whole decorated builds of farms.  PLEASE DONT DO IT AGAIN.  Just leave the current map where it is.  This (and the ice/snow elevation biome change) completely screwed people who had old worlds that had built up full decorated farm areas which were no longer useful farms when we upgraded.  Please take a lesson from this and don't change it again, leave it well enough alone.

Was able to get zombie into minecart on wholly powered rails in survival 1.21.  They don't want to walk on rails so it takes a bit, but it will eventually pick them up (curves on normal rails are obviously more efficient).  The example appears to show unpowered rails, and getting a mob into a minecart that isn't moving is impossible (regular rails allow a mob to bump a minecart and then be captured when it moves). 

 

[media]

 

Seems like a feature request, not a bug.

This has been true (and relied upon) for years - bells illuminate illagers (and witches) at any time, not currently participating raid mobs.  Changing this would break a lot of server games that rely on this feature.

This is a bug in the way that wayland OSKs interact with XWayland, not with Minecraft.

The java minecraft window (nearly) always accepts keyboard events (even if you clear all the keybindings it still captures some non-configurable ones like F3), thus a dynamic OSK would appropriately show up when the window is focused.

"twitter" is an english word with verb usage from the 14th century and noun usage from the late 17th century.  The grammatical usage in the splash has nothing to do with the website.

There is no language list separator - it's a regional configuration specified in locale.  It is not universally available, so that can create some issues (although a value is typically available from the underlying OS at LOCALE_SLIST or similar).  If you wanted a per-language setting (not sure why, this seems much worse than using the configuration of the local host), you'd have to do something like carve out some PUA space for a custom "list separator" codepoint and have each translation supply it (but again, this would be as unexpected to users as using a comma all the time).

You could use the LC_COLLATE rules, but they've never been as complex as required to really solve the issue.  I'm not sure Mojang really wants "Pink, Lime, and Red", versus "Pink, Lime, Red", or, "Pink, Lime and Red", all of which are variants that you'd get in english switching between en_US and en_UK even (and of course you wouldn't want to redo the sort, as the order does matter for these values).

I can't reproduce this when using the nvidia X server on linux - I suspect it's related to some driver/compositor behaviour that is specific to the OP configuration.

This is another locale issue - the dots should be replaced by an actual ellipsis character, which then should be properly replaced based on the LC_COLLATE definitions in your current locale.

This is a locale problem, not a translation problem (it should use the list separator from the locale database, although they are not universally available but in that case falling back to comma seems fine).

I bonemealed about 60000 grass blocks in a new (1.18.1) single-biome world and did find some lily of the valley, although not much.  There were 19 lily of the valley, in two separate "clusters" - one cluster is 18, and one of....one.  They are still inside cornflower teardrops, but you need to find a very large cornflower area to get any reasonable number of lily of the valley spawn points (some cornflower areas are too small to have any, and of course some have such a small number - like one - that making a farm isn't really viable).

I've added 3 screenshots to the ticket of the area, and the two places where I found lily of the valley.  While it does spawn, it certainly seems like it is much too infrequent.  Also because Y values matter for the flower gradient now, your chances of finding them are ridiculously small.

This is definitely a problem for upgraded worlds - upgraded chunks in plains biomes will never generate a tulip (at least, we haven't found a place we can bonemeal for tulips yet).  Unfortunately, MC-244716 indicates that they are aware of and will not fix this issue.  Yet another case of "You can't really upgrade your old worlds, despite what we told you" for 1.18.

This is terrible - it ruins hundreds of hours spent on building out big farms with substantial decorations.  We were told we could upgrade our old worlds, but that was apparently not really true.

Same message here:

 

 

[09:59:54] [Server thread/ERROR]: Failed to save chunk 70,1006
java.lang.NullPointerException: Cannot read field "d" because "$$0" is null
        at ddm.b(SourceFile:23) ~[server-1.18%20Pre-release%201.jar:?]
        at com.mojang.serialization.codecs.RecordCodecBuilder$Instance.lambda$ap2$4(RecordCodecBuilder.java:215) ~[datafixerupper-4.0.26.jar:?]
        at com.mojang.serialization.codecs.RecordCodecBuilder$2.encode(RecordCodecBuilder.java:112) ~[datafixerupper-4.0.26.jar:?]
        at com.mojang.serialization.MapCodec$MapCodecCodec.encode(MapCodec.java:96) ~[datafixerupper-4.0.26.jar:?]
        at xz.a(SourceFile:34) ~[server-1.18%20Pre-release%201.jar:?]
        at xv.a(SourceFile:42) ~[server-1.18%20Pre-release%201.jar:?]
        at xv.encode(SourceFile:13) ~[server-1.18%20Pre-release%201.jar:?]
        at com.mojang.serialization.Encoder.encodeStart(Encoder.java:14) ~[datafixerupper-4.0.26.jar:?]
        at com.mojang.serialization.codecs.FieldEncoder.encode(FieldEncoder.java:24) ~[datafixerupper-4.0.26.jar:?]
        at com.mojang.serialization.MapCodec$1.encode(MapCodec.java:39) ~[datafixerupper-4.0.26.jar:?]
        at com.mojang.serialization.codecs.RecordCodecBuilder$Instance$4.encode(RecordCodecBuilder.java:222) ~[datafixerupper-4.0.26.jar:?]
        at com.mojang.serialization.codecs.RecordCodecBuilder$2.encode(RecordCodecBuilder.java:112) ~[datafixerupper-4.0.26.jar:?]
        at com.mojang.serialization.codecs.KeyDispatchCodec.encode(KeyDispatchCodec.java:92) ~[datafixerupper-4.0.26.jar:?]
        at com.mojang.serialization.MapCodec$MapCodecCodec.encode(MapCodec.java:96) ~[datafixerupper-4.0.26.jar:?]
        at com.mojang.serialization.Encoder.encodeStart(Encoder.java:14) ~[datafixerupper-4.0.26.jar:?]
        at dem.a(SourceFile:72) ~[server-1.18%20Pre-release%201.jar:?]
        at det.a(SourceFile:119) ~[server-1.18%20Pre-release%201.jar:?]
        at dfb.a(SourceFile:53) ~[server-1.18%20Pre-release%201.jar:?]
        at dev.a(SourceFile:81) ~[server-1.18%20Pre-release%201.jar:?]
        at cqn.a(SourceFile:421) ~[server-1.18%20Pre-release%201.jar:?]
        at cqn.a(SourceFile:373) ~[server-1.18%20Pre-release%201.jar:?]
        at acp.a(SourceFile:758) ~[server-1.18%20Pre-release%201.jar:?]
        at acp.a(SourceFile:516) ~[server-1.18%20Pre-release%201.jar:?]
        at java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:714) ~[?:?]
        at java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478) ~[?:?]
        at acp.b(SourceFile:497) ~[server-1.18%20Pre-release%201.jar:?]
        at acp.a(SourceFile:470) ~[server-1.18%20Pre-release%201.jar:?]
        at ada.a(SourceFile:323) ~[server-1.18%20Pre-release%201.jar:?]
        at adc.a(SourceFile:300) ~[server-1.18%20Pre-release%201.jar:?]
        at net.minecraft.server.MinecraftServer.b(SourceFile:876) ~[server-1.18%20Pre-release%201.jar:?]
        at acd.b(SourceFile:326) ~[server-1.18%20Pre-release%201.jar:?]
        at net.minecraft.server.MinecraftServer.a(SourceFile:820) ~[server-1.18%20Pre-release%201.jar:?]
        at net.minecraft.server.MinecraftServer.w(SourceFile:684) ~[server-1.18%20Pre-release%201.jar:?]
        at net.minecraft.server.MinecraftServer.a(SourceFile:270) ~[server-1.18%20Pre-release%201.jar:?]
        at java.lang.Thread.run(Thread.java:831) [?:?]

 

Neither my game, my launcher, nor my server is modified.  I presume the bot is complaining that the level was once loaded in Paper, and so there are some NBT tags on entities that are not vanilla.  That is not causing this problem...  If Mojang is going to reject these types of bug reports, there's really no point in many people trying to help test new builds.

This is evident in the jfr output as well - there are zero minecraft.PacketSent events recorded:

[media]

@Dl if you did it by recording who placed the block, now you'll be getting player kills from magma blocks, wither roses, etc. which wouldn't really make much sense.  Still, the question isn't really whether it can be done, it's a question of whether it makes any sense.  Attaching kills to the person who placed a block would, I think, be quite odd (or at least make stats even less useful - I didn't really kill all of the creepers in the creeper farm, but I did place the magma blocks....why should that count?).  Also of course end crystals are entities when you place them, which is quite different from tnt which is placed in block form.

For what it's worth, indirect tnt kills being credited in stats is the exception rather than the rule.  Killing something with flint and steel, lava bucket, pushing it off a cliff, etc., all are not regarded as player kills.  This is very useful for disposing of villagers, iron golems, pillagers, etc. without having to work around problematic side effects.