Zé Carlos
Assigned
Reported
Comments
Still happens in the last version.
I won't bother updating the information anymore.
Have a nice day.
So nothing's changed?
@Tim H
I don't think it's necessary to have a recipe for the BUD pistons at all. Usual survival players don't know of the BUD behaviour and expect a bugless piston. Bugless survival mode should be the goal to strive for after all. Those who use BUDs rather use it for mapmaking or experimental builds and would use the creative menu or the /give command to get the pistons anyway.
Never thought about it in that way, it seems like really good idea.
@William Pearson
Good work elaborating the images.
In your post, the gold/iron one seems interesting and I also like the redstone torch/redstone dust since the materials are similar because you just add a stick to the redstone.
If that idea is to be executed, why not just differentiate them with stone/cobblestone? They would also need to be visually distinguishable, so that way one would have a cobblestone cover and the other a smooth stone cover.
That way the materials would basically remain the same since stone is smelted cobblestone.
@William Pearson
lets just stop arguing, I don't want more inbox spam.
Nice way to tell someone to just be quiet because you have run out of arguments, also there's a "Stop watching this issue" link, if you are so worried about spam.
Although you are probably the one who comments the most and keeps coming back, even after your arguments are proven invalid.
@Alex Taffe
This comment section has just turned into a massive argument over nothing.
Agreed, with this, let's move on and try to think of solutions that will make both groups happy.
1. I think that fixing BUD behaviour and adding a bug-free BUD block would be the best option, in my opinion.
2. Spliting pistons with inverted recipes is nice idea but as the gamerule idea, I think keeping bugs like this in the game for backwards-compatibility would only let them grow even less stable.
But at this point, I think they just don't care anymore.
Yesterday I made 3 contraptions and for my amazement all of them had bugs. In 2 of them, the pistons became stuck because of a diagonal powered block (was able to solve it with half-slabs, but still...). In the last 1, got a piston that remained powered in upward position, in an edge detector clock I bult. But unlike the other 2 contraptions, there is no way to easily counteract this behavior.
I have also run across MC-16097 and 2 other diffrent bugs but won't report them because i'm losing the faith in this. Seriously, after wanting to make a decent contraption, yesterday, and finding bugs in almost everything makes me lose the interest in this.
But I would like to make one last appeal.
3. If they don't want fix it, ok, fine. But at very least try to find a way to fix the piston stuck in upward position behavior, because the only way to make it retract, is to replace the block above it.
happens in current version
@William Pearson
Just get used to it.
I see what you're trying to say, but to me that is an invalid argument. You could just say that about every other bug: "don't fix this bug, just get over it". I'm sure there are bugs some people love and some people hate, but despite that, keeping a known bug in the game is not right.
I stand by my points and have nothing else to say.
@William Pearson
I've been trying to use less pistons since I discovered this annoying bug that makes them unreliable and highly susceptible, but using as little pistons as possible means I still use them,
Pistons are useful and needed but I would really like be able to use them in my builds without any of those weird behaviours.
I was saying if you have some old designs that use this bug that there are ways around and just as compact and if that design is massive more of a reason to use them because of less lag.
And it would be a removal without a replacement.
what would be a removal without a replacement?
You want quasiconnectivity for t flip-flop but they can be done just about the same size or less.
I'd like you to point out designs that use quasiconnectivity and can't be done in any other way.
@William Pearson
I like to use as little pistons as possible in redstone builds because it can do quite a bit lag depending on the quantity and intensity.
Probably before repeater locks, and hoppers we didn't have means to work around, but now we have.
somethings break, some change, some are added.
That's just how things are.
Progress is good.
@Dirk Sohler
I’m pretty sure “the community” we’re talking about on here is only a few big redstoners with a lot of subscribers on Youtube. Most of the community either doesn’t care or wants the bug being fixed.
Couldn't have said any better.
@William Pearson
I have. There's many. It's hard to figure out which ones actualy are broken. So far, we have found 2 broken systems, one of which is the most common t-flipflop in the world, and will break 90% of all maps if broken. (That may be an exaduration, but it is a common design).
Just do a hopper t-flip flop
I would also like to vote against adding a gamerule. Utilizing gamerules for optional forward compatibility has never happened before, and if you do it once everyone will end up demanding it for everything.
Although I would like to see quasiconnectivity fixed, I have to agree with you that the community would end up demanding it for everything. But not fixing bugs because the community like them may just result in the same situation.
I think the gamerule would solve this and leave everyone happy.
that way people could test both effects and also people could gradually get to know the new mechanics.
that player build it in there world and turns the feature on. Then if they build something else from someone on youtube the requires the settings being off, it'll just create a gigantic mess because only one will work at a time.
Alex, that player would just have to create 2 diferent saves, one with gamerule and the without.
Created an issue regarding chikens falling through hoppers.
My only questions now are if Pistons push items through a half-slab roof relates to Practical Use: Hopper sucks items through half-slab regarding items passing through half-slabs?
Also if Pistons push items through a half-slab roof relates to Items travel backwards or get stuck in the gap of the piston arm regarding the way pistons push tems.
I wanted to avoid create duplicated/related issues.
My taughts on this matter are that this is a bug.
It makes redstone inconsistent.
I'd like to have proper working pistons and maybe a BUD block that would produce a redstone signal (like the button so it would have a cooldown) when it would have adjacent blocks updated.
I will gladly accept any and every challenge to show that builds can be done without this bug.
When Zombies grow up they start to decompose and lose the outer skin layer (Epidermis) so get more exposed to day light ^^
Updated. I thought that once a bug would be 'confirmed' it would remain on a check list until it would be 'fixed'.
In my previous comment, I may have a couple of individual bugs, but I'm unsure whether or not I should create individual issues for them.
I have discovered that this behavior of items passing through non-full blocks can actually be helpful, like in Practical Uses for example.
Although in that example i'm not sure that the eggs actually pass through the half-slab, or are sucked right away.
I would like someone to clarify what happens in this situation, please.
The half-slab on top of the hopper serves the purpose of avoiding chikens falling through the hopper, like in MC-25365
What would really need an improvement is the physics behind the Drops.
Sometimes, when a chicken is burned or a piston pushes a melon or a sugarcane, for example, the Drops get all over the place, it's like they explode!
Also, when pushed by a piston, Drops can sometimes travel backwards or get stuck in the gap of the piston arm, like in Gap Fall
Very explanatory images of the bug. Good work.
Still happens in 14w31a...