MC-133273Normal Pistons also spit out theire blocks with a short signal
Normal piston now also spit out theire blocks at short signals like sticky pistons.
1.12.2 - versions below
https://streamable.com/mn24v
1.13 - pre7
https://streamable.com/vfwlg
(The block arrives at its destination too early.)
Created Issue:
Normal Pistons also spit out theire blocks with a short signal
Normal piston now also spit out theire blocks at short signals like sticky pistons.
1.12.2 - versions below
https://streamable.com/mn24v
1.13 - pre7
https://streamable.com/vfwlg
Normal piston now also spit out theire blocks at short signals like sticky pistons.
1.12.2 - versions below
https://streamable.com/mn24v
1.13 - pre7
https://streamable.com/vfwlg(The block arrives at its destination too early.)
![[Mod] bemoty](../../../data/avatars/users/50554.png){kind=small}
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
2018-07-20_21.05.08.png
This is a simple contraption that shows the issue:
[^ Piston bug.zip]
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
This is a simple contraption that clearly shows the issue:
[^ Piston bug.zip]
I also used a resource pack to show which are normal pistons, and which is a sticky piston.
There is no "flag to drop the block", that's why it randomly broke in one snapshot and randomly came back in another. It is not intentionally implemented.
Grum also didn't "agree to restore the behaviour", it just happened when fixing other things. A direct quote from Grum from that report:
The piston dropping its block is not a feature. Nothing in the code supports it being a feature either, this is why when you do changes in other places in the code it suddenly stops working. The behavior from before the snapshot has been restored by fixing another bug (
MC-122711). Do not expect the piston-dropping-a-block to be in the game forever without changes. If you need to drop the block, push a glazed_terracotta, you can only push the block and not pull it.
Do you include 2 gametick pulses in "short pulses"? Because they are normal things and if you can build something with this that reproduces it, that's good.
I didn't say this report should blocker another, but the other way around. If you currently can't find an example to reproduce this because of another bug, it's "MC-?????? blocks MC-133273".
Can we now please get back from the meta level and actually talk about the main topic again? Please give me something that reproduces the bug properly. If you know what KrasserTyp built and can rebuild it (I can't do it from the video, because the website pauses weirdly), please attach a structure file of that and I'll look into it. It looked like it would reproduce this without using another bug, but I'm not sure.
This break a lots of my redstone contraption... Still in official 1.13
What exactly is the bug here? Regular pistons are supposed to not retract. I can see that the back-and-forth-contraption looks different visually, I would consider that a bug. But it shouldn't break any contraptions. Can you show something that actually behaves differently?
Previously, normal pistons when short pulsed would not cause the blocks they were pushing to be dropped immediately in the new position, the moving block would instead take as long as it normally would to arrive at its new location as if the piston had not been short pulsed. I don't know if the piston head itself immediately retracted though so can someone else weigh in on that part?
Please show me something that breaks with this change.
i dont have an example of breaking, but rather of making things more complicated
previosly you could chain a observer piston, and then a redstoneblock to create a delay equal to 5 gameticks
now when doing the same will result in a 4 gametick delay
also you could first stack a tower of pistons, then place redstoneblocks infront of them, thus quasi-powering every piston in this tower
when updating one piston every piston used to extend after 3 gameticks
in this version the pistons instandly spit out the blocks after 0 gameticks
https://streamable.com/i6l3o
I see
MC-108in that video, but nothing else. Please show me a redstone contraption that clearly behaves differently now than in 1.12 (for example light turns on in only one of the versions).I haven't tested it yet, so far I can say:
1. That the redstone block doesn't power the redstone next to it while moving is another bug: MC-123217
2. I see nothing powering the sticky piston.
It does behave diffrent
"Please show me a redstone contraption that clearly behaves differently now than in 1.12"
Sure
1.12.2 : https://streamable.com/t7i7l
1.13 : https://streamable.com/i4lv5
what happens in 1.12.2 - lower : one left side there are two repeater wich take 4 gameticks, the other side is a zero tick pulse generator chained to a normal piston
the zero tick generator takes 2 gameticks, pushing out the redstoneblock 3, thus taking 5 gameticks. the right piston extends first as its one gametick earlier
whatt happens in 1.13 : one left side there are two repeater wich take 4 gameticks, the other side is a zero tick pulse generator chained to a normal piston
the zero tick generator takes 2 gameticks, pushing out the redstoneblock 0, thus taking 2 gameticks. the left piston extends first as its 2 gametick earlier
(the slimeblock just resets the redstoneblock that gets pushed out)
is this good enough?
No, it's not. 0-ticks are a bug as well: MC-8328
It's such a shame that redstone is so broken that apparently not even good redstoners like you apparently are, even know anymore what's intended and what's not.
But can you please still try to give me an example that behaves differently now and does not rely on other bugs?
if a 0 gametick signal reaches the piston, itll spit it out after 0 gameticks instead of 3
if a 1 gametick signal reaches the piston, itll spit it out after 1 gameticks instead of 3
if a 2 gametick signal reaches the piston, itll spit it out after 2 gameticks instead of 3
same prinzip
but the 0 tick was the easiest to build
and yeah i knew 0 ticks were probably not intended
but i thought this is more or less an official part of the game, as it doesnt do any hard and adds a lot of extra content
Sticky pistons spitting out their blocks is a bug as well!
MC-122911You have basically now exhausted the list of commonly used redstone bugs, can you please give me a build that uses none and behaves differently in 1.12 and 1.13 due to what you describe?
so
I now build this using 1 gametick signals. im guessing they are intended
https://streamable.com/ndivg
https://streamable.com/nu4sy
the problem is that normal piston now have the same behavior as described in "122911"
Fine, I just added a different contraption that uses NO bugs
While this new behavior may break existing contraptions, it actually sounds to me like a potentially useful new feature. We can now have finer control over how long a regular piston takes to push. Old machines can be redesigned with repeaters to compensate. Think of the ways we could use that to make machines faster. With all of the complaints about redstone features being taken away, we should cherish the few new ones we get.
This is actually a loss of feature because we used sticky pistons to control the time of extension and normal pistons for fixed timing. Now we lost one of the options. This just makes normal pistons the same as sticky piston block dropping a glazed terracotta.
NewcomerMC, no you used MC-123217!
krassertyp, can you please upload a structure file of the contraption in your last set of videos? The website you're using is really bad for pausing at a specific time, so I can't rebuild it from that.
In an idealized and, most importantly, mutable, potential intended future state where 108, 8328, 123217, 122911, and all other bugs have been resolved or had suitable alternative mechanics implemented, then this bug might be irrelevant. If that's the case, then the code that causes this "block teleportation" would be redundant anyway. However, we're not in this ideal future state, and this change in behavior breaks many builds.
It was my understanding, and even my experience working with Grum on trying to maintain sticky piston block event ordering, that the devs were committed to not breaking builds and maintaining 1.12 behavior as much as possible. If that is still true, then this should be looked at. The fix is probably not difficult. It's probably just a case of wrapping the line of code that clears the block entity in an "if (isSticky)" statement.
What's even more notable is that the clearing of that block entity probably exists intentionally to maintain the behavior of 122911, which, if you recall, was restored based on the same commitment to maintaining compatibility and not breaking builds. Even though Grum really dislikes that bug, he went out of his way to preserve it for us. Please do the same here.
If something is only buggy due to another bug or can only be tested once the other bug is fixed, then the report gets marked as blocked by the other report. So when the other bug gets fixed, this one gets looked into again and the report stays open until then.
Since I don't even know what the real problem here is, can you please tell me which report should get marked as blocking this report?
I think I understand. Keeping track of all of these inter-related things is quite the task. In that case, fixing this bug would be the most correct behavior possible now. The "teleportation" that is in place now would be the bug. Allow me to explain.
That this happens with sticky pistons is one aspect of the 122911 bug. Technically, it could be coded so that the block drop in 122911 happens without the "teleportation" aspect, but the way it presents in the code is that the act of teleporting the block is what sets the flag to drop the block in 1.12. So, both behaviors have always been discussed together and never separately. Both behaviors were removed early in the snapshots for 1.13, but Grum agreed to restore both behaviors shortly after.
So, for a sticky piston when a redstone pulse is cut off before the extension completes the following happens:
In 1.12, a regular piston doesn't perform the last two steps. In 1.13, the 3rd step, however, is being performed. This is what breaks existing builds.
If all of the other mentioned bugs were fixed, then the case of what to do when a piston is "short pulsed" would simply never come up. The clearing of the piston head Block Entity can be considered a work around for this special case that can happen now, and it's the bare minimum needed to handle it. So, asking for an example of a behavior change that doesn't depend on short pulses is an impossible task.
Therefore, there's no reason for this to block any other bugs. Restoring 1.12 behavior, in this case, is not something that needs to be undone later down the line.
I hope that helps clarify.
There is no "flag to drop the block", that's why it randomly broke in one snapshot and randomly came back in another. It is not intentionally implemented.
Grum also didn't "agree to restore the behaviour", it just happened when fixing other things. A direct quote from Grum from that report:
Do you include 2 gametick pulses in "short pulses"? Because they are normal things and if you can build something with this that reproduces it, that's good.
I didn't say this report should blocker another, but the other way around. If you currently can't find an example to reproduce this because of another bug, it's "MC-?????? blocks
MC-133273".Can we now please get back from the meta level and actually talk about the main topic again? Please give me something that reproduces the bug properly. If you know what KrasserTyp built and can rebuild it (I can't do it from the video, because the website pauses weirdly), please attach a structure file of that and I'll look into it. It looked like it would reproduce this without using another bug, but I'm not sure.
well the webside works fine for me, but i can upload it directly ofcourse
and now i made a contraption that shows that 2 tick pulses also qualify
and if streamable doesnt work, and the vid is larger than tthe upload limit, ill give a download link
https://mega.nz/#!wO4WRCqA!N_y9zyLgFQYMs_p7GKqGIwV7gChk0e6U3aRHo8IZfcI
I'll check this out later today. Until then, can you please upload a structure file?
(Also, what's wrong with using YouTube? There I can pause on every frame and control playback speed.)
You don't have to upload a structure anymore, I was able to rebuild it from the video.
But all it shows is that the redstone dust sends updates before the lever does. I tried it in all directions. And it's the same in 1.13.
And the two observers on top are superfluous and the two observers in a row can each be just one.
Now can you please finally upload a structure file of a non-bugusing contraption that breaks due to this bug? First you uploaded a lot that are using bugs, then you uploaded one that might be valid, but to a website that pauses weirdly, so I can't reproduce it, then something that doesn't even reproduce the bug.
krassertyp, can you please upload a structure file for this video? https://streamable.com/ndivg
Or maybe something else that reproduces it properly?
I'm asking for the 9th time now, it's getting ridiculous. If you don't show how this is a bug in this or the next attempt, I'll ask a mod to close this report, because there's not enough information then to see what the problem is.
Seems to be fixed in 18w30a
[Mod] bemoty, since you set this ticket to "confirmed", can you please tell me what it's about? And can you provide a build that gets broken by this?