Jono
- lapppy
- lapppy
- America/Denver
- Yes
- No
For example, the vanilla advancement "Monsters Hunted" contains a criteria called {{"minecraft:zombie". }}
Attempting to grant or revoke this criteria results in the following error:
Expected whitespace to end one argument, but found trailing data at position 73: ... minecraft<--[HERE]This also affects the vanilla advancements "Adventuring Time" and "Two by Two",
To reproduce:
- Start a new world
- run "/advancement grant @p only minecraft:adventure/kill_all_mobs minecraft:zombie{{}}
Probably related to the fix of MC-124048
For example, the vanilla advancement "Monsters Hunted" contains a criteria called "minecraft:zombie".
Attempting to grant or revoke this criteria results in the following error:
Expected whitespace to end one argument, but found trailing data at position 73: ... minecraft<--[HERE]This also affects the vanilla advancements "Adventuring Time" and "Two by Two",
To reproduce:
- Start a new world
- run "/advancement grant @p only minecraft:adventure/kill_all_mobs minecraft:zombie
Probably related to the fix of MC-124048
For example, the vanilla advancement "Monsters Hunted" contains a criteria called "minecraft:zombie".
Attempting to grant or revoke this criteria results in the following error:
Expected whitespace to end one argument, but found trailing data at position 73: ... minecraft<--[HERE]
This also affects the vanilla advancements "Adventuring Time" and "Two by Two",To reproduce:
- Start a new world
- run "/advancement grant @p only minecraft:adventure/kill_all_mobs minecraft:zombie
Probably related to the fix of MC-124048
For example, the vanilla advancement "Monsters Hunted" contains a criteria called "minecraft:zombie".
Attempting to grant or revoke this criteria results in the following error:
Expected whitespace to end one argument, but found trailing data at position 73: ... minecraft<--[HERE]If you remove the "minecraft:" from the command, you get
The advancement [Monsters Hunted] does not contain the criterion 'zombie'This also affects the vanilla advancements "Adventuring Time" and "Two by Two",
To reproduce:
- Start a new world
- run "/advancement grant @p only minecraft:adventure/kill_all_mobs minecraft:zombie
Probably related to the fix of MC-124048
Jono 100% agree, it's a very generalized/diffuse title, lag can have tons of different reasons.
Maybe we should go into according bugposts that are more specified to a lag reason.
But thank you very much to your general positive statement:
| Let's be honest, do we really expect path finding with a ton of mobs to cause absolutely zero lag whatsoever? While that would be great, i'm sure that any video game that is forced to do something like this (deal with A TON of entities and path finding calculations at the same time) would have some sort of a performance issue. |
@Jono: Can you please stop bullying other users . If other users say "this is not a discussion forum" then for sure it's justified.
@All: STOP. This is not a discussion forum. For any meta discussion please use https://www.reddit.com/r/Minecraft


I can confirm this bug. Framerate is about 120fps, but when charging a bow it drops down to 70fps.
In fullscreen the effect is more noticeable.
I've attached a crash report.
Confirmed for 1.5.1 pre-release.
It has the biggest effect is in full screen.
Confirmed for snapshot 13w23b.
Did some quick testing, and I can confirm this is fixed in 13w24a!
Thanks Dinnerbone!
Had this bug today while playing a UHC style game with my brothers. It was quite annoying!
After the effects of the apple wear off, the scoreboard continues to display the wrong number until the player takes damage a couple of times.
Confirmed, and please fix!
EDIT: Confirmed for 13w24a
This seems mostly fixed in 13w24b, however it is not completely fixed.
The scoreboard still does not take into account the two extra hearts from the new 'absorption' effect but is still accurate with the first 10 hearts (20points)
Pictures attached...
Confirmed in 13w24b.
CONFIRMED IN 13w25a using the following steps:
0. (Create a new world...)
1. Give a zombie a diamond sword.
2. Use the command /tp ~0 ~150 ~0. This will despawn all mobs except the one you gave the item to.
3. Change to survival mode
4. Observe damage dealt to be 1.5 hearts.
I did this bug on a freshly made superflat world.
Because some people couldn't reproduce this, I followed the same steps twice. The bug happened both times.
The difficulty was set to normal.
I would also like to point out that I did not use a zombie from a spawn egg or any mob spawner, the mob was spawned naturally at night time.
Confirmed in 13w25c.
Playing 1.6.1 today... I got right in the face of a skeleton who happened to have an enchanted bow and the frame rate dropped very quickly.
This bug is very annoying...! :/
Confirmed in 1.6.1.
Saw this today while playing!
Confirmed in 1.6.2
This can be replicated with a short link as well when the 'width' setting in the options is very low.
Saw this today while playing on a server, the animals that were hit would not stop running around in their pen until the player who hit them logged out.
Might be related to the fix of
MC-18976This is still in 1.6.2.
I have the optifine preview for 1.6.2 installed and this issue is not fixed (as expected).
I also did some more testing. My average framerate is around 60-70 fps. If there is an enchanted item on the screen, the framerate drops to 40-50fps. if an enchanted item takes up a large view of the screen (drawing back a bow, drinking a potion, standing right beside mobs with enchanted armour, etc) the framerate drops below 20.
@Jesse
Worked liked a charm, thanks for those links!
It will have to do until an official fix is made.
I can no longer reproduce this! Can anyone else?
I'm not sure which snapshot or version seemed to fix this, and I don't have time to find out right now for sure.
It was probably fixed in snapshot 13w26a with
MC-17571Well, this explains why seemingly random IP's appear to be 'pinging' my server... I always thought it was one of those dumb Minecraft server lists or something trying to get server info, but that must not be the case!
The server that I run has only five or six players on it but these end of stream messages flood the console and thus the server log very quickly.
It would be nice to get a fix for this! Confirmed over here.
I can still confirm this in 1.6.2, as of July 31.
Crash report attached.
And, I've also created a video to show the problem. I feel that screenshots don't really show this bug well.
http://www.youtube.com/watch?v=7tQWZ9MYf50
Note that my framerate is usually higher, but Fraps limited my fps in the video to 50fps.
I was using that driver (307.83) when I made the crash report, and when recording the video.
I also noticed this bug earlier in 1.6.2.
Confirmed (for me, at least...) in 13w36b.
That crash from
MC-3973is unrelated to the original bug report, which was:Unless my eyes fail me, I believe that there is no mention of a crash there, and no mention of world corruption either.
So, this report should either be reopened or
MC-3973should be updated completely to reflect the new crash (Not just the title).Confirmed on a Nvidia card.
Confirmed in 13w42a.
I am having this issue in 1.7.4.
Confirmed in 1.7.4.
Also confirming for 14w02c.
I can safely walk around in survival at night on hard difficulty. Mob spawning should be high, but there are hardly any hostile mobs.
Confirmed in 14w02c.
Confirmed.
Confirmed for 1.7.5 (of course!) :/
Confirmed in 14w08a.
Note that this bug does not seem to affect my laptop with Intel HD 3000 Graphics. I personally have only seen it on NVIDIA and AMD graphics.
Confirmed 14w18b.
Was the world created before 14w20a? Probably related to
MC-48442.14w29b and 14w30c have very bad server performance. Not just internal server singleplayer, but also dedicated multiplayer.
Attached a debug log from 14w30c on a flatmap.
EDIT: /gamerule doMobSpawning false removes the lag. Ok for my creative server but not so much for survival.
Seems to be fixed on 14w31a but I'm not sure.
Anyone still having this bug: if you set "/gamerule doMobSpawning false", does the bug go away?
Affects 14w31a.
Still in 14w31a.
Setting "/gamerule doMobSpawning false" seems to stop it (for me at least), but that prevents mob spawning.
@Dinnerbone Can you at least look at some of the causes of this? Natural mobspawning causes huge tick lag in the recent snapshots which is most likely a common reason for this crash.
https://bugs.mojang.com/browse/MC-58120
https://bugs.mojang.com/browse/MC-63708
Confirmed in 14w32a
Confirmed in 14w32a.
Confirmed in 14w32b.
Confirmed in 14w32b.
Doing some more testing, i've noticed that the cause of the lag is different depending on the type of world you have.
If the world is a flatmap, the cause of the lag is probably the tick "mobSpawner".
However, if the world is not a flatmap the lag is caused by either "ai", or "tickBlocks".
This is spammed in the console while doing a debug profile on a standard world (not a flatmap).
If the world is a flatmap,
The mobSpawner does not cause lag on a normal map at all. Only on a flatmap.
If a flatmap eventually gets some mobs on the map (via spawn eggs for example), it dosn't take a lot for the sever to start lagging because of "entities.regular.tick.ai"
Lag caused by "doMobSpawning true" seems to only affect flatmaps. On regular maps the tick lag seems to be caused by something else.
See
MC-58120.Confirmed 14w32d.
Just had the internal server crash with this error in 14w33c while generating a customized "caves of chaos" world. Log attached.
Confirmed in 14w34b.
It should also be mentioned that Dinnerbone said a pre-release could be planned for this week. I would rather not see this bug in a pre release.
Confirmed in 14w34b.
Confirmed in 14w34b.
Confirmed FIXED in 1.8-pre1 on a freshly created superflat world!
Also there seems to be less tick lag on other worlds as well!
Confirmed in 1.8-pre1. Very gamebreaking in my opinion.
Be sure to check for this bug in the next pre release or snapshot, as Grum might make a change which could re-introduce this bug.
https://bugs.mojang.com/browse/MC-62166?focusedCommentId=193340&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-193340
@DarkCharizardXD
That sounds like your computer has been infected with a virus. You might want to do some virus scans!
On my computer the lag is there but it is not too noticeable. It is probably worse for some people.
As someone who has never seen the effects of
MC-62166personally on any of my computers or hardware, I would rather have this lag bug fixed instead of keeping an attempted fix ofMC-62166that doesn't even seem to fix it completely.@HummerSaurus
That sounds a lot like
MC-68080.@Galaxy_2Alex
Then tell us what the purpose is instead of leaving everyone in the dark. I'm sure some people would like to know.
Does it serve any purpose other than to confirm existence of an issue? If so, then why is it even here?
What exactly is the comment section supposed to be for?
Possibly fixed in recent snapshots.
Someone else who had this issue should also check for it in the snapshots.
Cannot confirm in 1.8-pre3.
However, remember that doMobSpawing used to only affect superflat worlds. If there is any lag, it is probably caused by AI or slow chunk loading, etc
Tried out 64-bit Java. It seems to at least limit the effects of this bug for me.
Anyone having this bug should try downloading the latest version of 64-bit Java (provided they have a 64-bit OS of course!) to see if it improves the issue for them.
EDIT: I used the latest version of Java 8, not Java 7 if that matters.
Confirmed in 1.8 on our server. Hunger drops very rapidly by about 4 bars at a time and then regens quickly.
EDIT: Rebooting the server fixes it.
It is probably related to the change that hunger now refills in peaceful mode.
Changing difficulty from peaceful to normal causes the hunger bar to act weirdly.
Here are my laptop specs, for reference:
Upgrading to Java 1.8.0_20-b26 64-bit has fixed the choppy lag issue.
Averaging around 50-60 fps with Fancy, Maximum smooth lighting, All Particles, Clouds OFF, VSYNC OFF, VBO's ON, Render distance 6, MipMaps OFF.
When first loading the world, framerates are low. Let the world load of a few seconds and then it's fine.
Make sure that all previous versions of Java are uninstalled before installing Java 8 64-bit.
Java 8 32-bit DOES NOT fix the issue for me, only 64-bit.
This bug has become more prominent in 1.8. Console gets spammed with this:
And occasionally this error will show up:
Based on the comment above, it could be related to
MC-37586which is when the server thinks a player hasn't left when they actually have, causing ghost players.Probably related to
MC-68080as well.Fair enough, but let's not forget the possibility that they might be related. Code does some weird things sometimes.
My laptop is what I would consider a low end laptop gaming wise and has no problems with that world with mobs jumping slower.
Could you post a link to a "famous YouTuber video" that shows the problem?
Everyone please keep in mind that this bug is currently titled "DoMobSpawning is causing reduced tick speed, causing general tick lag", and not "Mobs are 'jumping slower'".
Mobs jumping slower was a side effect of this bug, but that is not what this bug report is about. This bug report is about the gamerule DoMobSpawning.
As of 1.8-pre4, DoMobSpawning causes no noticeable tick lag and has been resolved.
From what I can tell by doing tests myself, mobs are knocked back slightly slower in 1.8 compared to 1.7. Whether that's intended or not, I don't know. It it also seemingly unrelated to tick lag as it happens even with a full 20.00 tickrate.
MC-69655 should be reopened or a new bug report should be created, either way this "slow mobs" issue is not related to DoMobSpawning.
If anyone here is on Windows and has this issue, be sure to try out the new Minecraft Launcher:
http://www.reddit.com/r/Minecraft/comments/2pkxpx/we_need_your_help_testing_the_new_minecraft/
It does not require Java to be installed on your computer.
It might give some performance improvements for some people, or it might not. But it doesn't hurt to try it
I've been doing some experimenting to recreate this bug, and the easiest way to recreate it is to simply dump a bucket of water in front of a pack of zombies that are trying to path to you.
It seems that liquids cause a huge problem with path-finding.
Video: https://www.youtube.com/watch?v=lYkDAhZpUQs
I'm currently not sure if anything else causes problems with path-finding, but liquids are for sure one of them.
I tried messing around with your posted region file.
I haven't been able to pinpoint the source of the lag for sure, but it isn't due to path finding.
It doesn't help that the offending tick in the debug profiler is "unspecified". (levels/map/tick/tickPending/ticking/unspecified)
On a fresh map created with the latest snapshot, this tick uses only 0.20%.
With your region file, that tick uses 68%!
I can kill all entities with /kill @e, and some of the lag goes away as well as the console spam. However, not all of the lag is gone and the problem is still with the unspecified tick, whatever that is used for...
I want to try and see if I can recreate this with a fresh map. Unfortunately, problems like this have been caused in the past by using older maps with newer versions of the game, which really sucks if that is the case here.
See, here's the thing that bugs me about this bug and this bugtracker in general. No matter how this bug is resolved, people are still going to say that "there's still lag... its not fixed" because of the awful title of this bug. It is too general.
That being said, doing my original test with a ton of mobs that try and path find through water has significantly improved. I could be really picky and say that its not fixed because there is still slight tick lag when I do the test, but the game no longer comes to a screeching halt when I do it.
Let's be honest, do we really expect path finding with a ton of mobs to cause absolutely zero lag whatsoever? While that would be great, i'm sure that any video game that is forced to do something like this (deal with A TON of entities and path finding calculations at the same time) would have some sort of a performance issue.
I still haven't seen this "bug" outside of a path finding situation on my own worlds, so I can't say that this bug really exists in 16w07a personally. I'm also not going to be picky and say that "omg theres still a litte bit lag with a ton of mobs pathing thrugh water. reopen pls!" If Mojang wants to optimize path finding more (and they should), then that's cool, but from the progress they made with this snapshot, I consider the path finding issue fixed.
1. Can we please all stop being wanna-be mods and let the mods do their jobs? If you want to tell people that this isn't a discussion forum, become a mod yourself.
2. Another possible cause of this bug is the tick root.save. Sometimes it appears to stall the server when doing a save-all command or simple auto-saving. I'll be looking into this more today when I launch my 1.9 server.
Happy to say that I've run my 1.9 server for a few hours now without any issues. It looks like root.save tick lag isn't because of this bug, so we can disregard that.
The Snocrash farm is the only way I have recreated this bug, where the lagging tick is "root.levels.world.tick.entities.regular"
"root.jobs" and "root" could also be a cause, as well as "root.levels.world.tick", and "root.levels.world.tick.chunkMap".
Confirmed 1.9.2
Confirmed 1.13
Still an issue in 1.13 full release. Crashlog attatched.
Taking damage will set the players current health to whatever is set by generic.max_health if it is lower than 20.
Respawning will cause the attribute to reset to 20, but the amount of health that is visible is whatever it was set to before the player had died. See MC-179940.
Confirmed
Affects version 20w18a.
Affects version 20w18a.
Affects 1.16 Prerelease 1