Patrick Dinklage
- pdinklag
- pdinklag
- Europe/Stockholm
- Yes
- No
MC-65884
WEB-2198
I can't play Minecraft.
Whenever I join my server, I see nothing but sky. Nothing happens. Eventually I get killed by a Zombie I never saw, respawn, and there I am again staring at the sky.
When I press F3, I see a "waiting for chunk" message. Nothing happened after 5 minutes, can't bother to wait even longer. I consider the game broken beyond playability right now.
I can't play Minecraft.
Whenever I join my server, I see nothing but sky. Nothing happens. Eventually I get killed by a Zombie I never saw, respawn, and there I am again staring at the sky.
When I press F3, I see a "waiting for chunk" message. Nothing happened after 5 minutes, can't bother to wait even longer. I consider the game broken beyond playability right now.
Server running 18w48a on 64-bit Debian 8, Java 1.8.0_112.
Client running on Windows 10, Java 1.8.0_131.
I can't play Minecraft.
Whenever I join my server, I see nothing but sky. Nothing happens. Eventually I get killed by a Zombie I never saw, respawn, and there I am again staring at the sky.
When I press F3, I see a "waiting for chunk" message. Nothing happened after 5 minutes, can't bother to wait even longer. I consider the game broken beyond playability right now.
EDIT:
Nothing suspicious in either the server log or the client log.
Unlike @Patrick Dinklage said, I can reproduce on 20w21a
I can only second xelotar here.
The reason I'm using this rule is to disable fire spread, which works perfectly fine. However, a thunderstorm still causes fires which won't go away unless extinguished manually, which can be very annoying.
The option "doFireTick" may work as intended, but as has been suggested, lightnings shouldn't be able to cause fires when the rule is active. I cannot see any drawback from that and the developmental effort should be minimal.
I have not played 1.6 a lot, but in 13w37b this seems to be AWFULLY common compared to 1.5. It doesn't seem to be network related at all, but happens as frequently in single player. It is practically impossible for me to see a whole landscape because there are holes everywhere until I go to the first block that doesn't display. Then it suddenly display that "chunk" and quickly loads the sorrounding ones.
My render distance is set to far, but that was fine for me in 1.5, where I rarely experienced this problem. My hardware has not changed since and I am still running Java 7, 64-bit.
I can confirm it.
I suffered from this since it was reported. It's finally gone in 14w31a, I can play Minecraft again!
I can confirm this for 1.8-pre2.
It also appears that Endermite stats are not counted at all as 1.8-pre2.
Ryan, that's another bug.
One snapshot caused chunks to break beyond repair, the result was void chunks like you described.
We had the same on our server. It was quickly fixed by another snapshot, but it was too late. We ended up generating a new world...
In any event, that's not a rendering issue or a client-side issue at all.
I can confirm this for Survival Multiplayer in 1.8.
We use a command block attached to a clock that does "clear @a tnt". If you happen to play around with the inventory while a clear is executed (even / especially if it doesn't actually clear anything because nobody has TNT), you get ghost items either on the cursor or on certain slots. This is true for any inventory - player inventory, chests, furnaces, workbenches, etc.
As soon as we disable the clock - and therefore the command block - the issue is no more.
EDIT:
A nice workaround for those wanting to disable TNT like us is a command block that kills primed TNT and TNT minecart entities:
kill @e[type=PrimedTnt]
kill @e[type=MinecartTNT]
"... How can a CSP bug be server-side..?"
SP is the same as multiplayer these days, just that the server (a listen server) and client are on the same machine, in the same JVM. That's why "publish to LAN" works.
I managed to hack myself to a "safe" (non-crashing) location and built a Hopper, everything is fine. So hoppers are not the issue per se.
Anyway, going close to the area Digit described causes the server to crash instantly with the same crash report as reported here. Apparently, something has been corrupted.
18w48b was released virtually while I was reporting this.
Server updated, restarted, issue remains, can't play.
To add even more info, this even happens in Singleplayer.
When I just create a new world with all settings left to default, once I'm in the game it's as described: waiting for chunks, not seeing anything.
"Significally slower" is a huge understatement for my case.
I downright can't play Minecraft, neither multiplayer nor singleplayer.
Whenever I enter "the world", I look at nothingness. I only ever see the sky, nothing happens no matter how long I wait (tbh, I didn't bother waiting more than 5 actual minutes).
I can open my inventory, but I never see anything of the world. Eventually, Zombies are going to eat me, and when I respawn I'm back staring at nothing. F3 is saying "waiting for chunk", but it's waiting forever.
This also occurs when I just go into singleplayer and create a new world with no settings changed whatsoever. So it has nothing to do with the world, but seems to be a strictly technical issue.
@CJ Burkey
Server has 2x Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz. That's hardly the limiting factor here, especially since this issue never occured before the 1.14 snapshots.
My notebook (client / singleplayer with) runs on an Intel Core i7-5500U @ 2.40 GHz, never experienced any performance problems with Minecraft.
@CJ Burkey
I got a feeling this is faulty networking code, maybe a deadlock where client and server are waiting for each other acknowledging something and it never happens, caused by a race condition possibly. Only a guess.
Cause it sporadically worked for me today - no problems whatsoever. Then I log on a few hours later and no chunks are loading again. Doesn't feel like a hardware related issue.
I do see kill stats for Withers (and yes, I do mean Withers as opposed to Wither skeletons) as of 18w48b.
But add Vexes to the list of mobs without kill statistic.
I don't get how this isn't automated in Minecraft's internals?
Aye, I can confirm the 18w48b server using a full CPU albeit no players being online. May have to do with this too.
I really don't get how this is marked as resolved? Just realized that.
Iron Golems, Snow Golems, Illusioners and Vexes still do not appear in the stats. This issue is not resolved as of 18w48b.
Whatever it was, it's fixed in 18w49a, monsters are spawning just fine again.
All the new features are worthless if they never even load up... fix your damn game breaking bugs first, Mojang!
@Thomas Hine I am running a snapshot server, both playing and testing new features at the same time. This is in Mojang's interest. Testing new features, however, isn't possible if not even the basics are working. So it's also in Mojang's very best interest to fix these game breaking things first before adding more and more new things. That just doesn't make any sense.
I can't confirm any render distance related magic here, just tried setting one higher than the server's view distance and nothing changes. The combination of 10 server / 15 client does neither. Usually, I'm about 10 chunks higher than the server it appears. Seems completely unrelated to me.
How can there be anything more important than this at this point for whoever is responsible for backend development? Is there even anybody responsible for it?
This bug has been reported over three months ago, received more than 100 votes and almost 100 comments in that short time, it has been confirmed (or at least acknowledged) by Dinnerbone and it renders every snapshot absolutely useless because the game is unplayable in multiplayer (and also in singleplayer due to
MC-118106, which I believe is related).Mojang, get your priorities right and communicate. Are Mojang devs even using this issue tracker to see what the hell is going on? Is there any way to get their attention here so they realize that this is a serious problem (e.g., for the mods)?
I can confirm that when casually playing, chunk loading now (pre-release 2 and 3) seems like before this issue was reported.
Sometimes it takes a while for one or the other chunk to appear, but it's a minor thing that may be related to connectivity or whatnot. Glad this has been allegedly fixed!
Just tried pre3 with 4 players and that was fine. Went into spectator and flew around.
As mentioned, sometimes it takes a bit (talking seconds) for chunks to appear, especially when many entities are clogging the area (farms), but that's really how it has been before this issue and may be a client-side issue of some sort. Anyway, the problem of chunks never appearing was not reproducible for me anymore today and yesterday.
OK, thanks for that hint!
The server was probably busy generating all loads of chunks because we were in a new world with 10 people roaming around. Not sure if it should take 60 seconds to tick though - increasing the tick time won't exactly "improve the experience"... however, there is nothing suspicious in the logs except for the occasional "server is behind" messages.
Anyway, the crash log should definitely mention exactly what you said, that would help.
1.14 was very fine for my server, CPU usage stayed below 60% even with 10 players on, with next to no lag except for funny chunk loading.
Now in 1.14.1 Pre-Release 1, chunk loading is fine, but the server is clogging the entire CPU again and we're experiencing pretty bad entity and block lag with the same number of players. I'll watch the server when it's idle again.
Confirming for 20w13a.
Confirming for 20w14a.
Despite what it says under "Affected Version(s)", it's already fixed in 20w21a.