Earthcomputer

Cannot reproduce. Note that in 25w09a, random ticks were changed from happening in block ticking chunks to only entity ticking chunks, which means that random ticks now only happen in the exact chunk the ender pearl is in. Make sure there isn’t a chunk border between the ender pearl and the grass in your setup.

Fair but this one is particularly inconvenient and unexpected

I have added reproduction steps to the description, even though most people who know how datapacks work should have been able to figure them out.

If you're gonna make ender pearls load chunks on portal cooldown, imo you may as well make them load chunks all the time. It's easier to implement and would allow for much easier ender pearl cannon contraptions.

I cannot reproduce using MC@h Matt 's repro instructions. I can only assume that their JavaRnd implementation is not equivalent to Mojang's RandomSource, or maybe that Mojang fixed it since the issue was reported. Here's the code I ran using Mojang's actual RandomSource:

Random rand = new Random(4398074666259L);
System.out.println(rand.nextInt(53));

RandomSource rand2 = RandomSource.create(4398074666259L);
System.out.println(rand2.nextInt(53));

And the output:

30
30

I think this issue can be closed.

Mojang's code in `next` looks like this:

public int next(int i) {
    long m;
    long l = this.seed.get();
    if (!this.seed.compareAndSet(l, m = l * 25214903917L + 11L & 0xFFFFFFFFFFFFL)) {
        throw ThreadingDetector.makeThreadingException("LegacyRandomSource", null);
    }
    return (int)(m >> 48 - i);
}

So isn't `m` always positive here? I don't see where the difference between >> and >>> in this case

It looks like this game event has been removed.

(for future reference, your UUID isn't private information, you can see other players' UUIDs when hovering over their name in chat, and there are websites where you can look up a player's UUID by their username).

According to cortex, this is caused by the new jfr profiler support.

Hi, can someone please transfer the reporter from me, as I'm no longer interested in this issue and I get emails from it despite not watching it.

Note that the proposed fix still has a slight bias towards the northwest (with both stalagmites and stalactites). This is due to rounding down when the windSpeed is actually added to the position in the "offset" method. To remove all bias, in addition to the fix above, the windSpeed needs to be rounded with e.g. Math.round() when added to the position in "offset".

Thanks Sherlock

Confirmed for 1.16.3

This is caused by a refactor, which looks like it happened in 1.13, to block entity rendering. In 1.12, `BlockEntityRenderer.render` used to render the display name of a block entity if it had a name to display. `StructureBlockRenderer.render` used to call the superclass method. Now (at least in 1.16), the `BlockEntityRenderer.render` method is abstract and the code for rendering nameplates appears to have been removed (either by accident or by proguard).

As a side note, in 1.12, most block entities didn't call `super.render` even though the corresponding block entities overrode the method to get the nameplate, so didn't end up displaying the nameplate, which was probably a bug.

Can confirm Marcono's comment that this is caused by the seeds being too similar to each other due to being initialized to the current time in milliseconds. Before producing any outputs, a Random object will multiply the seed you give by 0x5deece66d; there are 50ms in a tick, so you could expect the internal seed of the Random to differ by a maximum of approximately 0x5deece66d * 50 = 1‚260‚745‚195‚850 (give or take a few milliseconds). This make look like a lot, but nextFloat() < 0.5 will only be true if this internal seed is between 0 and 2^47 (mod 2^48), which about 100x larger. This explains the delay of seconds you can see.

The other blocks in the structure are not as noticeably affected, as repeated multiplication of 0x5deece66d (and then addition of 11 which I left out for simplicity) quickly scrambles seeds even if they started close together.

P.S. can confirm for 1.16.3

Could this be https://github.com/glfw/glfw/issues/747 ?
In that case, this bug would be fixed by updating the version of glfw that Minecraft uses to 3.3.

By the way, if this is the issue, then to have the best chance of reproducing it, you want to use the X11 window manager, and make sure the game is running at a low framerate (client-side lag).

Works as intended. This is because the string only updates the observer every 10gt (half a second). So if you fly through the string and exit it within half a second, it will only update the observer once and leave the dispenser on. You need to redesign your contraption to work around this issue.

It looks like the obfuscated text splash text, which is works as intended.

The actual bug here is not that it is being read as an unsigned byte, it's that not_set is being sent in the first place. As I explained in the previous comment, this causes issues whether it's read correctly or not. The real fix is to do the logic that the game mode switcher screen currently does for the initial game mode, on the server, rather than on the client, so that not_set doesn't have to be sent in the first place. Or else the client can send "/gamemode " with no arguments.

It should be pointed out that this bug report is quite misleading as to what the actual issue is here. writeByte is the method which should be used to write both signed and unsigned data, so the issue isn't a mismatch with serialization.

The actual effect of this issue is that in multiplayer, previousGameMode is deserialized as survival mode when the server sends not_set, whereas in singleplayer (since packets aren't serialized) it is decoded as not_set. This would cause the client to send /gamemode survival when pressing f3+n for the first time if the player starts off in spectator mode, and /gamemode with no argument in singleplayer (although I'm not sure it's possible to first spawn in spectator mode in singleplayer). It also causes different defaults of the game mode GUI depending on whether it's singleplayer or multiplayer, and I think the defaults for singleplayer are the intended behaviour.

@Mish Rodic you mean 22a? I can't confirm in 21a, only 22a.