Affects version 20w18a.
Affects version 20w18a.
Confirmed
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.
Still an issue in 1.13 full release. Crashlog attatched.
Confirmed 1.13
Confirmed 1.9.2
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".
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.
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.
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.
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.
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 🙂
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.
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?
Fair enough, but let's not forget the possibility that they might be related. Code does some weird things sometimes.
Based on the comment above, it could be related to MC-37586 which is when the server thinks a player hasn't left when they actually have, causing ghost players.
This bug has become more prominent in 1.8. Console gets spammed with this:
io.netty.channel.AbstractChannelHandlerContext invokeExceptionCaught
WARNING: An exception was thrown by a user handler's exceptionCaught() method while handling the following exception:
java.io.IOException: An existing connection was forcibly closed by the remote host
at sun.nio.ch.SocketDispatcher.writev0(Native Method)
at sun.nio.ch.SocketDispatcher.writev(Unknown Source)
at sun.nio.ch.IOUtil.write(Unknown Source)
at sun.nio.ch.SocketChannelImpl.write(Unknown Source)
at io.netty.channel.socket.nio.NioSocketChannel.doWrite(NioSocketChannel.java:267)
at io.netty.channel.AbstractChannel$AbstractUnsafe.flush0(AbstractChannel.java:694)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.forceFlush(AbstractNioChannel.java:321)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:515)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
at java.lang.Thread.run(Unknown Source)
And occasionally this error will show up:
io.netty.util.concurrent.DefaultPromise notifyListener0
WARNING: An exception was thrown by rk.operationComplete()
io.netty.util.concurrent.BlockingOperationException: DefaultChannelPromise@1421d396(uncancellable)
at io.netty.util.concurrent.DefaultPromise.checkDeadLock(DefaultPromise.java:397)
[14:13:36] [Server thread/INFO]: "Player" lost connection: TextComponent{text='Disconnected', siblings=[], style=Style{hasParent=false, color=null, bold=null, italic=null, underlined=null, obfuscated=null, clickEvent=null, hoverEvent=null, insertion=null}}
at io.netty.channel.DefaultChannelPromise.checkDeadLock(DefaultChannelPromise.java:157)
[14:13:36] [Server thread/INFO]: "Player" left the game
at io.netty.util.concurrent.DefaultPromise.awaitUninterruptibly(DefaultPromise.java:290)
at io.netty.channel.DefaultChannelPromise.awaitUninterruptibly(DefaultChannelPromise.java:135)
at io.netty.channel.DefaultChannelPromise.awaitUninterruptibly(DefaultChannelPromise.java:28)
at gr.a(SourceFile:199)
at rk.operationComplete(SourceFile:125)
at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:682)
at io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:607)
at io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:565)
at io.netty.util.concurrent.DefaultPromise.trySuccess(DefaultPromise.java:413)
at io.netty.channel.DefaultChannelPromise.trySuccess(DefaultChannelPromise.java:82)
at io.netty.channel.ChannelOutboundBuffer.safeSuccess(ChannelOutboundBuffer.java:608)
at io.netty.channel.ChannelOutboundBuffer.remove(ChannelOutboundBuffer.java:344)
at io.netty.channel.socket.nio.NioSocketChannel.doWrite(NioSocketChannel.java:302)
at io.netty.channel.AbstractChannel$AbstractUnsafe.flush0(AbstractChannel.java:694)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.forceFlush(AbstractNioChannel.java:321)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:515)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
at java.lang.Thread.run(Unknown Source)
Affects 1.16 Prerelease 1