Christopher Martin
- outsidefactor
- outsidefactor
- Australia/Sydney
- Yes
- No
MC-51194
Pistons extending upwards break sand and gravel the same way a torch breaks falling sand and gravel.
I have included a world download with a machine to demo the behavior. The bug is most distinct with the central repeaters on the second setting, but the first setting will result in the block breaking eventually.
Please note, this may be related to bug
MC-46225, but this isnewbehavior. In snapshots up until 14w10c the piston disappears, but from 14w11b the piston no longer disappears, but now the block breaks as described above.Pistons extending upwards break sand and gravel the same way a torch breaks falling sand and gravel.
I have included a world download with a machine to demo the behavior. The bug is most distinct with the central repeaters on the second setting, but the first setting will result in the block breaking eventually. To start the machine, load sand or ravel on the pistons and press the stone button.
Please note, this may be (or may not be) related to bug
MC-46225, but this is different behavior. In snapshots up until 14w10c the piston disappears, but from 14w11b the piston no longer disappears, but now the block breaks as described above.
Pistons extending upwards break sand and gravel the same way a torch breaks falling sand and gravel.
I have included a world download with a machine to demo the behavior. The bug is most distinct with the central repeaters on the second setting, but the first setting will result in the block breaking eventually. To start the machine, load sand or gravel on the pistons and press the stone button.
Please note, this may be (or may not be) related to bug
MC-46225, but this is different behavior. In snapshots up until 14w10c the piston disappears, but from 14w11b the piston no longer disappears, but now the block breaks as described above.
Pistons extending upwards break sand and gravel the same way a torch breaks falling sand and gravel.
I have included a world download with a machine to demo the behavior. The bug is most distinct with the central repeaters on the second setting, but the first setting will result in the block breaking eventually. To start the machine, load sand or gravel on the pistons and press the stone button.
Please note, this may be (or may not be) related to bug
MC-46225, but this is different behavior. In snapshots up until 14w10c the piston disappears, but from 14w11b the piston no longer disappears, but now the block breaks as described above.Further info - if you replace the pistons with sticky pistons in the test world attached, the problem with not manifest until you change the repeaters to the first setting. On that setting the behavior of sticky and non-sticky pistons is identical.
Pistons extending upwards break sand and gravel the same way a torch breaks falling sand and gravel.
I have included a world download with a machine to demo the behavior. The bug is most distinct with the central repeaters on the second setting, but the first setting will result in the block breaking eventually. To start the machine, load sand or gravel on the pistons and press the stone button.
Please note, this may be (or may not be) related to bug
MC-46225, but this is different behavior. In snapshots up until 14w10c the piston disappears, but from 14w11b the piston no longer disappears, but now the block breaks as described above.Further info - if you replace the pistons with sticky pistons in the test world attached, the problem wi
thnot manifest until you change the repeaters to the first setting. On that setting the behavior of sticky and non-sticky pistons is identical.Pistons extending upwards break sand and gravel the same way a torch breaks falling sand and gravel.
I have included a world download with a machine to demo the behaviour. The bug is most distinct with the central repeaters on the second setting, but the first setting will result in the block breaking eventually. To start the machine, load sand or gravel on the pistons and press the stone button.
Please note, this may be (or may not be) related to bug
MC-46225, but this is different behaviour. In snapshots up until 14w10c the piston disappears, but from 14w11b the piston no longer disappears, but now the block breaks as described above.Further info - if you replace the pistons with sticky pistons in the test world attached, the problem will not manifest until you change the repeaters to the first setting. On that setting the behaviour of sticky and non-sticky pistons is identical.
Java 1.7.0_51-b13 on Windows 8.1 x64
Java 1.7.0_55 on Windows 8.1 x64
Java 1.8.0_11 B12 on Windows 8.1 x64
Hard crash when placing pumpkin to test auto-farm, server will not restart
@Christopher Martin: Don't make assumption about things behind the scenes.
Your Java version is quite old. 1.8.0_65-b17 is the version I am running. Maybe it's worth an upgrade.
No, it's not outdated, that's the known-working version of the java-bundled Minecraft Launcher.
This is no security hole or something like this, because the bundled Java version is only used for Minecraft, nothing else.
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
Christopher Martin, please retest this. [Mojang] Grum (Erik Broes) has done a considerable amount of work on pistons within the past few snapshots, and I am no longer able to get the falling blocks to break in any of my tests. I'm hoping this is fixed, but would like confirmation from others who have successfully replicated it in the past.
The resolution for MC-141484 may be what your issue is.
Further info: the impacts to existing long distance rails links are extreme, as well. How are server admins expected to fix hundreds or thousands of blocks of rail links on their servers? This change is akin to changing the max signal from redstone torches from 15 to 31: it changes everything and breaks almost anything that works today. It's a change to an underpinning principle that it doesn't seem there was much community call for, and a change that could have been handled with a new block, an 'accelerator rail', for example.
I can confirm it's still an extant problem. I fixed our server's witch farms about 4 times until I realised what was happening. Confirmed in 14w10c.
Mojang may have tried to fix it in 14w11a or 14w11b: the piston no longer disappears in 14w11b. However, the sand/gravel now breaks into entities in the same way falling sand/gravel is broken by a torch. I have reported this new behavior as bug
MC-51662.I'm not sure this is the same issue.
MC-6438refers to pushing blocks into a stack. The problem shown above occurs with a single block placed on a piston, and happens quite predictably on a slow cycle, not spamming. I will look intoMC-6438and try and see if it does encompass this.Hello all. I reported another, similar, fault and was directed to this issue by Galaxy_2Alex. My other issue was
MC-51662, if you're interested. I raised it as I thought my issue was discreet from this one as my demo machine doesn't stack blocks (and is significantly simpler), but it does break sand/gravel in a similar fashion. Can the original poster please attach a world download so we can confirm if this bug is still present in 14w11b? I would also like help confirming whether or not my issue is actually the same as this one.Edit: I have looked at the demo video and rebuilt the machine and I think this is a case of mistaken identity. This machine, like my demo machine in my report seems to be demonstrating a new bug. What it looks like is that falling sand gravel falling onto a piston head block in the process of extending or retracting is being treated like falling onto redstone/torches/etc and breaking the block. I can confirm I have tested the behavior in both 1.7.5 and 14w11b and the fault occurs in both. I will attach 1.7.5 and 14w11b worlds to this issue, I guess, as my issue has been closed.
Further Edit: I recreated my demo machine in 1.7.5 and that clearly shows that, while the issues are similar, the issue
MC-6438is current in both 1.7.5 and 14w11b, and my issue (MC-51662) is not present in 1.7.5 but is present in 14w11b. I would suggest this means they are similar but different issues. I am attaching demo worlds now.Confirmed 1.7.8
This problem has been around for nearly 4 months. It's causing havok to many users (even Docm77 mentioned it in a recent youtube video) and this bug is still unassigned... But they had time to futz with the Minecart physics.
Come on Mojang, let's fix some bugs! I have a dozen bugs I am watching that cause major issues for me as a server admin on a daily basis, but instead all Mojang seem to be talking about and focusing on is the name change functionality and plugging all the bugs it's introducing. Oh yeah, and Realms.
OP (Guillem Saldo Rubio), can you please update the affected versions list? This is still around in 14w17a.
This was originally posted in January... and it's still unassigned. Are we to assume then that this will never be addressed?
I crash on log-in. I am in an area with many item frames. I downgraded to 14w17a and all was well again.
Very frustrating! In 14w17a and 14w18a.
Nathan,
The OP seems to have given up, and is thus not updating the the affected version field, but if you raise a new ticket with the latest version a Mod just comes along and says "Duplicate!" and closes it, but then fails to update the affected version list with the new versions.
And it's still extant, today, in 14w18a, the ticket is four months old and it STILL is unassigned, but as this is only really affecting redstoner's there's been little movement. Even some of the youtuber's, like Docm77, are starting to grumble about this in their videos.
This is still a problem in 14w17a and 14w18a. As usual, the OP has LONG since stopped watching this, Mods keep sending duplicates here, but then do not update the affected version list.
There are DOZENS of serious issues going unresolved because original posters don't have the stamina to keep editing the affected versions, those of us who are tracking them can't and the mods won't. These issues are well described, easy to replicate and would take 5 minutes for a mod to confirm in the latest snapshot and update the affected version field. Instead they languish, unassigned and unresolved.
Make sure your Java is up to date, too. You're not too far behind, but better safe than sorry.
Yep, duplicate of
MC-51168Still present in 14w17a.
This is still current in 14w18a, as far as I can see. I am loving the activator rail dismount, but consistent behavior would be very welcome.
Guillem, will do. I had asked for the update on the 25th and I was getting worried it had been abandoned like so many other issues. I didn't mean to be rude, I am just getting frustrated at Mojang's peculiar inattention to several issues. This issue is over four months old and Mojang is yet to assign it to someone for resolution. Even a single comment: "This is acknowledged, look for a resolution around 14w25a" is more useful than the deafening silence we're currently getting.
When issues like
MC-6438andMC-119keep rising up like the living dead, over and over again, there needs to be a mechanism for users, other than the original poster, to modify the affected version field. I have made numerous comments on both of those issues for the OP to update them, but to no avail, and lumped this one in with them.37 votes, 40 odd duplicate issues and it's still marked unconfirmed and unassigned...
This bug used to happen while in proximity of pistons up until 14w08a, or there about. After that, is takes an unload/reload to exhibit the behaviour.
The peculiar behaviour of the block breaking, being unpredictable at 1, 3 and 4 ticks, but completely predictable at 2 does suggest the it is related to falling timing. Either this bug is related to
MC-6438, orMC-46225ANDMC-6438were resolved pre-1.7, as the bug history would suggest, and this behaviour is a new bug andMC-6438andMC-46225were re-opened by mistake.These are impacting a wide range of users. I have heard Youtuber's refer to it. The Mindcrack server was updated to snapshots circa 14w08a, and since then DOCM77 has occasionally mentioned he's constantly repairing his Witch Farm, which is how I discovered it: I would come back to the witch farm and it would be covered in witches and the shifting floor would only be partly working. With a bit of investigation, either the sand would be missing, or the piston. And, after repairing and leaving and coming back, some of the same pistons would be gone, but not all, and some new ones. There didn't seem to be a predictable pattern.
Please help! This is a show-stopper for ANY machine using pulse shorten-ers, and it's not like those are uncommon.
EDIT - It's definitely a moving target. I checked back over my notes and bug history, and found that I initially only saw the piston breaking mechanic and started watching
MC-46225. Later I found that the issue seemed to have evolved (between 14w10c and 14w11b) and reported it asMC-51662and was from there referred toMC-6438.It's all very confusing, and as months have passed since I started watching these issues I am having trouble keeping the order of events straight.
Flip, et al.
The sand bridge is not the ONLY implementation where this is broken. In the case of Pulse Shorten-ers we can't change the activation rate to prevent the sand block breaking.
The problem here is that I think this is a new bug that the Mods are claiming are two old bugs. I refer to my most recent post on
MC-46225:"The peculiar behaviour of the block breaking, being unpredictable at 1, 3 and 4 ticks, but completely predictable at 2 does suggest the it is related to falling timing. Either this bug is related to
MC-6438, orMC-46225ANDMC-6438were resolved pre-1.7, as the bug history would suggest, and this behaviour is a new bug andMC-6438andMC-46225we re-opened by mistake.These are impacting a wide range of users. I have heard Youtuber's refer to it. The Mindcrack server was updated to snapshots circa 14w08a, and since then DOCM77 has occasionally mentioned he's constantly repairing his Witch Farm, which is how I discovered it: I would come back to the witch farm and it would be covered in witches and the shifting floor would only be partly working. With a bit of investigation, either the sand would be missing, or the piston. And, after repairing and leaving and coming back, some of the same pistons would be gone, but not all, and some new ones. There didn't seem to be a predictable pattern.
Please help! This is a show-stopper for ANY machine using pulse shorten-ers, and it's not like those are uncommon."
Either the two bugs have merged into one bug, or
MC-6438andMC-46225were resolved as stated and there is a new, discreet, bug. The machine inMC-46225would seem to demonstrate this, in that one action produces both the results, and the distinction between the two results is on unload and reload of the containing chunk. The timing peculiarity demonstrated by that machine (two ticks making the sand breaking VERY predictable) would also seem to indicate that. Then again, I am not a coder, but it does indicate that it needs investigation by someone who IS.EDIT - It's definitely a moving target. I checked back over my notes and bug history, and found that I initially only saw the piston breaking mechanic and started watching
MC-46225. Later I found that the issue seemed to have evolved (between 14w10c and 14w11b) and reported it asMC-51662and was from there referred toMC-6438.It's all very confusing, and as months have passed since I started watching these issues I am having trouble keeping the order of events straight.
Yep, my 14w18a server and 14w19a test world exhibit this behaviour.
lol, 649 votes...
Flip,
I am not meaning to hijack you bug, but I was sent here when a mod marked my bug report (NOT about sand stacking specifically but about sand breaking generally:
MC-51662) as a duplicate of this one. At that point I was forced to start commenting here to have any hope of having the major bug I am experiencing fixed. It's a frustrating situation. I felt then, as now, that my bug may (I emphasise MAY) be a related but distinct issue, as yours relates to pushing sand under falling sand, where as my bug was just about pushing sand up on a piston. Either way, I'd like to see it fixed.If you refer to a standard witch farm design, as shown in http://www.youtube.com/watch?v=RGynJ0yOhmA, this bug will result in 14w04c to 14w19a. You can see in
MC-46225that this bug has evolved and is spilling over into many applications, as the machine designed to expose the piston vanishing bug will also reveal the sand breaking issue.And, sand is STILL breaking in 14w19a and we can't get a fix (could you please update the affected versions field please?). It's been months,
MC-46225is also still un-addressed and it seems that (in absence of evidence to the contrary) it no-one at Mojang even has it on their radar. ANY redstone machine that uses piston/sand combos as a pulse shortener experiences this if it's receiving rapid pulses. There is no replacement for the sand/piston shortener because it relies on the sand falling mechanic to prevent single tick pulses from resulting in a pushed out block. Combined with a tripwire hook and you have an unjammable device (see the above video for the explanation of the tripwire hook/ falling sand unjam mechanic). There is no workaround because the intrinsic mechanism is what's broken.I have made a revised world to make it easier to test on unload/load of chunk (attached as PistonVanishTest.7z). The previous world had the test apparatus near spawn, making the behaviour harder to induce due to the delay that spawn chunks take to unload.
There are command blocks to make teleporting back and forth easier. You may need to reload the machine with sand a few times and teleport back and forth a few times, as it seems the sand needs to be at a specific point for it to continue to fall into the piston base. The sand breaking mechanic is much easier to induce. These two facts also seem to indicate a strong link between this bug and the venerable
MC-6438.I have used this machine to re-confirm the bug with 14w19a. Guillem Saldo Rubio, can we get an update to the affected versions, please? It impacts 14w18b as well.
Torabi,
I am glad that it helped, and am happy to put my time into helping make Minecraft better. Please note: your discovery of the sand block breaking from your earlier comment also warrants you marking
MC-6438as confirmed as well, as the one machine confirms both bugs: if you stay close the sand breaks likeMC-6438, if you teleport it destroys the piston likeMC-46225. If they are linked it's important the same developer is aware of both bugs so they are addressed together, or at least to ensure the fix forMC-46225does not exacerbateMC-6438, or vice versa.Your earlier points as to the size and structure of Mojang are well taken. The written word is not a perfect medium and I can be, well, lets say 'terse' and leave it at that. I guess I have two main suggestions and, after saying them, will say no more unless asked for my continued opinion.
Regression Testing - Perhaps Mojang could maintain a typical test world that has one of every redstone and (non-mob) physics mechanic, induced by an appropriate timer and monitored via command block. Prior to a snapshot being released the test world would run for an appropriate period of time before releasing the snapshot. If nothing breaks for 4 hours (as an example), great, release the snapshot. You would, obviously, add new mechanisms each time you add a new mechanic (a great way for end users to see new mechanics in action as an added bonus). This world could be made available for user testing and verification. Heck, the community could even be drafted to help maintain it, though that would effectively mean including the community more in the actual release engineering process. I certainly would pitch in, as was demonstrated by my willingness to build test machines for this and other bugs, and people like the Mindcracker and ZipKrowd would have a stake in helping, too. It would also provide users a way to verify that their local copy of Minecraft is working as expected. If most people can run version x of the regression testing world flawlessly with version x Minecraft, but it doesn't work for a particular user it provides them an avenue of investigation as to why it's working differently than expected.
Prioritisation - I work in IT support, and in a past roll worked in a front line support team. When our numbers of tickets started spiralling out of control we imposed a change embargo on new features until the numbers of new tickets were reigned in. Once it'd settled down we started making changes again. Surgeons stop a patients heart when they're operating on it because working on a moving target is a dangerous proposition. I understand that game development is different in many ways to corporate IT support (and heart surgery), but maybe there are some tools or methods that are transportable that would help manage community ire more effectively.
No-one will be happier than I to see the mod API complete. The lag between new Minecraft release and mods being updated, and the consequent workload for modders, is a huge issue, and I would happily forgo new features for a while to get some some bugs bedded down and the API focussed on after that. The new piston/slime block interaction could have stood to wait, as could have the foray into new minecart physics, as examples, until things were bedded down more, and fighting on many fronts hurts efficiency, so maybe doing less would actually achieve more.
It's just my opinion, so feel free to ignore, but if there is anything of value there please pass it on. If you would like to discuss it further, in another forum, please let me know.
It's worth uploading a world save with a test machine to allow mods to more quickly evaluate bugs (the easier their job is the more likely your bug is to get addressed). If they try and recreate the machine and get it wrong and say they can't confirm the bug you're stuck chasing them. Your screenshot is pretty dark and mods may have difficulty interpreting what they are seeing.
Make sure the behaviour you're trying to demonstrate is documented in the world with signs.
I hope that helps and that you bug gets resolved soon!
I would recommend inducing the behaviour and doing a video capture. You can then post it on youtube and link it here. It will make it easier for mods to confirm the issue, or explain the behaviour if it's working as intended. The easier the mods' job is the more likely you are to get your bug investigated and resolved.
I just tried it out and sure enough, damage. Unfortunately, due to the (extremely) scanty details that come with new Minecraft feature releases we can't be sure if this intended behaviour or a bug.
I assume it's a bug, as it significantly reduces the usefulness of slime blocks if it is the intended behaviour. To make it easier for Mods to reproduce the bug I have attached a small world with the demo machine reproduced.
Jonathan,
Just wanted to let you know some things I have found out from comments Mods had left on other bugs. Firstly (rightly or wrongly) Mojang don't follow corporate style IT support systems. I know, a decent dose of ITIL might work wonders for them, but it's not happening today. Where you would normally expect a ticket to be picked up by someone as soon as it was verified, Mojang tend to lurk until they are ready to actually fix it, at which point it's assigned and fixed. It's a small team, so ambiguity of ownership of issues may not hurt them that much in terms of efficiency, however...
This is not support ticket best practice.
This gives the false impression that the bug is effectively dormant and not being taken into account by Mojang.
This generates community ire because it fails to manage user expectations in any useful way.
Mojang's community engagement level is very weird. They are hugely active on Twitter and Reddit (neither of which are mediums I have time to engage with, having a real job and more than enough on-line communities in my life already), but their own, internal, communication channels languish with a dearth of information and very brief announcements regarding to feature changes and bug handling.
This bug has 387 votes (at the time of writing) and should get addressed, so I wouldn't panic. If it's taking a long time to get assigned it's likely that Mojang just aren't sure how to fix it yet, or have other priorities right now (Realms is likely to be their focus for some time as there appears to be a lot of money at stake, right or wrong as that may be). I would assume that as a 1.8 release approaches they will stop making new feature changes and actually start to address some bugs. Of course, as we have NO actual data regarding the internal release engineering process within Mojang, nor a detailed release roadmap, this is all complete speculation, but a guy can dream.
Charlene,
There are reference drivers that may work on the AMD site: 13.1 claims to support the HD 4xxx series and support Windows 8.1 64. However, your biggest enemy is Toshiba themselves. Frequently OEMS make subtle alterations to the hardware design to meet their needs, but then fail to make updated drivers available when AMD or NVidia update the reference driver code. I work in support and have decided to no longer deploy Toshiba because they don't take their software updating support seriously enough: I expect a computer to be fully supported as a MINIMUM for it's useful three year life, but Toshiba seem to loose interest at the twelve month mark.
Check out the support page for your laptop and see if there is a recent driver there. Hopefully 13.1 will be there, and should work for you, but remember to backup your data before tinkering with anything.
fienxjox,
I am aware that the Mods are volunteers, and I am not making comment about them. Mods are likely doing the best they can with little or no guidance, given the lack of appropriate community engagement Mojang displays in other areas.
Your comment makes my point very well. Jonathan assumed that an unassigned ticket was dormant: this is a safe assumption as that is what it means in a normal support ticket environment. Is there a FAQ that answers questions about Mojang's support process that outlines this difference? No, another user has to pass on the information that they themselves learned through side-channels. And instead of you recognising that the system had failed, you instead came to the defence of the mods, when I hadn't actually said anything about the mods other than what I had seen them post on other tickets.
I don't watch twitter, as I said in my post. As this is the official channel (the Mojang website and bug tracker) by which Mojang (the corporate entity I purchased my game from) expects me to manage my bugs and interactions with them I don't see why they shouldn't do the same, or at least give equal time and effort to.
Yes I am aware that Mojang is making major changes. My comment was how I acquired this information: rumour, community discussion and short, detail-poor release comments from Mojang. There are plenty of community, open source software projects run far more professionally than this. Check out FreeBSD's release engineering process, and it's not $35 a copy, it's free. It's not a dinky little Java game, it's a full operating system. I don't expect it to be that good, but half that good? That'd be nice. A quarter as good? It's a start.
I am not saying I don't want issues fixed. In fact, that's what I want: Mojang to focus bedding down the internal re-engineering and keep its focus there. There have been many, many new features in the 14w snapshots. How about letting it be for a while so we can actually get the new API out so the community has a stable base to work from? I think the majority of users would prefer 1.8 sooner with just the re-factoring and API done than it later with slime blocks and new minecart physics.
@Djfe,
I guess we'll just have to wait and see. I despair for the bugs from January this year, but Mods have made some comments on other tickets that suggest that there is significant re-engineering going on and that bugs may go un-addressed while the underlying systems are overhauled. I can understand that, I just wish there was better communication of that here and in the release notes for the snapshots. It would prevent people from getting (quite legitimately) upset at the apparent (due to the lack of in-band communications) inaction.
Original poster or Mod, can we can an update to the affected versions, please? Both 1.7.9 and 14w19a, if you please.
Jonathan,
I hear your pain. And, yes, I understand that poor support is not unique. Updating with new information is not 'trolling' and I find myself in a similar position on other issues.
I guess we'll wait and see how things evolve, and keep posting new data when we can.
Check to see if you think this may be related to
MC-129. If you think it is, make a comment there, vote and watch the issue so it gets the attention it deserves.if you think this is a discrete, new bug (rather than the continual re-emergence of an old issue) stick it out here.
To get action on tickets you need to do two things:
1) Attach a compressed world with a sample machine that demonstrates the issue. This makes it easy for mods to confirm the bug and the easier their job is the more likely they are to do it.
2) Make sure you keep confirming the bug in new snapshots. Mods tend to focus on bugs marked as impacting the current snapshot.
Mojang rely on Mods to help manage the flood of issues. Mods are volunteers who do their work when they can.
I tried this on 14w20b and didn't have an issue. As you haven't shown what type of item elevator you're talking about that means we don't actually know if your particular bug is resolved or not.
Please re-test your design and update the affected versions field if necessary. I didn't upload my working version for fear of confusing the issue when it is reviewed by a mod.
Flip or a mod, can you please add 14w20a and 14w20b to the affected versions list?
Can Guillem Saldo Rubio or a mod add 14w20a and 14w20b to the affected version list please?
Can we get an update to the affected version please? It impacts 14w20a and 14w20b.
Can we get an update to the affected versions? As far as I can tell this is still an issue in 14w18b (that's the snapshot my server is running), but can someone confirm it's still in 14w20b?
Can you firm this is still an issue in 14w20b and, if so, please update the affected version, or close the issue if not.
I can confirm this in 14w20b, 14w18b and 1.7.9. Is this a case of a bug re-emerging, or has it been consistently broken for all this time?
I have to admit it's fairly esoteric, as a redstone torch is much resource cheaper than a detector rail, but there are times I have wanted to use this due to space issues. It also means that up-slope activator rail mob unloaders don't work, and I have a use for that too (a one way mob unloader, for example).
As frustrating as this is, it must be a damn pickle to have gone over two years without resolution. Is it related to the minecart hitbox size?
I can see what happens and confirm it. What would be your preferred behaviour? The problem exists because the item frame is a transparent block and chest lids open into those. If you put a chest under a glass block the lid clips through as it opens, very similarly to this, as pointed out by Kumasasa. Would you prefer the item frame to get partially masked out of existence while the chest is open? Would you expect the same changes to be extended to chest-lid interaction with other transparent blocks? Should an open lid preclude third party (another player) interaction with the item frame, or for that matter any transparent block with a hitbox?
The clearer you are about your expectations the better the mods are able to manage them and Mojang to respond to them.
I am having the same issue in client/server, but instead of [SEVERE] it says:
[Client thread/ERROR]: Item entity # has no item?!
The server in question was running 14w18b. While I would like to move to 20b, but it actually causes more issues than it solves.
Flip or a mod, can you please add 14w21b to the affected versions list?
If you're able to run recent nVidia software (assuming that's the type of GPU your laptop has) it has built in recording, if I remember correctly. Otherwise the trial version of Fraps should do the trick and it's easy enough to use. There are plenty of help videos on Fraps on Youtube. You don't need a high res capture, and it only needs to be just long enough to demonstrate the behaviour. Upload it to youtube and post the link here.
OP has failed to update ticket in months, the affected version is now out of date and there has been no community confirmation. This looks like it can be closed.
Can you check and see if you think this is related to
MC-129? Throw your support in there if you think it is, keep posting here if you think it's a discreet issue. You may want to update the affected version field if it's still an issue in 14w21a.And 14w21b. Can we get an update to the affected version field please OP or Mod?
If there is a bug in the login code that can cause a loop or a bunch of half opened sessions then it IS a MC issue. OP, can you confirm if it's current with 14w21b? You may want to make further posts explaining the discovered issue if further detail.
Blah and Marquis Owens,
Yes, only a mod can do this. No, don't expect any action any time soon. There are so many bugs in the 14w snapshot branch now I am starting to think Mojang don't know where to start in debugging. They are going through a core code re-design (refactoring some mods have called it) and it's actually introducing bugs. At the same time they are insisting on adding new features, further complicating the already monumental job. Is that smart? I'll let you decide, but they don't seem very interested in making their process more professional, no matter how willing they are to take money for products and services.
OP, can we get 14w21b added to the affected version field please?
kbk, yeah the directionality of it suggests it's bug-like, if not an outright code bug. It's likely going to be very hard to fix, which would suggest it's going to languish, unresolved, for some time yet.
OP, can we get an update of the affected versions field please? 14w21b.
And in 14w21b.
And now it's June... No recent snapshot, no comments from mods, no programmer feedback, nothing. Reported in January and still unresolved 6 months later.
And to 14w21b, please. It's been nearly six months.
Fixed or rolled back? If rolled back, can we expect the code to be re-introduced again in the future?
Can we get snapshot 14w21b added to the affected versions list?
OP (Chris) can you upload a zipped version of your world? Coders and mods are busy people and are more likely to implement a fix when you do as much of the work as possible, as demonstrated by
MC-56541, which was reported and resolved within a week. Well, it could also be because of the cliquey, in-crowd nature of the Mojang inner circle (it seems the same crap the jocks were doing in high school is now the province of the nerds), but that could just be my suspicious nature talking.Flip or Mod, can we get an update to the affected versions list? 14w25a and 14w25b.
Torabi, am I to assume from what you are implying that piston mechanics won't be reviewed before the 1.8 release? 1.8 will ship with this bug live? That would be interesting news.
OP or mod, 14w25b to the affected versions list, please.
OP or mod, 14w25b to the affected versions list, please.
Torabi,
This is where this gets frustrating. The behaviour I am discussing is new to the 14w branch. The machines I discuss work in 1.6 and 1.7 (being witch farms based on shifting floor design) and are only breaking recently. This contradicts your statement about there being no changes to piston mechanics.
I will re-iterate from the beginning:
I did not report
MC-6438. I was directed here after my issue (MC-51662) was marked as being a duplicate of this one. My bug was NOT about pushing sand under sand (an esoteric, rarely used redstone mechanic), but merely the destruction of sand by upward extending piston heads.MC-6438has a very generic sounding title, but when you read the bug description it is a very narrow application, and has many more moving parts than what I discuss inMC-51662.This entire discussion proves my initial point about
MC-51662being a distinct bug.MC-6438has existed for a very long time, but the behaviour reported inMC-51662only just showed up in the 14w branch.I would suggest that many people, the ZipKrowd none-the-least, will be interested to hear that their witch farms, which work fine in 1.7, will cease to work as of 1.8, especially if
MC-46225also remains un-addressed.Lastly, as to your comment about this being a 'low cost' bug, I disagree. All of the components of pistons are farmable, and are therefore renewable. Sand is not. New lands must be explored to find sand. From a certain point of view, sand and gravel are are more valuable than pistons.
Torabi,
Thank you for making the changes. For reference's sake I will answer this in
MC-51662and quote your question there.Anyone who is impacted by
MC-51662should head over there and vote to make sure it gets resolved.In response to Torabi and continuing from the old
MC-6438conversation:"You say the behavior in
MC-51662is new, but how does it differ fromMC-26356(aside from yours being better written)?", TorabiAll tick variations now seem to break blocks (not just 2 as in
MC-26356). Shorter ticks seem to result in more pulses, resulting in a higher chance of the block breaking, but all tick lengths, when spammed, break blocks."What did the sand do before?", Torabi
It didn't break. In the latest 1.7 version witch farms work all day without issue.
"You say there that "In snapshots up until 14w10c the piston disappears", so when did it actually work?", Torabi
It worked in every release of 1.7 before the 14w branch, and in all versions of 1.7 after the fork. From 14w04a
MC-46225started breaking the machines. Then, from 14w11b machines were breaking because of bothMC-46225andMC-51662.Unfortunately, this issue is now four months old for me, so my imperfect memory is now a complication. The description should likely read:
"In snapshots up until 14w10c the piston disappears (as in
MC-46225), but from 14w11b the piston now can display either behaviour, either disappearing as inMC-46225or breaking sand as described above."If that makes sense to you I will update the description.
Also, the behaviour has evolved over the snapshots. In 14w11b the blocks break aggressively while you are present, now it takes a two tick pulse to do it in front of you, but a chunk unload, by teleporting away or portal travel, triggers it (or
MC-46225) fairly predictably (as long as you are aware of the spawn chunks and take their impact into account) no matter the pulse length.Really, the best bet at this stage is to download the machine from
MC-46225(it has many improvements so I'll post it here too and remove the old one) and load it into 14w11b and step forward from there, as the behaviour seemed to subtly evolve over time. If you need me to do that process it will have to wait until the weekend for me to have enough time to dedicate to that sort of testing.As of 14w25b, it is much more likely for the sand to break than piston disappear. I can't even get pistons to disappear in the test world on SP any more, but if I download our server files to a local test server and run them in 14w25b they do disappear on chunk unloads, but not at the same rate they used to (circa 14w10c).
"Regardless, both are likely caused by one of the following:
Sand falling onto a moving (extending or retracting) piston head, treating it like a non-solid block (such as a torch, rail, etc) and breaking.
Sand falling into an extending/extended piston head (
MC-4789) and breaking because it has nowhere to land (MC-6438).Sand falling into the empty space while the piston is retracted, and breaking rather than being pushed when it extends.
I think that falling sand, as an entity, would be pushed by the piston, and only break when landing on a non-solid block.", Torabi
I concur that all of these are possibly related. It needs a serious investigation to straighten it out. There may be an underlying tick processing issue, as was recently demonstrated by Panda in reference to Redstone Torch processing (
MC-56541).I have uploaded PistonVanishTest.7z, a revised version of my original test machine for these issues. Please use it for testing as it has the machine built outside the spawn chunks, ensuring chunk unloads on teleport. It also have signs explaining it's use and command blocks for teleport testing. I will revise it this weekend with command blocks to manipulate the tick rates to allow that sort of testing as well, but I need to research the commands for doing that and make sure my understanding is firm before I try updating this.
Thank you for that comprehensive testing and fault description. I appreciate the attention you are giving this issue.
You have explained something that had been confusing me: a conflicting set of results. I had been using the two machines interchangeably, assuming that they would produce similar results, but of course they do not. I am... amazed. That inconsistency hints at complexity behind the scenes, and indeed you seem to have hit the nail on the head: there are multiple interactions producing unexpectedly complex results.
If I (vaguely) remember correctly there were some posts on YouTube about new sand/gravel generators (DocM77 may even have done one) in the 14w branch, but as I don't use pure exploits I didn't look into their mechanics at all at the time. Part of bug either may be related to the re-emergence of these generators, or perhaps as a result of attempts to close the loophole again.
When I get home from work I'll have a dig around online and see if any of the new sand generators use mechanics seen in the demonstration machines above.
I have the same issue, but with item frames. I have removed most of them, but there is one left and I can't figure out where it is... I wonder how likely this is to be fixed any time soon, if at all.
Has anyone any suggestions on how to locate problematic objects?
João de Camões: I can see what you're saying, but I just want to be sure. You're talking about using the Fill/Replace tool in MCedit?
If the crash was:
{name=facing, clazz=class dt, values=[north, south, west, east]}java.lang.IllegalArgumentException: Cannot set property ayl
to down on block minecraft:wall_sign, it is not an allowed value
What is the code for a wall sign with the down orientation? 68:something? 68:0? I'm a bit wary about using replace tools and not quite knowing what I'm doing.
I wonder what it is about 2 tick pulses that makes them so peculiar. If you look at
MC-51662andMC-46225there are weird two tick interactions there as well.ChocolateChip Cookies -
I have done some testing with 14w27b and, on the surface, this seems to be (at least for now) working again. Given that Mojang have not closed the issue I would suggest either:
a) they are aware of the issue and don't consider it closed yet - this is (possibly/maybe) because 1.8 is still an object in motion, and further recoding and tweaking may break it again. That seems a bit thin (certainly without confirmation), but I guess we need to give them the benefit of the doubt.
b) they are not aware of the issue and the new (or should I say, restored old) behaviour is an unintentional side effect of other changes
Neither of these give much hope that's it's fixed for good at this stage. Given that the release notes on recent snapshots make no mention of piston mechanics it's reasonable to assume that what's been changed recently may be changed again, without warning or mention, in future releases, as that's what's happened before.
I resolved this by a roll-back, but since have moved to 14w27b and found it far more agreeable than previous versions. It's worth a try.
Is it just me, or is this much improved under 14w27b?
I had to make a world to confirm this under 14w27b. Please find it attached.
Note - the original bug post picture does not look the same under 14w27b as there is a separate bug affecting the appearance of Repeaters, making the settings appear reversed (1 is 4, 3 is 2, etc).
Again, I must wonder what the special case is for two tick pulses.
So very confusing the first time I tried to use a repeater in 14w27b! It's all sdrawkcab!
I get this too. There is nothing out of the ordinary on the server console:
10.07 17:31:07 [Server] INFO [17:31:07] [Server thread/INFO]: <clip> left the game
10.07 17:31:07 [Disconnect] User [17:31:07] [Server thread/INFO]: <clip> has disconnected, reason: TextComponent{text='Disconnected', siblings=[], style=Style{hasParent=false, color=null, bold=null, italic=null, underlined=null, obfuscated=null, clickEvent=null, hoverEvent=null, insertion=null}}
10.07 17:31:05 [17:31:05] [Server thread/INFO]: <clip> ran command Message of the Day
10.07 17:31:05 [Server] INFO [17:31:05] [Server thread/INFO]: <clip> joined the game
10.07 17:31:05 [Connect] User [17:31:05] [Server thread/INFO]: <clip>, IP <clip>
10.07 17:31:05 [Server] INFO [17:31:05] User Authenticator #4/INFO: UUID of player <clip> is <clip>
I restored a backup and tried again, same deal. Restored backup again and rolled back to 14w27b and it's fine again.
Related to
MC-51662orMC-46225?If you read the comments of
MC-51662andMC-46225you'll see the actual bugs don't derive from the piston but from the falling sand; the piston is just a method to induce the behaviour. In the case ofMC-46225, sand can fall into a piston, replacing it which effectively destroys the piston. If you add any block under falling sand at the right instant the sand would fall through it, too, if my understanding is correct. I've seen falling sand fall through pistons and then part way into the floor below on 14w10c. It's like it's got acid for bloodMy point was there has been recent jiggering (between 1.7.2 and 14w08a) with the falling sand mechanics (which lead to
MC-51662andMC-46225) and this issue may have arisen from that jiggering. How recently did you move to snapshots? Could the issue have been around since earlier snapshots and you didn't notice until recently? There has been subsequent jiggering which has evolvedMC-51662andMC-46225over time. This is likely the changes to the tick processing for block updates, or other recoding around the Mojang's efforts at making MC more efficient.Falling sand is a different object to sand at rest, IIRC, so there may have been other code changed recently that's delaying the transition from falling sand to stationary sand. Is the behaviour the same for gravel and all other gravity affected blocks? Just wondering if it's a property of the falling mechanic or of sand itself.
I was able to break and place blocks, but I have found out what was going on: I was outside the spawn radius. I was on my way back to close the ticket when I saw your very fast follow up.
The video is currently private and cannot be viewed.
Also, this appears to be in 14w32a: can you please update the affected version field?
Confirmed in 14w31a and 14w32a.
Also, it applies to crafting: you would expect shift clicking to move from inventory to the first available slot in the crafting window, but it moves it to the hot-bar, and vice-versa.
The bug still impacts 14w33a, however the scope is reduced. Setting the test loop repeaters on the test machine to two ticks will cause the blocks to break on travel to and from the nether (chunk unloads I suspect) on about one in five trips. It will also happen with the repeaters on one tick, but much less frequently than it use to, and again only when the chunk is unloaded and then loaded again..
I have uploaded a revised version of the test world. There is a setup now to move the player between the test site and a remote chunk, forcing the repeated load and unload of the chunk.
Sonicwave,
This is never getting fixed, unfortunately. It's been six months and there has been no official word from Mojang. I certainly won't be updating the ticket any more: I just can't keep investing my time in it. It took a monumental effort to even get a Mod to acknowledge this was a discrete bug, and that was a good three months prior to 1.8's release, plenty of time for Mojang to address it. It remains unassigned, so we can be sure of one thing: no-one is looking at it. And seeing as there are many bugs going back multiple versions that remain un-addressed, it seems this bug, like so many before it, aren't 'sexy' enough for Mojang to be bothered to fix it (there was plenty of time to add feature after feature to 1.8, but bug fixes are boring, it seems).
It's insulting to me to have spent twenty times the effort and time it would take to fix the bug updating tickets for each new snapshot, constantly re-testing because, as yet, I can't even be sure anyone at Mojang knows about the bug because there has been no official notice. And, while many people have sent me PMs about this, replied and commented on my YouTube videos about this, no-one up-votes the ticket, so it languishes here, un-addressed and without even a plan to acknowledge it, let alone fix it.
So, I am pretty much done with this bug now. And I may be done with Minecraft too: I paid for a product and it doesn't work to my satisfaction and the manufacturer has done nothing to resolve my issue. If I am willing to take that sort of treatment that just makes me a sucker. I want a refund.
Here's some other crazy behaviour related to this.
What you would expect from block descriptions on the Wiki:
The Minecart should travel East from the starting point then turn right.
What you would expect from MC-868:
The Minecart should travel East from the starting point, activate the detector rail around the corner then go left.
What actually happens:
Insanity ensues! Watch the video: https://youtu.be/HCrlaovpXuk
This bug is THREE YEARS OLD. Very soon, Mojang are going to have to pack this bug up and send if off to school it's so old.
Videogamer555,
I know it's not made clear, but if you read back in the comment history that it'll be fixed when 1.9 data structure is implemented. We're in early snapshots for 1.9, so it's a bit early to expect this to be finished.
That being said, I have a host of bugs I have been watching, many over two years old, and I was told in several of those that they would be fixed in 1.8, and they weren't, and haven't had a mod or dev post on them since 1.8's release, so I wouldn't hold my breath.
Gerhard Pillow:
Water flows and similar things make it much worse, but I certainly have experienced it in 1.8. With all mobs, having many of the mob in the pen makes it much worse, but I noticed it with Villagers glitching out of a Iron Farm design, too. They were not glitching through the floors, but through a head hight wall designed to separate adult from baby villagers. This suggests weird processing of the hitboxes on chunk load perhaps. It certainly only happens when the chunk is unloaded and then loaded again. For critical farms I have had to implement keep-alive mechanisms tied to a world-clock in the spawn chunks, or resort to locating the farm in the spawn chunks, but spawn is very crowded these days, with things like Iron Foundaries making door placement... problematic.
Jordan Davis:
The problem seems to revolve around chunk loads. Maybe the best way is to move mobs away from fences and other blocks on load, but I am not sure how that would work. I didn't see this bug for all the time I was on 1.7, but since 1.8.1 dropped (when I first started playing 1.8 on my primary server) I have noticed it. It has prevented me constructing many farms under 1.8 as I don't want to build the farm and have to restock it every few days, especially if the farm involves farmer villagers: it's such a pain to breed 50 villagers to get the 3 farmers that you need (OK, not 50, but it feels that way). The only solution I have found so far is to locate the farms in your spawn chunks, but spawn chunks are already pretty busy, these days, or use a keep-alive mechanism tied to a world-clock at spawn. That's a terrible solution because it means chunks I would happily let unload are loaded all the time, increasing server load and producing lag.
And, at this stage, it's not fixed on the 1.9 track. It's very frustrating. Jeb is actually assigned to the bug, so I would suggest it will get resolved in short order. That seems to be how bugs go: they may sit idle for some time, but if it's actually assigned you can be sure someone's actually looking at it. If a bug isn't assigned you can't assume someone at Mojang isn't watching it, but you can't assume someone is, either. Do a search on assigned bugs: you'll find that it's an amazingly low number when compared to the total number of open bugs.
Captain Starbuck:
It's a good suggestion, but's it's unlikely that Mojang will change their system: I've seen many good suggestions made in the past, and I don't recall ever seeing or hearing about one being implemented. We'll have to wait and see. I certainly am sick of the 8 or 9 e-mails I get every day about issues I am watching on JIRA, seeing as 90% of the time the e-mail was generated by someone posting a comment along the lines of "This bug is 2 years old, why hasn't it been fixed?" to which I can only reply "I don't know, we get no feedback or indication when bugs will be resolved". Another 5% is a Mod saying "This is old and the OP hasn't updated it recently, can I close it?" And about 0.05% of the time it's actually a post about the issue being fixed... So, yeah, lots of frustrating noise drowns out actual feedback from Mojang.
I get the distinct impression that Mojang don't particularly want people to know that they are looking at a bug until they are actually going to fix it soon, an impression I have been given by Moderator commentary. I, personally, wish that it was more like a traditional helpdesk where jobs are assigned and evaluated quickly. The assignee then communicates with the user community an estimated time to resolve the problem (setting the end users' expectations). This allows the users to evaluate if they will wait for a fix or find a work-around themselves. I certainly would have skipped 1.8 altogether if Mojang had honestly communicated their intentions: much of what I have been trying to do in Minecraft for the last year has revolved around mechanics that are currently hopelessly bugged, and many of those issues have had zero feedback from Mojang for over a year. Some of them were recently assigned for resolution in the lead up to 1.9.
I would have been better off not starting a new world for 1.8, and sticking to the much stabler and better supported 1.7, and then start a new world in 1.9. From my perspective, 1.8 broke more features I use than it introduced. Administering a 1.8 server has become an increasingly frustrating experience as not only am I frustrated by the numerous bugs, but I also have to investigate user complaints, and then prove to the user that it's a bug and not a problem with the server. I then inevitably am left with the responsibility to both report the bug and track it, or find an existing issue and track that, all adding to my workload in administering that server.
With Mojang, you just have no idea whether or not a bug will be fixed until right before it is fixed. Thus, bugs can sit for years with user after user posting comments like 'this was reported 2 years ago, is there an estimate to when it will be fixed?' to which the official answer is almost always silence. All it would take is one comment from a Mojang staffer or Moderator: "This is linked to core game design. We need to change the way many things are done to fix it, and each of those things has other things contingent on it. We'll address the first set of issues in the lead up to the next version, and the second phase in the version after that. So, about two to three years". Then people would have something they could work with. Maybe it would be useful for Mojang to mark some bugs as "On Hold" while they establish what is involved in a fix or while they wait to resolve other bugs or implement other features that are holding up the fix. What Mojang does now is inherently deceptive: you just don't know when your bug will win the support lottery; it may be tomorrow, it may be two years from now, it may be never. You just never know.
Another reason users should be able to close their own tickets! Don't worry, I've opened tickets and then fixed the issue straight away, too.
Thanks for following up that you fixed it. I am sure a Mod will be along to close it for you, soon enough.
Your Java version is quite old. 1.8.0_65-b17 is the version I am running. Maybe it's worth an upgrade.
KingSupernova
I agree that it's technically not fixed, but the work-around is a good one, if we assume that an actual fix is not feasible for some reason. This might be a case where the developer could let us know what happened behind the scenes so we have a better understanding and are more accepting of the choice of work-around over resolution, but it's Mojang's prerogative to do so or not.
It feels instinctively like a hack, but there may be really good reasons why changing the stronghold generation code was not practical. At least now servers with 20 or so players will probably generate with enough strongholds for each player to claim their own, and have some choice in which one the claim. I am sure that someone will eventually find a seed that fails to generate all 128 strongholds, but that would have to be really unlikely. I wonder if Mojang actually modelled that to prove how unlikely... It's an interesting thought experiment, if nothing else.
And you are correct that the chances of ender-pearls and end portals are not comparable. End-portal numbers are bound (3 in pre 1.9, 128 in 1.9+), where as there is no upper limit to the number of Endermen because they respawn. But, 128 does stack the deck to the point that I have to say that the chances of none of the end portals spawning is almost nil, so close to nil that it's effectively the same thing. At least it's been addressed to some extent! One less open bug I am watching
I can confirm that:
this impacts 18w15a
it impacts both AMD (tested on Vega 64) and nVidia (tested on 960m).
There is similar lag near forest mansions, but that's usually caused by fire (fire seems to spread faaaast in 18w15a), but I checked around in spectator mode for fire near the jungle and that didn't appear to be the problem.
There was a similar bug back around 2014 or 2015. Maybe an old making a comeback?
I can confirm for 18w15a.
Forest Mansion burned down in a minute because of a lava block.
I thought that this was a cause for
MC-125442, but it seems that the issue causing jungle lag is separate to this issue: I scouted around a Jungle in spectator mode and didn't see any fire to explain the lag.I can confirm that lighting causes lag spikes in 18w15a.
I couldn't tell from testing whether this is client side or server side (or a little of both).
That .gif makes it pretty clear that there's an issue
Brianna,
Is this bug happening when you start the game, or when you load a world? Did the game crash while you were playing, and then refuse to start after that?
Can you attach a crash report? You should look in C:\Users%username%\AppData\Roaming\.minecraft\crash-reports and see if there are files being created when the game crashes.
Is there any indication (on the WIki or elsewhere) where this is not the intended behavior?
With the advent of the Turtle Shell helm (mixed with Respiration and Aqua Affiinity) I find myself doing a lot of diving, and I often break and collect my boat as I might come up a long way from when I began my dive. This being so, the ability to place a boat on returning to the surface is quite useful.
I agree with your bug report
MC-128895, as it doesn't make sense of the map to need your hands to hold it on land and not underwater, but this seems like the intended behavior.I am pretty sure this a duplicate of
MC-128700I can confirm this bug on 18w16a.
I can see where Mojang was going with this, but the repercussions are sever for existing worlds. It is more realistic, and some may want that, but it breaks a lot of things
The new water physics, perhaps, should be settable at creation of the world, and disabled by default for worlds imported from old versions. There are serious implications for a lot of existing designs and worlds just from water being able to flow over slabs, let alone it effectively turning slabs into source blocks.
I think the mechanic needs more nuance if it's going to make it into a release. Either it needs to be configurable if implemented this way, or the mechanic needs to operate like traditional water blocks do and have a flowing water mechanism like there is with full blocks so infinite spread doesn't happen.
It could also be that we've seen the first pass at the mechanic and that Mojang already intended to evolve it over time. Time will tell!
It seems this has been resolved, as of 18w20b. I just started a single player world and tested the locate command and it worked and the stronghold was at the location it said.
As a further test I logged into our playtest MP server which had previously produced bugged answers to the locate command. Strongholds did not generate near the locations suggested by Amidst or other mapping tools. As of 18w20b I can confirm that Strongholds generate where expected and that the locate command works, even on worlds imported from 18w19a. Please note that when we found that the locate command was bugged and Strongholds were not where they should have been we took care not to generate chunks where Amidst reported Strongholds should have been. I would suggest that users who have imported worlds from before the bug was resolved will have to purge chunks to make them regenerate to ensure that the fixed world generation works correctly.
The problem with Neko's comment above (https://bugs.mojang.com/browse/MC-148504?focusedCommentId=536094&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-536094) is that there is no method for server admins to optimise worlds with the "Erase cache data" option.
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
crash-2019-05-08_10.07.13-server.txt
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.
crash-2019-05-20_22.11.09-server.txt
crash-2019-05-20_22.19.31-server.txt
profile-results-2019-05-20_23.39.20.txt
^profile-results-2019-05-20_23.51.30.txt
^
^^profile-results-2019-05-20_23.59.35.txt
^^
@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.
@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.
@Kamil Pigłowski
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 bothMC-138550andMC-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. IfMC-138550does 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.
@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.
@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.
Mudassar Khan
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.
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:
However after running the farm for over an hour I did not see any of the following:
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.
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.
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.
@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.
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.
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.
This impacts MCPE too:
MCPE-58748This 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".
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.
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...".