MaladjustedPlatypus
- Mistahtokyo
- mistahtokyo
- America/New_York
- Yes
- No
MCPE-20640
BDS-42
Fixed in the 1.2 Beta release.
Still seems to be affecting 1.2.5.15
Verification builds:
1.2.5.15 BetaSummary:
Prior to 1.2 observers detecting a piston head that it was powering would form a "clock". This was incorrect behavior since observers, normally taking 1 tick to detect and output a signal, would have had it's signal ignored (as the piston head would have been retracting while receiving the pulse, therefore ignoring it).This was fixed in 1.2, perhaps as a side produc of the faster observers and the instant chaining observers. It has returned in 1.2.5.15, possibly as a side effect of this bug being fixed:
bugs.mojang.com/browse/MCPE-23947Steps to Reproduce:
1.Build setup as posted in the attached videos.
2. Turn the lever on to "prime" the setup.
3. Turn the lever off.Observed Results:
The piston retracts, but then extends and retracts ad infinitum.Expected Results:
The piston retracts, ignoring the observer's pulse since it (should) be occurring at the same tick that the piston head is retracting.Screenshots/Videos attached: Yes
Notes:This is a borderline case of bug/game design issue. It seems that to fix this, the observer clock linked in the bug report above must be broken, unless some special exception is made.Verification builds:
1.2.5.15 Beta
Summary:
Prior to 1.2 observers detecting a piston head that it was powering would form a "clock". This was incorrect behavior since observers, normally taking 1 tick to detect and output a signal, would have had it's signal ignored (as the piston head would have been retracting while receiving the pulse, therefore ignoring it).This was fixed in 1.2, perhaps as a side produc of the faster observers and the instant chaining observers. It has returned in 1.2.5.15, possibly as a side effect of this bug being fixed:
bugs.mojang.com/browse/MCPE-23947Steps to Reproduce:
1. Build setup as posted in the attached videos.
2. Turn the lever on to "prime" the setup.
3. Turn the lever off.
*
Observed Results:*The piston retracts, but then extends and retracts ad infinitum.
Expected Results:
The piston retracts, ignoring the observer's pulse since it (should) be occurring at the same tick that the piston head is retracting.
*
Screenshots/Videos attached:*Yes
*
Notes:*This is a borderline case of bug/game design issue. It seems that to fix this, the observer clock linked in the bug report above must be broken, unless some special exception is made.
Verification builds:
1.2.5.15 Beta
Summary:
Prior to 1.2 observers detecting a piston head that it was powering would form a "clock". This was incorrect behavior since observers, normally taking 1 tick to detect and output a signal, would have had it's signal ignored (as the piston head would have been retracting while receiving the pulse, therefore ignoring it).This was fixed in 1.2, perhaps as a side produc of the faster observers and the instant chaining observers. It has returned in 1.2.5.15, possibly as a side effect of this bug being fixed:
bugs.mojang.com/browse/MCPE-23947Steps to Reproduce:
1. Build setup as posted in the attached videos.
2. Turn the lever on to "prime" the setup.
3. Turn the lever off.
*
Observed Results:*The piston retracts, but then extends and retracts ad infinitum.
Expected Results:
The piston retracts, ignoring the observer's pulse since it (should) be occurring at the same tick that the piston head is retracting.
*Screenshots/Videos attached:*Yes
*Notes:*This is a borderline case of bug/game design issue. It seems that to fix this, the observer clock linked in the bug report above must be broken, unless some special exception is made.
Verification builds:
1.2.5.15 Beta
Summary:
Prior to 1.2 observers detecting a piston head that it was powering would form a "clock". This was incorrect behavior since observers, normally taking 1 tick to detect and output a signal, would have had it's signal ignored (as the piston head would have been retracting while receiving the pulse, therefore ignoring it).This was fixed in 1.2, perhaps as a side produc of the faster observers and the instant chaining observers. It has returned in 1.2.5.15, possibly as a side effect of this bug being fixed:
bugs.mojang.com/browse/MCPE-23947Steps to Reproduce:
1. Build setup as posted in the attached videos.
2. Turn the lever on to "prime" the setup.
3. Turn the lever off.
*
Observed Results:*The piston retracts, but then extends and retracts ad infinitum.
Expected Results:
The piston retracts, ignoring the observer's pulse since it (should) be occurring at the same tick that the piston head is retracting.
Screenshots/Videos attached:
Yes
Notes:
This is a borderline case of bug/game design issue. It seems that to fix this, the observer clock linked in the bug report above must be broken, unless some special exception is made.
Verification builds:
1.2.5.15 Beta
Summary:
Prior to 1.2 observers detecting a piston head that it was powering would form a "clock". This was incorrect behavior since observers, normally taking 1 tick to detect and output a signal, would have had it's signal ignored (as the piston head would have been retracting while receiving the pulse, therefore ignoring it).This was fixed in 1.2, perhaps as a side produc of the faster observers and the instant chaining observers. It has returned in 1.2.5.15, possibly as a side effect of this bug being fixed:
bugs.mojang.com/browse/MCPE-23947Steps to Reproduce:
1. Build setup as posted in the attached videos.
2. Turn the lever on to "prime" the setup.
3. Turn the lever off.
*Observed Results:*The piston retracts, but then extends and retracts ad infinitum.
Expected Results:
The piston retracts, ignoring the observer's pulse since it (should) be occurring at the same tick that the piston head is retracting.
Screenshots/Videos attached:
Yes
Notes:
This is a borderline case of bug/game design issue. It seems that to fix this, the observer clock linked in the bug report above must be broken, unless some special exception is made.
Verification builds:
1.2.5.15 Beta
Summary:
Prior to 1.2 observers detecting a piston head that it was powering would form a "clock". This was incorrect behavior since observers, normally taking 1 tick to detect and output a signal, would have had it's signal ignored (as the piston head would have been retracting while receiving the pulse, therefore ignoring it).This was fixed in 1.2, perhaps as a side produc of the faster observers and the instant chaining observers. It has returned in 1.2.5.15, possibly as a side effect of this bug being fixed:
bugs.mojang.com/browse/MCPE-23947Steps to Reproduce:
1. Build setup as posted in the attached videos.
2. Turn the lever on to "prime" the setup.
3. Turn the lever off.Observed Results:
The piston retracts, but then extends and retracts ad infinitum.
Expected Results:
The piston retracts, ignoring the observer's pulse since it (should) be occurring at the same tick that the piston head is retracting.
Screenshots/Videos attached:
Yes
Notes:
This is a borderline case of bug/game design issue. It seems that to fix this, the observer clock linked in the bug report above must be broken, unless some special exception is made.
Verification builds:
1.2.5.15 Beta
Summary:
Prior to 1.2 observers detecting a piston head that it was powering would form a "clock". This was incorrect behavior since observers, normally taking 1 tick to detect and output a signal, would have had it's signal ignored (as the piston head would have been retracting while receiving the pulse, therefore ignoring it). This was fixed in 1.2, perhaps as a side product of the faster observers and the instant chaining observers. It has returned in 1.2.5.15, possibly as a side effect of this bug being fixed:
bugs.mojang.com/browse/MCPE-23947Steps to Reproduce:
1. Build setup as posted in the attached videos.
2. Turn the lever on to "prime" the setup.
3. Turn the lever off.Observed Results:
The piston retracts, but then extends and retracts ad infinitum.
Expected Results:
The piston retracts, ignoring the observer's pulse since it (should) be occurring at the same tick that the piston head is retracting.
Screenshots/Videos attached:
Yes
Notes:
This is a borderline case of bug/game design issue. It seems that to fix this, the observer clock linked in the bug report above must be broken, unless some special exception is made.
World file: https://pixeldrain.com/u/5GPf8v3V (Had to upload externally due to the large file size).
Server is running mostly default survival settings except for simulation distance of 6 and chunk render distance of 32. Has been stable for the past year without issue until around 1 month ago. At first we believed the crashes to be caused by entering portals too quickly (going from nether to overworld, then overworld to end portal fast) since some of the crashes were occurring under those conditions, but we have also been getting crashes throughout normal gameplay, when performing normal actions such as placing blocks or even walking around. The crashes occur in multiple areas, overworld, nether, and end. There doesn't seem to be a specific chunk or groups of chunks causing this since the same areas may be fine one moment, then crash at another. As of now the server will crash at least 4-5 times a day if people are active. Checking memory usage showed a steady usage of around 700MB our of the 3GB allocated, so there doesn't seem to be any issue there.
Crash reports are fairly limited in information, but here are some of them:
CrashReporter Key: 8c4937c1-64cb-3532-a8dc-1deb28f67293
Crash
[2022-08-18 21:19:27:947 INFO] at clone (UnknownFile:?)
[2022-08-22 01:26:19:319 INFO] at clone (UnknownFile:?)
[2022-08-11 15:46:43:396 INFO] at clone (UnknownFile:?)
This is the most verbose one we managed to get:
[2022-08-11 14:58:04:885 INFO] Package: com.mojang.minecraft.dedicatedserver
Version: 1.19.20.02
OS: Linux
Server start: 2022-08-11 00:18:58 UTC
Dmp timestamp: 2022-08-11 14:58:04 UTC
Upload Date: 2022-08-11 14:58:04 UTC
Session ID: f56e352f-fa47-405d-a38f-f0ea09422adc
Commit hash: 1aa76c5813541fe1bbb16c4e3a0af2b29474dc34
Build id: 10811062
CrashReporter Key: 8c4937c1-64cb-3532-a8dc-1deb28f67293Crash
[2022-08-11 14:58:04:885 INFO] at clone (UnknownFile:?)
dd62e092-4219-4cc3-b64c-90de895b1b67DEBU[52747] Forwarding signal signal="child exited"
ERRO[52747] Failed to signal sub-command error="os: process already finished"Edit: Added more crash logs. Info is still seemingly vague. The most reliable crashes seem to be from going through portals. To trigger, first load the world on a server (NOT single player), then go from spawn to the nether, from the nether to the end portal station, through to the end, then back to spawn. Repeat a few times and you should eventually crash.
World file: https://pixeldrain.com/u/5GPf8v3V (Had to upload externally due to the large file size).
Server is running mostly default survival settings except for simulation distance of 6 and chunk render distance of 32. Has been stable for the past year without issue until around 1 month ago. At first we believed the crashes to be caused by entering portals too quickly (going from nether to overworld, then overworld to end portal fast) since some of the crashes were occurring under those conditions, but we have also been getting crashes throughout normal gameplay, when performing normal actions such as placing blocks or even walking around. The crashes occur in multiple areas, overworld, nether, and end. There doesn't seem to be a specific chunk or groups of chunks causing this since the same areas may be fine one moment, then crash at another. As of now the server will crash at least 4-5 times a day if people are active. Checking memory usage showed a steady usage of around 700MB our of the 3GB allocated, so there doesn't seem to be any issue there.
Crash reports are fairly limited in information, but here are some of them:
CrashReporter Key: 8c4937c1-64cb-3532-a8dc-1deb28f67293
Crash
[2022-08-18 21:19:27:947 INFO] at clone (UnknownFile:?)
[2022-08-22 01:26:19:319 INFO] at clone (UnknownFile:?)
[2022-08-11 15:46:43:396 INFO] at clone (UnknownFile:?)
This is the most verbose one we managed to get:
[2022-08-11 14:58:04:885 INFO] Package: com.mojang.minecraft.dedicatedserver
Version: 1.19.20.02
OS: Linux
Server start: 2022-08-11 00:18:58 UTC
Dmp timestamp: 2022-08-11 14:58:04 UTC
Upload Date: 2022-08-11 14:58:04 UTC
Session ID: f56e352f-fa47-405d-a38f-f0ea09422adc
Commit hash: 1aa76c5813541fe1bbb16c4e3a0af2b29474dc34
Build id: 10811062
CrashReporter Key: 8c4937c1-64cb-3532-a8dc-1deb28f67293Crash
[2022-08-11 14:58:04:885 INFO] at clone (UnknownFile:?)
dd62e092-4219-4cc3-b64c-90de895b1b67DEBU[52747] Forwarding signal signal="child exited"
ERRO[52747] Failed to signal sub-command error="os: process already finished"Edit: Added more crash logs. Info is still seemingly vague. The most reliable crashes seem to be from going through portals. To trigger, first load the world on a server (NOT single player), then go from spawn to the nether, from the nether to the end portal station, through to the end, then back to spawn. Repeat a few times and you should eventually crash.
Server is running mostly default survival settings except for simulation distance of 6 and chunk render distance of 32. Has been stable for the past year without issue until around 1 month ago. At first we believed the crashes to be caused by entering portals too quickly (going from nether to overworld, then overworld to end portal fast) since some of the crashes were occurring under those conditions, but we have also been getting crashes throughout normal gameplay, when performing normal actions such as placing blocks or even walking around. The crashes occur in multiple areas, overworld, nether, and end. There doesn't seem to be a specific chunk or groups of chunks causing this since the same areas may be fine one moment, then crash at another. As of now the server will crash at least 4-5 times a day if people are active. Checking memory usage showed a steady usage of around 700MB our of the 3GB allocated, so there doesn't seem to be any issue there.
Crash reports are fairly limited in information, but here are some of them:
CrashReporter Key: 8c4937c1-64cb-3532-a8dc-1deb28f67293
Crash
[2022-08-18 21:19:27:947 INFO] at clone (UnknownFile:?)
[2022-08-22 01:26:19:319 INFO] at clone (UnknownFile:?)
[2022-08-11 15:46:43:396 INFO] at clone (UnknownFile:?)
This is the most verbose one we managed to get:
[2022-08-11 14:58:04:885 INFO] Package: com.mojang.minecraft.dedicatedserver
Version: 1.19.20.02
OS: Linux
Server start: 2022-08-11 00:18:58 UTC
Dmp timestamp: 2022-08-11 14:58:04 UTC
Upload Date: 2022-08-11 14:58:04 UTC
Session ID: f56e352f-fa47-405d-a38f-f0ea09422adc
Commit hash: 1aa76c5813541fe1bbb16c4e3a0af2b29474dc34
Build id: 10811062
CrashReporter Key: 8c4937c1-64cb-3532-a8dc-1deb28f67293Crash
[2022-08-11 14:58:04:885 INFO] at clone (UnknownFile:?)
dd62e092-4219-4cc3-b64c-90de895b1b67DEBU[52747] Forwarding signal signal="child exited"
ERRO[52747] Failed to signal sub-command error="os: process already finished"Edit: Added more crash logs. Info is still seemingly vague. The most reliable crashes seem to be from going through portals. To trigger, first load the world on a server (NOT single player), then go from spawn to the nether, from the nether to the end portal station, through to the end, then back to spawn. Repeat a few times and you should eventually crash.
Edit 2: Made the bug public and removed the world file since I confirmed the memory leak occurs with a fresh world.
Server is running mostly default survival settings except for simulation distance of 6 and chunk render distance of 32. Has been stable for the past year without issue until around 1 month ago. At first we believed the crashes to be caused by entering portals too quickly (going from nether to overworld, then overworld to end portal fast) since some of the crashes were occurring under those conditions, but we have also been getting crashes throughout normal gameplay, when performing normal actions such as placing blocks or even walking around. The crashes occur in multiple areas, overworld, nether, and end. There doesn't seem to be a specific chunk or groups of chunks causing this since the same areas may be fine one moment, then crash at another. As of now the server will crash at least 4-5 times a day if people are active. Checking memory usage showed a steady usage of around 700MB our of the 3GB allocated, so there doesn't seem to be any issue there.
Crash reports are fairly limited in information, but here are some of them:
CrashReporter Key: 8c4937c1-64cb-3532-a8dc-1deb28f67293
Crash
[2022-08-18 21:19:27:947 INFO] at clone (UnknownFile:?)[2022-08-22 01:26:19:319 INFO] at clone (UnknownFile:?)
[2022-08-11 15:46:43:396 INFO] at clone (UnknownFile:?)
This is the most verbose one we managed to get:
[2022-08-11 14:58:04:885 INFO] Package: com.mojang.minecraft.dedicatedserver
Version: 1.19.20.02
OS: Linux
Server start: 2022-08-11 00:18:58 UTC
Dmp timestamp: 2022-08-11 14:58:04 UTC
Upload Date: 2022-08-11 14:58:04 UTC
Session ID: f56e352f-fa47-405d-a38f-f0ea09422adc
Commit hash: 1aa76c5813541fe1bbb16c4e3a0af2b29474dc34
Build id: 10811062
CrashReporter Key: 8c4937c1-64cb-3532-a8dc-1deb28f67293Crash
[2022-08-11 14:58:04:885 INFO] at clone (UnknownFile:?)
dd62e092-4219-4cc3-b64c-90de895b1b67DEBU[52747] Forwarding signal signal="child exited"
ERRO[52747] Failed to signal sub-command error="os: process already finished"
Edit: Added more crash logs. Info is still seemingly vague.Themost reliable crashes seem to be from going through portals. To trigger, first load the world on a server (NOT single player), then go from spawn to the nether, from the nether to the end portal station, through to the end, then back to spawn. Repeat a few times and you should eventually crash.
Edit 2: Made the bug public and removed the world file since I confirmed the memory leak occurs with a fresh world.
Server is running mostly default survival settings except for simulation distance of 6 and chunk render distance of 32. Has been stable for the past year without issue until around 1 month ago. At first we believed the crashes to be caused by entering portals too quickly (going from nether to overworld, then overworld to end portal fast) since some of the crashes were occurring under those conditions, but we have also been getting crashes throughout normal gameplay, when performing normal actions such as placing blocks or even walking around. The crashes occur in multiple areas, overworld, nether, and end. There doesn't seem to be a specific chunk or groups of chunks causing this since the same areas may be fine one moment, then crash at another. As of now the server will crash at least 4-5 times a day if people are active. Checking memory usage showed a steady usage of around 700MB our of the 3GB allocated, so there doesn't seem to be any issue there.Made the bug public and removed the world file since I confirmed the memory leak occurs with a fresh world. Also adding some extra info from my comments below:
After further testing this seems to be a memory leak related to chunk loading. If you check the memory while standing still, not loading chunks, it should be stable. When you load chunks, whether it's via crossing portals, flying, etc. the memory use should increase and not come back down. Running farms while standing still did not affect the memory usage for us. Passive mob farms, redstone mechanisms, etc. did not contribute to the memory leak. Here's a log of our memory use up until the server crashed again.
Crash reports are fairly limited in information, but here are some of them attached below.
Multiple Server Crashes due to Memory Leak
Server is running mostly default survival settings except for simulation distance of 6 and chunk render distance of 32. Has been stable for the past year without issue until around 1 month ago. At first we believed the crashes to be caused by entering portals too quickly (going from nether to overworld, then overworld to end portal fast) since some of the crashes were occurring under those conditions, but we have also been getting crashes throughout normal gameplay, when performing normal actions such as placing blocks or even walking around. The crashes occur in multiple areas, overworld, nether, and end. There doesn't seem to be a specific chunk or groups of chunks causing this since the same areas may be fine one moment, then crash at another. As of now the server will crash at least 4-5 times a day if people are active. Checking memory usage showed a steady usage of around 700MB our of the 3GB allocated, so there doesn't seem to be any issue there.Made the bug public and removed the world file since I confirmed the memory leak occurs with a fresh world. Also adding some extra info from my comments below:
After further testing this seems to be a memory leak related to chunk loading. If you check the memory while standing still, not loading chunks, it should be stable. When you load chunks, whether it's via crossing portals, flying, etc. the memory use
shouldincrease and not come back down. Running farms while standing still did not affect the memory usage for us. Passive mob farms, redstone mechanisms, etc. did not contribute to the memory leak. Here's a log of our memory use up until the server crashed again.Crash reports are fairly limited in information, but here are some of them attached below.
Server is running mostly default survival settings except for simulation distance of 6 and chunk render distance of 32. Has been stable for the past year without issue until around 1 month ago. At first we believed the crashes to be caused by entering portals too quickly (going from nether to overworld, then overworld to end portal fast) since some of the crashes were occurring under those conditions, but we have also been getting crashes throughout normal gameplay, when performing normal actions such as placing blocks or even walking around. The crashes occur in multiple areas, overworld, nether, and end. There doesn't seem to be a specific chunk or groups of chunks causing this since the same areas may be fine one moment, then crash at another. As of now the server will crash at least 4-5 times a day if people are active. Checking memory usage showed a steady usage of around 700MB our of the 3GB allocated, so there doesn't seem to be any issue there.Made the bug public and removed the world file since I confirmed the memory leak occurs with a fresh world. Also adding some extra info from my comments below:
After further testing this seems to be a memory leak related to chunk loading. If you check the memory while standing still, not loading chunks, it should be stable. When you load chunks, whether it's via crossing portals, flying, etc. the memory use increases and not come back down, which it should not be doing. Running farms while standing still did not affect the memory usage for us. Passive mob farms, redstone mechanisms, etc. did not contribute to the memory leak. Here's a log of our memory use up until the server crashed again.
Crash reports are fairly limited in information, but here are some of them attached below.
MaladjustedPlatypus, the 1.2.10.2 release seems to have been based off a different development branch than the 1.2.10.1 beta build, so some of the fixes/changes in that beta will likely show up again in 1.2.11. Until then, I'll reopen this issue.
Headless piston issue is still present in 1.0.3. I'm not entirely sure how to reproduce. Powering it does nothing, moving it still crashes the game. See attached screenshot for proof. http://imgur.com/a/K2gyP
Edit: should the headless piston be filed as it's own bug?
Copying my post from the subreddit:
It is actually possible to instamine on Win10 via a bug. Imagine you're digging a 1x2 straight tunnel forward. If the regular instamining conditions apply (sometimes even without them) and you aim your pick towards to upper edge of the lower block, it'll be instamined. If you aim towards the lower edge of the upper block, it'll be instamined. Mix the two so your cursor is exactly positioned near the lower edge of the top one and you can instamine a 1x2 tunnel even while sprinting. There are instamining angles when facing blocks above you as well. Not sure about below.
Affects version 1.0.9.
To Ryan, the fact that an item becomes an entity during the transition has nothing to do with it as tnt should also destroy any entities in the blast radius. Java Minecraft behavior results in moving items being destroyed.
I am aware of the drop rate. I can blow up hundreds of blocks and still have no drops. Were you able to get drops? I have tested this in several new worlds with nothing changed from the default settings. If the gamerule needs to be manually set, that behavior is bugged.
Edit: Video for proof. Not a single block drops. https://streamable.com/ibxnj
To expand upon this. Helen mentioned that, as of the current public update, even survival drops are not working as intended. The behavior was originally as per the description, but no longer. There is also supposedly a fix for 1.2, so at the very least it is being addressed.
Happens with other tree types. Fallen trees generate from saplings, including saplings grown with bonemeal. Doesn't make sense for a tree to instantly grow into a fallen tree.
Fixed in the latest 1.2 beta.
Still affecting Beta 1.2 Build 5
Fixed in 1.2 Build 5
I've tried to replicate this several times and simply cannot reproduce it. I even tried filling 40 sets of 100x100 walls with redstone torches then reloading reveral times. Since 1.2 Build 5 none are falling.
As of 1.2 Build 5 the stairs are not rotating when pushed by pistons, as show here. Stairs Fixed.mp4
Atm the MCPE observers seem to have 0 delay when detecting other observers. This results in the redstone dust being pulse so often it is essentially always on.
I tested it in the 1.2 beta and was unable to reproduce, even on chunk borders.
Cannot reproduce in 1.2 Build 5.
Cannot reproduce in 1.2 Build 5 with neither heavy nor light weighted plates.
Confirmed to happen in 1.2 Build 5.
The issue with your example is that redstone devices are ticked randomly, not in order of propagation like Java. As of now it is a feature and unrelated to the observer itself.
Cannot reproduce in 1.2 Build 5
Works as of 1.2 Build 5.
Isn't 1.2.0.15 Beta 1.2 Build 5? If so, selecting that version would be incorrect. At the time of posting the bug report I did not see any option for beta 1.2 Build 6.
It is intended for them to generate naturally, not from bonemeal
This bug still affects 1.2.0.25. However, it is now partially functional. Adjacent glazed terracotta blocks are still pushed by slime blocks, but they are no longer pulled by them. Attached a video to demonstrate. MCPE Glazed Terracota Bug.mp4
Yes, seems the devs created a condition where they could universally be pushed so long as the piston head was pushing in order to allow them to be pushed directly by slime blocks, but that had the unintended side effect of "pushing" the blocks when they should not be.
Have you tried removing the torches? The cart could be clipping into them.
^ Still occurring in 1.2.1.1. How did you test this?
Appears to be fixed as of Beta 1.2.5 Build 2
It seems this issue, besides crashing, also results in pistons breaking each other (they drop the item, not just deletion), and pistons getting transformed into smooth stone. Basically, when multiple pistons are interacting, like double/triple extenders, and the timings are too short such that the pistons' behavior is affected by the random update order, issues begin to arise. Originally when a piston timing was affected by random tick order it would either work or not work. Now it either breaks the piston, turns it into stone, or crashes.
Affects 1.2.5.15, but requires different timings to trigger (due to the slower observers).
Still occuring as of 1.2.5.15 in worlds whose default gamemode is creative.
Still affecting Beta 1.2.5 Build 3
This had been fixed in 1.2 with the instant observers. As of 1.2.5 Beta 3 (1.2.5.15) observers have been slowed down (from the changelog, it seems it was to fix
MCPE-23947) and this issue is occurring again.Cannot reproduce as of 1.2.5.15
Cannot reproduce as of 1.2.5.15
Works as intended. The ticking range is limited such that non-pure-redstone components (dust, repeaters, comparators) will not receive updates unless they are within the ticking range.
Affects 1.2.5.15 (1.2.5 Beta Build 3).
In the end dimension, endermen are spawning in high light levels and in non-solid blocks (carpet over string, over a block, they spawn trough the carpets). Affects 1.2.5.15
Re-tested. Does not seem to be affecting 1.2.5 Beta Build 3
Is the looping an internal confirmation or did a dev mention it somewhere?
Interestingly enough the randomness itself does not seem to be intended, at least not permanently. The devs themselves have mentioned that the random order is only to prevent players growing accustomed to a broken system until they can establish a proper order method.
It can delete anything (bedrock included) and in some cases transmute pistons into various stone types
As the 'Minecraft 12_6_2017 4_15_38 PM.png' image shows, this is fixed for certain orientations, but not all.
Confirmed to be fully fixed using my previous test cases.
I'm noticing that this bug is not reliable. After some time the ones that always crashed no longer do and some that did not crash do.
Edit: Okay it is reliable, but has an interesting property. If you build ONE of these at a time and trigger then as you build them, you can reliably trigger the crash. However, if you build the setup, then trigger some normal non-crashing setups near it (to update the region, so to speak) the setup does not crash.
This fix has broken parity with Java. Before, mobs could and should have spawned on top slabs as it was a solid flush spawning surface for them. Now, mobs no longer spawn on top slabs. A proper fix would be mobs not spawning on bottom slabs, but spawning on top slabs.
Uploaded example screenshot. A single solid block under is enough.
Odd... Perhaps the fix was reverted from the beta? That exact test case was fixed in it (the beta).
This is still occurring as of 1.2.10
That would be a separate bug, redstone powering blocks it should not be powering.
Can we get some explanation as to why this was marked "works as intended"? In the Discord Helen herself said that it was a bug and that rock (another dev) confirmed it as such.
As far as I'm aware this bug is no longer present in the latest stable release.
Affects 1.6.0
Affects 1.6.0
Source? ^
I don't think this is related to
BDS-17453since there is a permissions.json file present. Either way the server crashes are not on startup, they're after some time playing, which can vary dramatically, not sure if that's relevant to the script-watchdog setting.Attached here is the server properties file. Not sure what would cause an issue there, thought it might be outdated since I do not see a script-watchdog setting.
server.properties
Sorry for the duplicate comment, can't seem to add another attachment via editing existing comments. Here's a screenshot of the server directory. If anything I'm seeing more files than what is normally present so I'll back up the server files, download a fresh install and try again.
In a situation such as this where "parity" brings obvious negative consequences, why not alter Java to match Bedrock behavior instead? Allow Java raids to start during the victory celebration. Parity should seek to bring together the best elements from both codebases, not the worst.
After further testing this seems to be a memory leak related to chunk loading. If you check the memory while standing still, not loading chunks, it should be stable. When you load chunks, whether it's via crossing portals, flying, etc. the memory use should increase and not come back down. Running farms while standing still did not affect the memory usage for us. Passive mob farms, redstone mechanisms, etc. did not contribute to the memory leak. Here's a log of our memory use up until the server crashed again. syrupy_20220827204110.ps.log
Edit: Tested with a fresh world on the server, issue still persists.
The use of the word "should" is with regards to someone trying to reproduce the bug, not that said behavior is what one would expect in normal gameplay. If you were to test for the bug, that is what you "should" be seeing. I'll change the word to avoid any more grammar semantics unrelated to the bug.