litetex

Update 25w35a: Problem is still present affected method (yarn mappings) PlayerSkinWidget#isInteractable

Here is the same behavior on a not modified client:

@Greymagic27

The problem is also present in non modified versions of the game. Could you reopen the issue.

Code Analysis:

It looks like net.minecraft.client.gui.components.AbstractWidget#isMouseOver now checks if the element isNarratable???

This makes absolutely no sense, as the mouse can also be hovered over elements that are not narratable.

Okay, why was this closed as invalid now?

• The overall bug - which is experienced in the gameplay as "Rabbits usually fail to raid carrot crops" - is caused by having multiple pieces of broken code in the same file/behavior. So this is ONE bug/faulty behavior which is caused by multiple pieces of broken code.

• Also MC-150224 is a single bug despite having problems in at least 5 pieces of code...

• Each of them will require a separate fix though, and fixing one does not fix the others. Since they are not the same issue on different instances either (example: comma spliced strings), you should probably create separate reports for each problem.

  This is correct but to fix the broken behavior you need all fixes at once, otherwise the overall behavior will not be fixed.

  Also I have no idea what is meant with "example: comma spliced strings"

Depends on what you define as "thing"...

By the same AI-Goal? Yes
By the different pieces of code inside the goal? Yes

There are multiple problems inside rabbit pathfinding and related code causing this issue:
1. The calculation of the jump height/velocity is incorrect and poorly implemented. This results in too small jumps for climbing over a block (hops aren't high enough).
2. Rabbits sometimes "stall" (no horizontal movement) during jumps - due to this they just jump upwards in the same place when trying to climb a block.
3. Rabbits are stuck / try to wander around forever:

• The root cause is that PathNavigation#doStuckDetection sets its timeouts based on movement speed. If the movement speed is 0 (this is the case when a rabbit/mob is "stuck"), the timeout is also 0... and if the timeout is 0 it's ignored and therefore it's executed forever (or until interrupted by something external like another goal).

• Rabbits only have a single goal when idle: WaterAvoidingRandomStrollGoal/RandomStrollGoal. Most other entities also use RandomLookAroundGoal. Thus the above mentioned infinite navigation is likely never stopped in favor of executing another goal like in most other mobs.

• RabbitMoveControl#tick constantly updates the rabbits speed (Rabbit#setSpeedModifier). While doing this it also indirectly executes moveControl#setWantedPosition thus the rabbit always tries to reach it's last target even when it shouldn't do that.

Further helpful links:

• Video comparison showcasing the problems in more detail

• Reference implementations of the fixes

See also: MC-277500

Just for further reference:
This likely describes the same problem as I already mentioned in https://bugs.mojang.com/browse/MC-274911#comment-1347741

 No, that was even before the MC-274911 report was resolved. That issue is MC-275279 and MC-275007

This new code is not present in 1.21.1, so it's not possible that this happend before.
MC-275279 is affecting only 24w33a, so it's likely the same problem as I described below.
MC-275007 is likely working as intended as it has been this way for years. The behavior is also described in the wiki.

So I just had a look at this "bugfix" and I think it has a problem:

At first let's have a look at the code. It looks roughly like this:
Raid#findRandomSpawnPos(int proximity, int tries) looks like this

int i = proximity == 0 ? 2 : 2 - proximity;
// ...
int y = this.world.getTopY(Heightmap.Type.WORLD_SURFACE, x, z);
if (MathHelper.abs(y - this.center.getY()) > 32 * i) continue;  // <-- this line is new and is the fix for this "bug" here

Now to the code's behavior:
The changes effectively limit the vertical distance (Y) where a raid wave can spawn, limiting the "ring" like structure on the "top and bottom".
However the vertical distance is not hardcoded to the mentioned 112 blocks in the issue but instead dynamically derived from the proximity/"ring" of the spawn location.
The higher proximity the closer it spawns to the center of the raid.

I think that these values e.g. for the are way to small and result in unexpected behavior, for example:

• When the proximity is 2 (innermost "ring") - which is btw what every raid farm uses - it's nearly impossible (spawnable blocks are picked at random in the "ring") to get a raid spawned as the y distance of the spawn location now has to be exactly 0.
  Here's a showcase:

• Although very unlikely this might also affect normal villages that sometimes generate in very rough terrain (e.g. a cliff or on small islands in the ocean) which might cause all spawn attempts to fail - resulting in the raid just vanishing

I would propose the following solutions in preferred order:

1. If possible revert this change - Which naturally generated village is 112 blocks away from the ground in the first place?
2. If reverting is not an option: Make the innermost ring ignore the Y difference limit, to force the raid to spawn and not "vanish"
3. Increase the Y difference. At best to a static value like the mentioned 112 blocks in the issue.

Code analysis

using Fabric's Yarn mappings 24w14a+build.5

Problem 1 & 2 are caused by the fact that the corresponding code is no longer present inside the Raid/RaidManager classes.
The other problems are caused inside Raid#start(ServerPlayerEntity) because the checked StatusEffect is RAID_OMEN (not BAD_OMEN)

Seems like the error happens in net.minecraft.world.entity.ai.memory.ExpirableValue#<init> (seems new, couldn't find it in 20w06a) in this code block:

public ExpirableValue(Function<Dynamic<?>, T> var1, Dynamic<?> var2) {
      this(var1.apply(var2.get("value").get().orElseThrow(RuntimeException::new)), var2.get("expiry").asLong(9223372036854775807L));
   }

The method is called from net.minecraft.world.entity.ai.Brain#readMemory(net.minecraft.world.entity.ai.memory.MemoryModuleType,com.mojang.datafixers.Dynamic)

private <T, U> void readMemory(MemoryModuleType<U> var1, Dynamic<T> var2) {
      ExpirableValue<U> var3 = new ExpirableValue((Function)var1.getDeserializer().orElseThrow(RuntimeException::new), var2);
      this.setMemoryInternal(var1, Optional.of(var3));
   }

and that is called from net.minecraft.world.entity.ai.Brain#<init>

private final Map<MemoryModuleType<?>, Optional<? extends ExpirableValue<?>>> memories = Maps.newHashMap();
...

   public <T> Brain(Collection<MemoryModuleType<?>> var1, Collection<SensorType<? extends Sensor<? super E>>> var2, Dynamic<T> var3) {
...
      Iterator var4 = var3.get("memories").asMap(Function.identity(), Function.identity()).entrySet().iterator();

      while(var4.hasNext()) {
         Entry<Dynamic<T>, Dynamic<T>> var5 = (Entry)var4.next();
         this.readMemory((MemoryModuleType)Registry.MEMORY_MODULE_TYPE.get(new ResourceLocation(((Dynamic)var5.getKey()).asString(""))), (Dynamic)var5.getValue());
      }

looks like something is feed, where the value-Attribute is missing.

Memories of a villager (from 20w06a) that is lost in 20w07a:

Log file of 20w07a:

The problem is caused because neither

net.minecraft.server.commands.TeleportCommand#performTeleport(CommandSourceStack, Entity, ServerLevel, double, double, double, Set<ClientboundPlayerPositionPacket.RelativeArgument>, float, float, TeleportCommand.LookAt)

nor

net.minecraft.server.network.ServerGamePacketListenerImpl#teleport(double, double, double, float, float, Set<ClientboundPlayerPositionPacket.RelativeArgument>)

are checking if the target would be inside the world border

Did you use --workDir? → http://hopper.minecraft.net/help/guides/changing-work-directory/

Got the same result when replacing

"clientToken" : "<clientToken>"

with

"clientToken" : ""

[Info: 2019-10-21 18:28:39.8820726: NetQueue.cpp(401)] NetQueue: Primary ip: 13.227.134.21, Url: launchermeta.mojang.com
[Info: 2019-10-21 18:28:39.8821272: NetQueue.cpp(472)] NetQueue: Action finished: https://launchermeta.mojang.com/mc/game/version_manifest.json?_t=2019-10-21T18:28:39Z
[Info: 2019-10-21 18:28:39.8821484: GameVersionManager.cpp(160)] Got available versions manifest from https://launchermeta.mojang.com/mc/game/version_manifest.json?_t=2019-10-21T18:28:39Z
[Info: 2019-10-21 18:28:39.8878816: NetQueue.cpp(401)] NetQueue: Primary ip: 13.227.135.68, Url: authserver.mojang.com
[Info: 2019-10-21 18:28:39.8879176: NetQueue.cpp(433)] NetQueue: Action failed with result "The requested URL returned error: 403 Forbidden" (22) : https://authserver.mojang.com/validate
[Info: 2019-10-21 18:28:39.8879380: NetQueue.cpp(472)] NetQueue: Action finished: https://authserver.mojang.com/validate
[Info: 2019-10-21 18:28:39.8880291: EndpointAPI.cpp(128)] Error: The requested URL returned error: 403 Forbidden, Code: 403
[Info: 2019-10-21 18:28:39.8881162: NetQueue.cpp(534)] NetQueue: Starting net action https://authserver.mojang.com/refresh
[Info: 2019-10-21 18:28:39.9383705: LauncherAppRenderer.cpp(217)] Creating renderer context...
[Info: 2019-10-21 18:28:40.1689038: NetQueue.cpp(401)] NetQueue: Primary ip: 13.227.135.68, Url: authserver.mojang.com
[Info: 2019-10-21 18:28:40.1689592: NetQueue.cpp(433)] NetQueue: Action failed with result "The requested URL returned error: 403 Forbidden" (22) : https://authserver.mojang.com/refresh
[Info: 2019-10-21 18:28:40.1689840: NetQueue.cpp(472)] NetQueue: Action finished: https://authserver.mojang.com/refresh
[Info: 2019-10-21 18:28:40.1690915: EndpointAPI.cpp(128)] Error: The requested URL returned error: 403 Forbidden, Code: 403
[Error: 2019-10-21 18:28:40.1780104: LauncherController.cpp(388)] INVALID_CREDENTIALS

Can't confirm this. Restarted my PC and still was automatically logged in.

→ Check MCL-12347

Experiencing the same problem

Everything is normal in the log file beside this:

[Error: 2019-10-20 17:40:25.2943514: LauncherController.cpp(388)] NO_USER_SELECTED

Maybe the access token expires? - because it doesn't happen if you stop and start the launcher immediately...

Edit:
I also noticed that the launcher_profiles.json doesn't contain a profileId and a userId under authenticationDatabase/<SomeHash>/properties:

{
  "analyticsFailCount" : 0,
  "analyticsToken" : "<analyticsToken>",
  "authenticationDatabase" : {
    "bd49bb76f93cbd155eee1e85724ad227" : {
      "accessToken" : "<accessToken>",
      "profiles" : {
        "2770e2ff3f19438682ea1fcc370ffc94" : {
          "displayName" : "<displayName>"
        }
      },
      "properties" : 
      [
        {
          "name" : "registrationCountry",
          "profileId" : "", //←!!!
          "userId" : "", //←!!!
          "value" : "DE"
        }
      ],
      "username" : "<email>"
    }
  },
  "clientToken" : "<clientToken>",
  "launcherVersion" : {
    "format" : 21,
    "name" : "2.1.3674",
    "profilesFormat" : 2
  },
  "profiles" : {
    //...
  },
  "selectedUser" : {
    "account" : "bd49bb76f93cbd155eee1e85724ad227",
    "profile" : "2770e2ff3f19438682ea1fcc370ffc94"
  },
  "settings" : {
    "channel" : "release",
    "crashAssistance" : false,
    "enableAdvanced" : true,
    "enableAnalytics" : false,
    "enableHistorical" : true,
    "enableReleases" : true,
    "enableSnapshots" : true,
    "keepLauncherOpen" : true,
    "locale" : "de-DE",
    "profileSorting" : "ByLastPlayed",
    "showGameLog" : true,
    "showMenu" : true,
    "soundOn" : false
  }
}

Which leads me to the assumption that the clientToken stays active for a amount of time (maybe one day?), but when it expires the launcher is unable to get a new one from the servers with the accessToken.

EDIT2:
Just found this out:
If you delete clientToken (replace "<Token>" with ""), the launcher doesn't generate a new one, beside having a accessToken and "remeberMe" enabled, you have to reenter your credentials.

@Knobel Max

Check → https://www.minecraft.net/en-us/download/alternative/

You are using the old java (alternative) launcher, use the new one (recommend) instead

Check if your graphics cards driver is up to date. Updating it might help.

# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 268435456 bytes for Failed to commit pages from 229376 of length 65536
# An error report file with more information is saved as:
# C:\Users\varun\AppData\Roaming\.minecraft\hs_err_pid1680.log
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x00000000b8000000, 268435456, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)
20:32:35.378

Looks like you have not enough RAM for me...

Check if your PC fits the minimum system requirements: https://help.mojang.com/customer/en/portal/articles/325948-minecraft-java-edition-system-requirements

Check with your TaskManger if any other program uses a lot of RAM and try to close it (close no programs that are essential for your system, your computer may crash)

Another option:
If that doesn't help start Minecraft with less RAM.
Open the Launcher goto "Minecraft Java Edition">"Installations">Edit your used profile>"More options">"JVM Arguments" replace -Xmx2G ... with -Xmx1G ....
This may cause minecraft performance issues, but at least it should start your game 🙂