tetsujin
- tetsujin
- tetsujin
- Europe/Stockholm
- Yes
- No
MCPE-37679According to the wiki, when a kelp block is broken, the kelp block below the one that was broken (if any) gets a random age between 0 and 24 (not 25) - so if you break the second block of a kelp plant, the first one should still grow at least once. Most farm designs take advantage of this as Sickle says, so that while there's a fair chance that a single kelp plant might not grow high enough to trigger an observer, the piston can still be activated by other observers, meaning that there is a very miniscule chance (as in, under one billionth of a percent) that a kelp plant that re-rolls to age 24 would not be harvested again in a typical piston/observer kelp farm design.
I am encountering this issue as well, but only on my survival world. I tried it in a second location (several hundred blocks away) and I think it teleported me back to the overworld again, but I was killed by a monster immediately so I'm not sure. My nether portal in my creative world works correctly.
For the past month or so of beta versions, I have been unable to use the phone's "home", "back", and "recents" buttons while in game, they simply do nothing. This made it very difficult for me to exit Minecraft until I learned alternate methods (i.e. exiting from Minecraft using the phone's pull-down notification menu)
The device is a OnePlus 3T (A3000) running Android 9. The device's navigation keys are capacitive sensors but are separate from the sensor used by the touch screen.
tetsujin: Your input is welcome, but don't go to a lot of trouble with it. Mega_Spud and I have been talking about this and I'm preparing to revise the description with the new information, new repro steps, and a new sample world. I'm also looking a little deeper into what about the water above the top kelp may be stopping it from growing.
There are a lot of "me too" comments here but I want to add some specific information on what has I have observed: (Playing on Android, BTW)
I have a 1-chunk kelp farm with 504 kelp plants harvested by timer-controlled pistons. It's a vertically stacked design so different plants occupy the same X/Z coords but at different elevations.
The machine sits in an ocean biome (deep ocean I think), extending from sea level down to about Y=32. AFAIK kelp growth does not depend on light levels, but in my build I chose to light the interior of the farm - light levels should be no lower than 10 at any point in the farm.
I designed and initially built the machine in Bedrock 1.13 and it consistently yielded around 9000 kelp per hour
In Bedrock 1.14 it now produces around 1100 kelp per hour, roughly 1/8 the speed. (Rate measured over 5 minutes of operation yielding less than 100 kelp)
I don't know if this change was intended or not. Personally I'm hoping my farm will be restored to its previous level of performance in a future update of the game.
Don't know what your post has to do with anything. Who was talking about "0 tick" or piston glitches? This bug is about legit, conventional kelp farms. 1.14 seriously dropped the growth rate of kelp, presumably as part of the effort to fix lag issues with kelp.
Yann, thank you for the information. I don't play Java ed. so I don't really know how fast kelp grows there. Even if I don't like lower rates, I can respect a decision like that for the purpose of game balance and parity, if that's really what is going on here.
I'll have to look into that "sometimes the kelp just stops at random age" to see if that is what's going on. However it seems to me like this can be explained by the difference in random tick rate between the platforms:
According to the Minecraft wiki there is a difference in the frequency of random ticks: On Java Edition a block will get a random tick, on average, once every 68 seconds. On Bedrock Edition, it's said to be around to 205 seconds.
So if we use my farm as an example again: In 1.13 we would expect 504 kelp plants, harvested periodically, random ticking once every 205 seconds, and growing 100% of the time they receive a tick, to yield:
3600 sec/hr * 1 item/tick * 1 tick/205 seconds * 504 plants = 8850 items per hour (a bit short of my 9000/hr estimate)
If 1.14 dropped the rate to 0.14 items per random tick (14% growth chance per random tick) we would get this:
3600 sec/hr * 0.14 item/tick * 1 tick/205 seconds * 504 plants = 1239 items per hour (on the high end of what I have measured for the farm in 1.14)
On Java, I believe the output of the farm would be higher due to more frequent random ticking:
3600 sec/hr * 0.14 item/tick * 1 tick/68 seconds * 504 plants = 3735 items per hour
In other words I think what we may be seeing here is parity in terms of growth per random tick, but a slower random tick rate. If I am correct about Java behavior then my 504 plant farm should still be producing about 3 times what it currently yields on Bedrock.
If kelp grows more slowly than on Java, that's not "parity" - that's kind of my point. Kelp growth was about 2x faster than on Java, and now it's slower, about 1/3 as fast as Java. Getting parity with Java would still mean less kelp than in Bedrock 1.13 - but a lot more than we're getting now - I could live with that.
But I also wanted to point out that if the change from Bedrock 1.13 to 1.14 was to reduce the chance of kelp growth per update from 100% to 14%, that actually fits what I've observed in farm performance pretty well. If a significant number of the plants simply weren't growing at all, I wouldn't expect that to be the case.
I do plan to look into the phenomenon you describe and see what impact it's having on all this, but at the moment I don't have the tools to view that NBT data, so it will have to wait a bit.
With regard to shulker loaders and unloaders, what I have seen is that designs that previously worked with less that 1% loss of shulker boxes (and in many cases, designs which I had NEVER seen lose a shulker box) are now experiencing loss rates in the neighborhood of 30%.
As an example, there is a 1-wide loader design by navynexus that breaks the shulker with a horizontal sticky piston and trap door that I tested in earlier 1.14 versions, put 100 shulker boxes through them and every single one was collected. In 1.14.20, in a 50 shulker test it lost around 20 boxes.
Breaking shulkers with a sticky piston and trap door had been one of the most reliable ways to do it. Shulker boxes would have a bit of random velocity to them, but they were pretty much guaranteed to stay in the same space and drop down. Now the shulker box is likely to glitch through the piston head and despawn.
As another example, I have a manual shulker unloader (a "crafting station") which breaks the shulker box from above with a vertical sticky piston and either a trap door, end rod, slab, etc. - again, a design I had tested with hundreds of shulker boxes in prior versions and not observed any being lost in the machine. All of these options now result in the shulker box glitching upward through the piston head a fair percentage of the time, and remaining there once the next shulker is dispensed.
Shulker loaders and unloaders on Bedrock have always been a bit unreliable on Bedrock in my experience because, almost without exception, any method you use to break the box will result in it having some random velocity that can send it flying, glitching through corners, popping out the back of a piston, etc. But with some careful design a loader could still be quite reliable. But a lot of designs that were quite reliable before 1.14.20 are now very unreliable. Given the relatively high cost of acquiring more shulker boxes in-game (i.e. by end raiding) I see this as a pretty serious problem.
I have tested my kelp farm in 1.14.30 and got a rate of about 2500 kelp per hour, down from the 9000 per hour I got in 1.13, and still below the roughly 3700 per hour I'd estimate the farm would produce on Java - but up from the roughly 1100 per hour I got in 1.14.0. (EDIT: I think I did that test on 1.14.0 before I knew that kelp would sometimes stop growing, so it's possible that 1100 per hour I observed is lower than it would have been after a replant.) So it's still seemingly not even up to parity with Java.
(The farm has around 500 plants, with enough water to grow up to 3 tall, with a timer-controlled harvest approximately every 100 seconds)
When I replant the farm, I remove any plants that hadn't grown to 2 or higher, and then bone-meal them to make sure they are (initially, at least) able to grow. But as the farm runs, and individual plants are harvested repeatedly, some of them will not grow back to height 2 or greater (even if bonemeal'ed) unless they are replanted again - if this is a result of the randomized kelp age after the kelp above is harvested, I'd expect this to happen about 3.8% of the time, and so after around 18 harvests (about half an hour of operation) my farm's yield would drop to about half of what I get immediately after a replant.
There are basically two phenomena reported here which impact kelp farm performance:
I don't actually know the specifics, in detail, of either issue. I have run some tests but I haven't separated the two phenomena in that data. Most of us observe the issues by running a kelp farm and seeing how much kelp we get out of it - which unfortunately doesn't give us a clear picture of which of these two phenomena are at play, as both issues affect farm output. In my earlier tests I just reported the farm's configuration and yield, but hadn't replanted it. Later I found that dozens of my plants had been halted.
So for instance in the initial report, "In my Kelp farm, I broke them all down to last base Kelp and waited, and after nearly 30 minutes of waiting only a Single stalk of Kelp had grown, and it had only grown once."
The act of breaking all kelp down to 1-high may itself have halted the growth of those plants. Or since the test was done in an operational farm, several of the plants may have already been halted.
I will attempt to get some good data on how frequently breaking a kelp plant results in it not growing back, and on what kind of kelp growth rates we are getting before the plants enter this state.
This may be a case of
MCPE-159285. My death in my world does meet the criteria described in that bug (I was over 2000 blocks away from spawn, and when reloading the world I am stuck at "Building terrain" as in 159285). I hadn't spotted 159285 prior to creating this ticket.I don't know for sure if this is the issue I am encountering. When I go through a nether portal in my survival world, I take damage for a while and then wind up back in the overworld. I've tried it in two different locations (hundreds of blocks away from each other) with more or less the same result.
I was experiencing this issue, but solved it in my survival world:
When I tried to go to the nether, I took damage. Initially I thought this was suffocation damage. I'd go into the portal, take damage for a while, then appear in the overworld again. However, on one attempt, I actually got killed by a monster. At first I thought I went into the portal, took damage, then came out in the overworld (at some random location) and got killed by a monster there, but it occurred to me that the "suffocation damage" might just be a monster in the nether attacking me, and the reason I reappeared in the overworld might be because of collision with the monster or something. So I put Thorns enchantment on my armor and went in again, heard the zombie taking damage from Thorns, and then I appeared in the nether and could finish him off.
Through all of this I also saw symptoms of
MCPE-159900: when I couldn't go through my regular overworld portal, I constructed another one 500 blocks east of the first one in my industrial district. When I tried to go through it I was killed by the zombie, but I found most of my dropped items outside my regular overworld portal. I had traveled to the nether, but to the same portal on the nether side that the original portal is linked to, got killed by the zombie there, and my items traveled back to the first portal in my industrial district. I will provide more details of my experience on that ticket.I experienced this issue on v1.19.50 on Android.
I first experienced this issue while facing
MCPE-162742- Basically there was a zombie in the nether, either in the portal or close to it, so each time I'd go through the portal I'd take damage and then wind up in the overworld again. However, I've killed the zombie and discovered that this issue, of going to the wrong location in the nether, still persists.I started out trying to go through my industrial area portal at (950, 32, 3008) (hoping to reach the portal in the nether at (105, 98, 360)) and reappearing at a new portal in the middle of my industrial area (840, 81, 2866). Desperate for a way to escape this problem I traveled East looking for another nether portal, ultimately giving up and building a new portal at (1439, 61, 2973) - but when I traveled through this portal, I got killed by the zombie and was worried that my items would be lost at some random location in the overworld or some new portal somewhere in the nether.. But in fact I found most of them at my industrial area portal (950, 32, 3008), and a few others in the nether at (105, 98, 360). After killing the portal zombie I again traveled to (1439, 61, 2973) to try the portal again, and found myself this time in the nether at (105, 98, 360). So I can confirm this issue. v1.19.50 on Android.
As I understand it, the "ideal" location for a nether portal linked to (1439, 61, 2973) would be (179, _, 371), and the farthest the game should look to the North/West in the nether for a portal should be about (162, _, 352) - the NW extent of the chunk to the NW of the ideal portal location. Instead it linked to a portal another 57 blocks to the West of that chunk. The portal it linked to is in the proper Z range but not the proper X range.
Once I was able to reach the nether again I traveled to a more distant portal: using the portal at (950, 32, 3008) I went to (105, 98, 360) in the nether, then flew through the nether to (635, 98, minus 1073) to the stronghold at (5070, 33, minus 8578). I was curious to see if crossing into the nether from a more distant portal would also send me back to (105, 98, 360). It did not, instead it sent me back to the correct portal on the nether side, (635, 98, minus 1073). Then I was curious to see if the bug was sending me to the last portal I'd entered from the nether side, so I traveled back to (950, 32, 3008) via the overworld and re{-}entered the portal there, but again landed at the correct location in the nether, (105, 98, 360). I've not yet checked to see exactly how far away an overworld portal can be and still link to the same portal in the nether. I also haven't yet determined if this still happens if there's a closer portal to the "ideal" location (overworld coords / 8) on the nether side.
I, too, have been relying on this behavior and am disappointed to see it no longer works. In my case the use case is a pumpkin farm, in which rails are moved through a row of pumpkins by a flying machine, with hopper minecarts on them to collect the pumpkins as they're broken.
I believe this new behavior creates a disparity with Java Edition, as this style of farm is common for high-yield pumpkin farms on Java.
My phone is a Oneplus 3T running Android 9. The navigation keys are capacitive, not part of the display.
Sorry, not a bug, my mistake:
Buttons were disabled by "gaming mode"