Mobs moving / jumping too Slow

This is MC-58120. Will happen in worlds created / openened with 14w2x / 14w3x snapshots. Delete the worlds and create a new one in 1.8

No, it isn't. It's happening on every new world I create in 1.8 pre-2, regardless of domobspawning on or off. All other entities do not lag at all. This is a new issue.

I have changed the video and put annotations in there, since it is describing this bug more correctly:
http://youtu.be/Bdfs8a3UfKg

(Feel free to put the link in the description of the bug if you think it helps describe the issue.)

Thank you, Kumasasa.

I'll take a look, Walden, thanks.
EDIT Just commented on the video, the vid didn't quite show the bug correctly. It did show that old worlds seem to have excessive lag, or at least worlds with a lot of content. I suggest re-doing the video like I said in the comment.

@unknown: Ok, lets continue the discussion in the comments on the video. I am willing to do more extensive testing.

I've got this exact same problem in my game, on both 1.8 and 1.8.1; I can confirm that it happens in brand new worlds as well. I don't have any older world saves installed on my game. No matter what new world I create, I've got this same problem. My original ticket that I put in early this morning was MC-75875, which has been marked as a duplicate bug to this one.

Yes Daniel, I've reported a series of mob "lagginess" problems that you're experiencing. Don't worry, everyone is experiencing these issues, but some people just brush it off as if it's nothing. In reality, these problems with mobs are more game-breaking then many people think. They make mobs significantly easier to kill, while making it seem like the user's computer is too slow, confusing many people.

Guys? Do mean that when you hit the mobs they don't react to it? Because I have been noticing that when you hit a mob, well a hostile one, it doesn't seem to attack you after you do, like it should. It does make them way to easy to kill. They just stand there like, huh i don't know what I'm doing'.. then after a moment or so it finally decides it wants to kick your butt. I thought maybe it was intended but now I am thinking it's a little strange..

EDIT: I am using 1.8.2pre6

Tiya tehJak, yes, this is the exact same problem that I've been having; the hostile mobs just basically refuse to react when you attack them, no matter what difficulty, etc. Personally, I still think it's a problem due to the coding changes with Creepers (and how other mobs react to them), but maybe it's some sort of other problem. And, yes, even tested the newest pre-release for 1.8.2 and it still exists. Looks like I'm going to have to skip 1.8 altogether and hope 1.9 fixes this stuff.

I can confirm this still happens in the full version 1.8.2

Still occurring with 1.8.3 full version.

Confirmed the Squid test case on 1.8.7
Squids' movement/gravity is different from the rest of the mobs.

Gravity for mobs is generally handled by their AI, though that is a bit counter-intuitive. Squid movement is presumably different because they can only move underwater – though I wonder how it compares to guardians. What people are experiencing is probably a result of all mobs now using the "new" AI system. Whether the behavior is intended, or the desired behavior wasn't accurately reproduced when recreated in the AI system, Mojang will have to determine.

For me, mobs were, at one time, getting knocked back in slow motion and they moved very slowly, again as if they were in slo-mo, right after the update to 1.8. This doesn't seem to be the same issue.

This has been the absolute most annoying bug for me in 1.8, and I've looked into finding the issue more than once. I finally found it.

Using MCP's mappings, go to EntityLivingBase.moveEntityWithHeading. Comment out the line "if (this.isServerWorld())". Fixed. Or at least fixed back to previous standards, complete with the minor stuttering of motion (probably caused by frequent position update packets, which should probably be tweaked to avoid that somewhat, but that's another issue).

But yeah, the movement wasn't being handled on the client like before, and was only happening through server-side packets, which completely loses the feel of the way the game used to work, and completely ruined it in my opinion.

EDIT: Here's a tweak class mod (compatible with Forge) to demonstrate: www.fybertech.net/minecraft/physicsfix-mc1.8-1.1.jar

I'm not sure if that's a good idea. I don't know much about programming, but wouldn't that cause a client-server desync for mob position if there were lag?

It shouldn't make any difference, it's literally how 1.7.10 works. Previous versions all ran that block of code on both client and server.

The server sends periodic forced position updates anyway. And I played for quite a while and didn't see any adverse affects, other than the same issues it used to have of not being particularly smooth sometimes. I think even the rabbits work better.

If that's the cause, then it's unlikely to be changed back. Their stated goal is to move as much game logic as possible to the server, for both security and so that plugins can modify it. In single player, it shouldn't matter whether it's on the client or server, since they're both being run on the same machine. In a multiplayer environment, mobs shouldn't be any less responsive than other players are. If that's not the case, then maybe there's something wrong with how that data is being synchronized. I believe some major cleanup is being done on entities for 1.9, so this issue may be addressed in the process. @unknown, what about the difference in squid behavior reported in the issue description? Is squid movement still handled in the client in 1.8?

The motion is different when it's only executed on the server because it goes through quite a different pathway of code before the changes are ever applied on the client, likely at least a tick later, and when they finally are, it's smoothed across 3 more ticks by default. I've disabled the smoothing before and it doesn't help; the severe stuttering between packets just looks even worse.

Squid are unaffected because they override moveEntityWithHeading and execute a single function (to directly apply movement). There is no server-side check here, which is why it's immediate for that particular mob. Either it was overlooked, or putting the check into EntityLivingBase's version was unintended.

Any advantages they gain by turning Minecraft into a dumb terminal are going to be negated by the resulting loss of response in the client, even in singleplayer, no matter how much they optimize the network code. The game has never had the same responsiveness as 1.2.5 because network packets are always trying to update position and velocity throughout the client's own animation. Although I do agree that some amount of update packets are still necessary to prevent them going out of sync altogether. Pre-1.8 felt like both systems were fighting one another, while 1.8 avoids the fight at the cost of response. There's got to be a better balance. But I'd take the moderate stutter from before than 1.8's solution any day.

This bug is extremely visible (for me at least) in 15w31a.

Yes, I'm sad to say that the same holds true for me... I was so hoping that once 1.9 rolled out, the bug would be fixed, but yes, it's still here and very noticeable in the newest snapshot.

Confirmed in 15w31b.

Confirmed for 15w32b.

Confirmed for 15w33c.

Still in 15w35b.

Still in 15w39c

a quick report:

Completely ignored arguments: [--nativeLauncherVersion, 286]
[20:01:14] [Client thread/INFO]: Setting user: Eela11
[20:01:15] [Client thread/INFO]: LWJGL Version: 2.9.4
[20:01:15] [Client thread/INFO]: Reloading ResourceManager: Default
[20:01:15] [Sound Library Loader/INFO]: Starting up SoundSystem...
[20:01:15] [Thread-5/INFO]: Initializing LWJGL OpenAL
[20:01:15] [Thread-5/INFO]: (The LWJGL binding of OpenAL.  For more information, see http://www.lwjgl.org)
[20:01:16] [Thread-5/INFO]: OpenAL initialized.
[20:01:16] [Sound Library Loader/INFO]: Sound engine started
[20:01:16] [Client thread/INFO]: Created: 512x512 textures-atlas
[20:01:21] [Server thread/INFO]: Starting integrated minecraft server version 15w39c
[20:01:21] [Server thread/INFO]: Generating keypair
[20:01:21] [Server thread/INFO]: Preparing start region for level 0
[20:01:22] [Server thread/INFO]: Changing view distance to 32, from 10
[20:01:22] [Server thread/INFO]: Eela11[local:E:8679785b] logged in with entity id 275 at (722.1176362253076, 64.20000004768369, 464.9125326938397)
[20:01:22] [Server thread/INFO]: Eela11 joined the game
[20:01:28] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 5546ms behind, skipping 110 tick(s)
[20:01:54] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 15290ms behind, skipping 305 tick(s)
[20:01:56] [Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2045ms behind, skipping 40 tick(s)
[20:02:13] [Server thread/INFO]: Saving and pausing game...
[20:02:13] [Server thread/INFO]: Saving chunks for level 'New World'/Overworld
[20:02:17] [Client thread/INFO]: Stopping!
[20:02:36] [Server thread/INFO]: Saving chunks for level 'New World'/Nether
[20:02:36] [Server thread/INFO]: Saving chunks for level 'New World'/The End
[20:02:37] [Client thread/INFO]: SoundSystem shutting down...
[20:02:37] [Server thread/INFO]: Stopping server
[20:02:37] [Server thread/INFO]: Saving players
[20:02:37] [Server thread/INFO]: Saving worlds
[20:02:37] [Server thread/INFO]: Saving chunks for level 'New World'/Overworld
[20:02:37] [Server thread/INFO]: Saving chunks for level 'New World'/Nether
[20:02:37] [Server thread/INFO]: Saving chunks for level 'New World'/The End
[20:02:37] [Client thread/WARN]: Author: Paul Lamb, www.paulscode.com
Java HotSpot(TM) 64-Bit Server VM warning: Using incremental CMS is deprecated and will likely be removed in a future release

Confirmed for 15w40b. I noticed it when I spawned a bunch of skeletons.

Anyone having this issue, please ZIP that world and attach it here.

Can anyone confirm this in 16w06a ? There might be some related / same issue: MC-96848

It's getting better but not like 1.7.10 and before. Go into 1.7.10 and just hit mobs in creative and go back to 16w06a and you'll see a huge difference in performance. So I can confirm.

I have to say that it has improved it looks nice and fluent and the mobs look like they have weight to them.

@Kumasasa Could it be that they are seeing the hang time of the mobs when you hit them back? I didn't think about that until now. That hang time is normal I believe that isn't a bug but in 1.9 pre 1 the hang time looks much more fluent (better) than it did in older versions. In previous ones, the hang time was jagged and appeared as if there was a lagging problem. But i think it looks great now. Mobs are jumping up onto blocks very nicely!!

The same problem occurs only in the overworld on PS3. In Nether, mobs normally moves. Sorry for my bad english.

@unknown: Please report that at https://bugs.mojang.com/browse/MCCE

Is this still an issue in the most recent versions (currently that is 1.10.2, or 16w43a) of Minecraft? If so, please update the affected versions and help us keeping this ticket updated from time to time. If you are the owner/reporter of this ticket, you can modify the affected version(s) yourself.

Still an issue in 1.10.2. (It gets more noticeable if you have mods installed.) (I haven't checked 1.11.2, so can't confirm if there too)
I know mods doesn't counts for vanilla. (mod mentioning is for referencing: vanilla 1.7 (& heavily modded too) and before is the contrary; in lag environments hostile mobs insta-kill instead of lagging)

Thanks for reading, and I hope this helps. Will check if the problem is still on latest snapshot.

EDIT: Still a issue in latest snapshot (17w06a)

Affects 1.13-pre1

Does this bug also affect players in multiplayer?

@unknown, ticket is yours now.

Confirmed for 1.13-Pre5

Confirmed for 1.13.1.

Is 1.14.4 or 19w39a the same? I don't have observational experience about this, so I'm not helpful to judge.

Yes it occurs in bedrock 1.14 as well

Still in 20w12a

This may be caused due to the AI update of 1.2 and 1.8, where mobs now bounce back without moving their body and they no longer jump.

Can confirm in 1.17.1.

In 1.20.1

In 1.20.2 Pre-Release 2

In 1.20.2 Release Candidate 1

In 1.20.2

As @fyberoptic has pointed out, this bug is due to the client no longer predicting the position of entities and relying on server packets, which they ssmooth the position accross 3 ticks. There is no easy fix: one fix would, as Jeff did, revert the change made in 1.8 to client prediction: but this would bring back the stutterness caused by conflict between client prediction and server packets. Another solution, which seems more viable to me, is increasing the rate of packets sent by the server, which would eliminate the need for linear interpolation which cause the visual slowness: however, sending entity packets every tick has its own share of issues, but it could be considered for integrated servers (Singleplayer) as no real network traffic is required for packets between the server and the client.

I have tried implementing such fix on a personal mod, where I simply forced the server to send entity move packets every tick instead of using their built-in update interval, and client-side I would disable the linear interpolation and directly set the position: the result looks similar to 1.2.5 SSP mobs, minus the slight (but virtually invisible) latency between Client and Server. However, the downside of this is that a slight tick lag would cause all mob movement to stutter and be unsmooth, but at least it isn't a glaring issue.