mojira.dev

Christopher Martin

More than one avatar was detected! There might be multiple accounts sharing this same name.

Assigned

No issues.

Reported

MCPE-85385 Horse facing south after changing from 3rd person view Duplicate MC-151263 Ticking Entity Crashing Related to Zombies and Zombie Pigman Entities Duplicate MC-151252 Skeletons Attack Wolfs In Minecarts Cannot Reproduce MC-128872 Hard crash when placing pumpkin to test auto-farm, server will not restart Duplicate MC-69543 Falling sand top texture rotated compared to sand at rest Duplicate MC-62973 Spawn Protection not working on non-op users even with ops in ops.json Invalid MC-60308 You can place a torch on the surface of a water source block using a steep angle and a wall Duplicate MC-58767 Server Crash - Cannot set property ayl{name=facing, clazz=class dt, values=[north, south, west, east]} to down on block minecraft:wall_sign, it is not an allowed value Duplicate MC-51662 Sand/Gravel broken into entity by upward extending piston Fixed MC-51194 Changes to Minecart physics hopelessly breaks ALL existing cart based machines Invalid

Comments

I was having this issue on Linux (Manjaro) and fixed it by clearing my ~/.minecraft folder, though I backed up my saves, screenshots and shaders folders.

 

This is not a great look, however. People were already asking "So what's the upside to migrating my account?" and the answer is a resounding "none, but there might be a really bad downside...".

They seem to generate a corrupted path through the occupied block. If you push them into another space they recalculate their path and seem to get unstuck.

This impacts MCPE too: MCPE-58748

This issue has been marked as resolved, but how has it been resolved?

Here is the fix I suggested in the MCPE issue thread:

Bees should have two AI modes:

1) Have a "home" hive/nest set - in this mode they would navigate like Sea Turtles, always able to find their home hive or nest while the player is in range. In this mode Bees would work as they do currently while looking for flowers, but when weather, pollen or ToD force them to head home they should be much more able to find their way home (NBT tags with the XYZ coords of the "home" nest/hive would be used to make pathfinding more accurate, just like for the sea turtles). If a Bee arrives at their "home" nest and find it already fully occupied or missing it would immediately change to mode 2

2) No "home" set - in this mode the Bee begins a random wander to find a new home, and nothing can interrupt this search other than taking damage from a player or mob (resulting in combat behavior) or if a player has a flower (to allow homeless Bees to be led to a new home).

Should the current "fix" prove not to actually resolve anything might I suggest that setting a home in an NBT tag and then using those coords to improve pathfinding might be a better fix? I have to make assumptions because there are no details anywhere for how the issue has currently been "fixed".

Java Vanilla 1.15.2

I keep loosing bees. I breed them, have more than enough hives and have lowered fires, removed water etc. It seems like my loss is entirely due to random movement. This is frustrating, vastly reduces the fun of bees and instead makes it a constant battle to re-breed them every few MC weeks. It's also not even remotely bee-like as one of their defining characteristics in the real world is their navigational abilities. I could build enclosures, and that's fine for mid and end-game, but early on it's just a constant struggle you don't need to be dealing with that's not at all realistic. I don't mind non-realistic behavior if that adds to or improves gameplay, but that's not the case in this instance.

Bees should have two AI modes:

1) Have a "home" hive/nest set - in this way they would navigate like Sea Turtles, always able to find their home hive or nest while the player is in range. In this mode Bees would work as they do currently while looking for flowers, but when weather, pollen or ToD force them to head home they should be much more able to find their way home (NBT tags with the XYZ coords of the "home" nest/hive would be used to make pathfinding more accurate, just like for the sea turtles). If a Bee arrives at their "home" nest and find it already fully occupied or missing it would immediately change to mode 2

2) No "home" set -  in this mode the Bee begins a random wander to find a new home, and nothing can interrupt this search other than taking damage from a player or mob (resulting in combat behavior) or if a player has a flower (to allow homeless Bees to be led to a new home).

Bees are really close to being an excellent addition to MC, but currently they are totally useless long term without an enclosure, and that's neither realistic or fun.

I am having this issue still in 1.15.3; I just had this happen several minutes ago, so I logged out and came here. My world started in 1.14.? and was just recently updated to 1.15.3, where I obtained banner 11, which will not stack with the other 10 I already have. All of these are from patrol captains or raid captains.

I can confirm that this impacts users of KDE Plasma. This is a very popular desktop used on a lot of Linux distros.

I must agree with RedCMD above: it seems rather silly that the game doesn't detect the environment and apply the appropriate fix, rather than have this oscillating scenario of either KDE or MacOS not being supported by default. It is surprising that this cycle has persisted for so long without someone at Mojang recognising it and working to implement either a work-around or address the root cause.

There has been a lot of noise about gaming on Linux lately and more people are migrating so better support for Linux is in Mojang's best interest.

Happens REALLY often on my 1.15.1 Amplified server

@xavom

Unfortunately Mojang seem to think that everything's fine with the current state of the server; I certainly have not seen any acknowledgement from Mojang about the terrible state of affairs or any plan to investigate or resolve the issue. Mojang could be working on it, but if they are they aren't talking. I have seen community moderators asking for profile data, but there is no sign that the data is actually making it to anyone at Mojang. It's pretty much been radio silence. And, for the hosting community, this has had a massive impact, which makes the lack of communication even more hard to deal with.

Here's is Mojang's current solution to your problem: buy better hardware. For your needs (48 players SMP) all you need is a 1024 core 300Ghz Xeon CPU, 512TB of RAM and a 2TB/sec SSD. I am sure you can get one of those for cheap at your local PC store, right? It's not like their current published hardware recommendations are total garbage...

1.14 has been a disaster. It's generated a lot of renewed community interest, which has meant higher than usual server loads, which all would have been fine if 1.14 wasn't also a total dog in the performance stakes. For nearly a decade the hosting community was a huge part of Minecraft's success, but the double punch of Realms and Mojang's ongoing hostility to the hosting industry is making it very hard to provide servers for the community.

Hey there @spottedleaf

 

Thanks for having a go at solving the issue. I believe that Panda had a go at fixing this a while back:

https://bugs.mojang.com/browse/MC-4?focusedCommentId=325432&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-325432

 

Pretty sure his solution is pretty close to yours.

I just upgraded a 1.14.2 server to 1.14.3 with --forceUpgrade and --eraseCache and got:

[11:54:21] [pool-3-thread-1/WARN]: Unable to resolve BlockEntity for ItemStack: minecraft:air
[11:54:21] [pool-3-thread-1/WARN]: Unable to resolve BlockEntity for ItemStack: minecraft:air

 

So this appears current, at least up to 1.14.3.

This is current in 1.14.2.

 

I created a large scale flower farm in a Flower Forest biome expecting to get the full list:

  • Dandelion

  • Poppy

  • Allium

  • Azure Bluet

  • Tulips

  • Oxeye Daisy

  • Cornflower

  • Lily of the Valley

 

However after running the farm for over an hour I did not see any of the following:

  • Dandelion

  • Oxeye Daisy

  • Cornflower

  • Lily of the Valley

This is frustrating because I really wanted the Cornflowers. Dandelions are supposed to be common so I was surprised to not see any at all.

 

@unknown
 
Can you please stop repeating this? Even if you throw hardware at the server that does not resolve the UNDERLYING issue. You're just telling people to spend money upgrading to work around Mojang's error.

Yes, there is a floor to the CPU performance that can run a Minecraft server. This issue is about how quickly that floor has raised and whether or not that speed of that rise is legitimate or not. There has been an almost order of magnitude increase in per-user server load and it is unfair to ask people to lay out cash to work around a problem that Mojang SHOULD BE FIXING.
 
There are clear indications of MASSIVE inefficiencies in 1.14 and a significant lack of optimisation, both client side and server side. I suspect that this issue is because of a couple of big ticket items, like the insane increase in spawn chunk radius and 1.14's tendency to keep many many MANY more chunks loaded than previous versions and the INSANE increase in Villager processing cost, and a bunch of small ticket items are coming together to create the issues that people are experiencing.
 
Time and again people make it clear they are comparing 1.14 to 1.13 and you keep acting like they don't know what they are talking about and just should upgrade. Stop it. There is an obvious issue with 1.14, people keep providing mountains of evidence of the issue and you keep repeating the same non-advice. THERE IS NO AMOUNT OF HARDWARE YOU CAN THROW AT 1.14 TO MAKE IT RUN CORRECTLY: no matter what hardware you buy Minecraft will still not run efficiently. Yes, you can make it smooth, but the hardware required to do so (on a per-user basis) is 4 or 6 times 1.13. THAT IS INSANE. There is not enough extra content in 1.14 to justify that. There is an obvious issue. It is clear as day.
 
 

@kamil piglowski

I am not sure if this is the right forum for discussing Spigot as this is the official Mojang forum and Spigot is a 3rd party server that emulates most of the base mechanics, but differs in some specific ways that make it totally unsuitable to a segment of the playing community.

@nick killeen

I agree, 1.14 has obviously not been sufficiently tested on servers. 

There have been sweeping changes made behind the scenes without any community consultation. Built your massive farm just outside of the what would have been the spawn radius in 1.13 and before? Nope, spawn junks are much, much larger in 1.14 (and there has been no explanation for why). And there is a massive area around spawn that can lazy load and stay loaded for ever, even if everyone logs out. The only way to unload it is to reboot the server. Don't run a perma-loader for your spawn chunks? Doesn't matter, with the new spawn mechanics the spawn chunks will stay loaded, no matter what dimension your players are in. Hell, it'll probably stay loaded without any players logged into the server at all, even if that's the last freaking thing you wanted!

These changes could at least partially explain some (but by no means all) of the extra lag. It certainly explains why memory requirements for servers have grown by a factor of two or three.

I'm used to Minecraft Java being unloved and under-supported, but it's hard not to feel that this update was coded by inexperienced people, with little or no background in Minecraft (and certainly no server experience) and with no guidance or support from management or other people inside Mojang with more Minecraft Java history.

 

Not sure there is enough evidence to justify that feeling? Watch this video, it is VERY eye-opening. MethodZz has numerous videos on 1.14's insanity, but this one captures the essence of the issue very well.

https://youtu.be/kVlDtWRoWuA

I am starting to wonder if Mojang's plan to incentivise people to move to Bedrock is to just render the Java edition unplayable.

@@unknown
 
While this ticket (MC-118106) is indeed about performance issues, it is more about long standing structural issues. If you have experienced a massive change within 1.14 then it is more likely that you are experiencing both MC-138550 and MC-118106.
 
You really should look into MC-138550. It's an acute issue that has arisen during the 1.14 shapshots that has been partially resolved several times but it keeps returning with a vengeance. If MC-138550 does appear to be impacting you please show your support on that issue as we're not even sure if Mojang acknowledges it as a legitimate issue as we haven't seen any official communication as of yet.
 
I hope that helps.
 

@DFRBugger

You say "Please also note that disconnecting and reconnecting makes the spikes stop". Would you say that you were logged out for long enough (more than 15 seconds) for the chunks to unload?

 

Was this a new world? Were these new chunks? Could any of the lag/delay be attributed to world generation? You do say that you sat still for a long time. 

 

I am getting the feeling that 1.14 has high overheads, much higher than previous version (don't know if that's intended or not, or whether it's due to bad code or design changes... or both). I suspect in your case any many like yours you're being impacted by this bug and the situation you first encounter load spikes is from world generation. In past versions you might not even have noticed the world generation overhead if your PC was fast enough, but with 1.14 the cost of world generation and the increase overheads of 1.14 might now be exposing you to performance issues you could have had in the past had your PC not been such a beast... and a 8950 is pretty beastly 🙂, even if it is a mobile CPU.

It is very interesting that you have said that performance can return to normal if you exit and re-enter, causing the chunks to be saved out and then reloaded. When I was hunting more details of this issue on our SMP 1.14.2 pre-2 server I found that when it escalated to the point where a crash was inevitable I could avoid the crash by stopping the server, effectively causing the server to save out the chunks and then re-load them on next start.

 

Perhaps this is some sort of unintended consequence of the new multithreaded file I/O? I hope not... threading is going to be an important part of scaling Minecraft to take advantage of newer CPUs.

 

I hope Mojang make a post about this soon. The community really needs to hear from them regarding this so we can make informed decisions.

@jokubas

I don't think that synthetic tests are very useful in this instance as I don't think we should be ruling anything out. I have seen reports that overhead per villager is ten times that of 1.13, and that sounds like an unintended impact of the new villager code. As someone administrating a server impacted by this issue I can say that we'd like the villager impact assessed as part of this as we have a 40 villager iron farm in the spawn chunks (we haven't implemented a perma-loader yet because we're waiting to see what the final word from Mojang on this issue).

@Neil Hogg

You indicate that you tripled your RAM from 2GB to 6GB, for how many users? 4 to 8, by my guess?

If so, this is (historically) an insanely high amount of RAM for so few users. It might be the case that Minecraft's efficiency has tanked that far, but if that's the case then Mojang need to update their guidance on server configuration, because they are still claiming that 1GB is sufficient for a low user count server. If 4GB is no longer sufficient for hosting our server I want to know about it because it will cause me to seriously re-evaluate our hosting strategy and hosting hardware. If I am going to commit to a significant purchase of a faster CPU and a lot more RAM (and a motherboard to house them) then I need to hear it from Mojang.

I suspect that the issue is somewhat situational. Last night I was experiencing this issue on our server to the point it was causing the watchdog to shut down the server. I was able to work through the issue by moving through chunks until the one causing the problem to close the server was loaded, at which point I immediately logged out (I was the only person on the server at the time). By doing this several times I was able to 'unjam' the chunks. This is not to say that the issue isn't impacting us all the time, more that when it progresses to the point it abends the server I was able to get the server to work through the logjam of processing by using the chunk unload delay to get the chunk to be processed without the additional overhead of having a player actively logged in and interacting with the world. I also found that triggering a graceful server shutdown while the server was ticking behind would also resolve the issue in some cases.

 

I am inclined to believe that there is something very stupid in the 1.14 code. If we're lucky it's some badly written code that can be addressed to reduce the overhead, but I am increasingly worried that the issues are baked into the design of new mechanics. There were an astonishing amount of issues revealed during the prerelease process leading up to 1.14 and I was very surprised when the new release arrived when it did as the process felt truncated.

What we need more than anything else is some sort of communication from Mojang on the subject.

I can confirm this issue.

Causes extreme lag and server shut-downs. Very frustrating, lost hours to tracing issues.

I have attached debug traces and crash reports.

[media][media][media]



^

[media]

^

^^

[media]

^^

This issue (or something related) seems to be back with 1.14.1-pre1.

 

1.14.1-pre1 appears to try and expire llamas. I visited a chunk created in 1.14 with a villager trader and some trader llamas. The server immediately crashes with:

– Entity being ticked –
Details:
Entity Type: minecraft:villager (avl)
Entity ID: 14986
Entity Name: Villager
Entity's Exact location: 346.41, 64.00, 1347.98
Entity's Block location: World: (346,64,1347), Chunk: (at 10,4,3 in 21,84; contains blocks 336,0,1344 to 351,255,1359), Region: (0,2; contains chunks 0,64 to 31,95, blocks 0,0,1024 to 511,255,1535)
Entity's Momentum: 0.00, -0.08, 0.00
Entity's Passengers: []
Entity's Vehicle: ~ERROR~ NullPointerException: null
Stacktrace:
at bhi.a(SourceFile:676)
at vg.a(SourceFile:383)

 

I have attached a full copy of crash-2019-05-08_10.07.13-server

 

[media]