Repeaters and comparators don't update non-solid blocks in front of them
Repeaters and comparators only give out block updates in case a solid block is in front of them.
Powering a dropper/dispenser or piston like in picture 1, which was possible in all previous versions, is no longer possible, because the dropper/dispenser/piston doesn't receive the information, that it is powered.
Powering only a single piston (picture 2) would be no longer possible without workarounds.
Placing a block in front of the repeater wouldn't work, because it activates both pistons (picture 3)
[Mojang] Grum (Erik Broes) added a comment - 2 hours ago - edited
This happened when we made the observers not be able to power the airblock in front of them and thus being able to power the observer line with a gaps in it.
Linked Issues
is cloned by1
MCPE-19852is duplicated by2
relates to3
MC-108Droppers, Dispensers and Pistons activate when blocks are providing power diagonally or two blocks aboveWorks As IntendedMC-109297Observer blocks don't detect repeaters and comparators powering/unpowering in front of them.DuplicateMC-109315Redstone torches, repeaters, comparators, dust and observers update non-solid blocks around/in front of them.Won't Fix
Created Issue:
Repeaters and comparators don't update non-solid blocks in front of them
Repeaters and comparators only give out block updates in case a solid block is in front of them.
Powering a dropper/dispenser or piston like in picture 1, which was possible in all previous versions, is no longer possible, because the dropper/dispenser/piston doesn't receive the information, that it is powered.
Powering only a single piston (picture 2) would be no longer possible without workarounds.
Placing a block in front of the repeater wouldn't work, because it activates both pistons (picture 3)
Attachments3
is duplicated by
Repeaters and comparators only give out block updates in case a solid block is in front of them.
Powering a dropper/dispenser or piston like in picture 1, which was possible in all previous versions, is no longer possible, because the dropper/dispenser/piston doesn't receive the information, that it is powered.
Powering only a single piston (picture 2) would be no longer possible without workarounds.
Placing a block in front of the repeater wouldn't work, because it activates both pistons (picture 3)
[Mojang] Grum (Erik Broes) added a comment - 2 hours ago - edited
This happened when we made the observers not be able to power the airblock in front of them and thus being able to power the observer line with a gaps in it.
is duplicated by
relates to
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
[Mojang] Grum (Erik Broes)![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
is cloned by
Its just like MC-109266 and this should be like this, i know it says now that it works like intended, but MOJANG promised to not change the way redstone is working so far, only to add the observer. right now you are changing redstone big time, plz dont do this cause it is breaking everything and is becomming only more buggy, plz change it back so that the repeater can give block updates to air. cause your breaking the normal BUD in the game.
:'(
Plz listen to the redstone community
The bug
A repeater, comparator or observer will not update the block in front of it if that block is non-solid. This provides another way of quasi-powering pistons.
To mods
Even if MC-109266 is WAI this is still a bug as the piston actually receives power. If Mojang do not want power going through non-solid blocks they should not actually allow those blocks to be powered which would require fixing MC-108.
I am pretty sure that is incorrect. In 16w43a a repeator facing into an air (or other non solid block) will power the air block, just as before. However what has been "fixed" in MC-109266 is that the air block no longer updates the surrounding blocks to let them know it is powered.
You can test it is powered by manually updating the surrouding blocks while the air block is powered.
This was clearly demonstrated in the later parts of this video: https://www.youtube.com/watch?v=2Sqxs2wQmP0
bob, that is terrible logic. If we assume that all behaviour in previous versions of the game is intended behaviour, then why report any bugs at all and why would MC-109266 be WAI, since that is a change from the last version.
This releates to MC-109266, but is a duplicate of MC-107664. You were never able to detect the change of repeater/comparator on/off states.
Proof done in 16w41a: https://gfycat.com/SnarlingKaleidoscopicCattle
It only seemed like this is possible in a line of repeaters/comparators, because the repeater updated the block in front of him. Since 16w43a repeaters/comparators only update solid-blocks, which another repeater/comparator isn't.
If you treat this is a seperate issue, you're missing the point.
That they powered air blocks was a bug.
They don't power air blocks. They give out block updates. The repeater still powers the piston, but the piston doesn't receive the information anymore. Please try to understand the situation before commenting. You do this every time.
I don't see how this works as intended. Changing the mechanic doesn't contribute to consistency or less confusion at all. The only thing it achieves is breaking things.
im counting the contraptions that will break due to this senseless change.... cya in 1.13
I meant giving air blocks a block update, sorry, my bad, but that doesn't change the fact that that was a bug that is now fixed.
blocks that give strong power were always updating up to two blocks away (like repeaters), and weak power ( for instance redstone blocks) - one block away. That's how pistons were informed of a change. The rule was simple. Now it seems that devs try to make complex rules what can and what would not update in which situation. This doesn't seem like a great idea (complicating things, rather then simplifying).
is it still a "fix" if countless contraptions will be broken due to it? its not like we had that behaviour for 1 snapshot.... its in the game for years now and a part of qc wich was said it wont be taken out?
This happened when we made the observers not be able to power the airblock in front of them and thus being able to power the observer line with a gaps in it.
so its not working as intended?
Well, there is still some buggy behaviour though (piston staying extended although there is no signal): Video (Edit: Link removed)
I don't think that's intended.
SunCat That's Quazi Connectivity.
Jack if it wasn't intended, he'd have reopened it.
I guess you meant me?
I don't think that's what you call quasi connectivity. There wasn't even any redstone component (other than the piston) in my world after I removed the repeater and the redstone block.
Even if it was Quasi Connectivity, it's a new kind of Quasi Connectivity which wasn't there in 1.10.2.
But I think that would be worth a new ticket.
Yes sorry, meant you.
And that is caused by QC.
@violine if a repeater not updating the airblocks infront of it when powered is WAI why would it be buggy behaviour the other way around?
anyway as grum said this got changed bc of observers wich are in the game since 3 snapshots, totally worth breaking countless contraptions that always worked
Mojang plz dont change old redstone features, you promised not to do so at minecon, so why
just make it so that repeaters still give block updates, but that it doesn't effect the observer, cause this is giving way more bugs than it solves, at least make it so that a repeater powers a piston if placed towards the piston and one block higher than the piston itself, cause now we can't power 2 pistons on top of each other separately
It makes no sense for a block that is suppose to give out updates, to do so only when there's a solid block in front. All redstone components powering strong signal have updated 2 blocks away, and did this regardless of the nearby blocks. I was under the impression that recent redstone changes were /intended/ to make redstone more consistent. I can't think of a worse inconsistency than components behaving differently because of the block in front, despite still giving power. If inconsistencies are considered bugs (which is what a lot of mods here say), then this definitely qualifies as a bug.
If the purpose of this change was to prevent observer chains with gaps in between, then make observers update only when there is a block state change. This fixes the issue above, while still allowing observers to detect other changes, like RS dust power level change, rail state, chests etc..
The bug report was closed in less than 1 minute, and this only shows that the mods put no thought into evaluating the validity of the report at all. On top of that, I don't see how mods can decide intended behaviour from non-intended behaviour when it wasn't on the changelog. This case needs to be reopened and properly reviewed.
We mods have contact with the devs, and a dev also comented here that this is intended (I actually asked him to comment).
As the repeaters/comparators and observers updating was changed in snapshot 16w43a, this bug was introduced. The reason for it happening, is because of the fact that repeaters, comparators or observers will no longer update blocks with a "manhatten" distance of 2, if there is not a solid block in front of the repeater/comparator/observer. This is against previous intended behaviour, and is thought of as a bug from almost all users of it.
Knowing that this "fixes" other bugs (in very bad ways), it will create a lot of edge cases, where the behaviour of updates from repeaters has changed, where the powering itself stays the same. This means, that some components wont update, in vital situations. Also - you mods shouldn't evaluate bugs, which you do not understand properly. There are people, who've studied the code, who would be more suitable for this evaluation, thanks. Also some of the developers get features mixed up, which is true in this case. - updating is not the same as powering.
yes and his comment basicly said: we broke old consistant behaviour on prupose to fix behaviour of a new block... search and show me the sense of that!
The issue is that the repeater still powers the piston below the block in front of it. If you are going to remove the block update, you should also remove the piston being powered. I would consider that an even bigger bug. I don't want it to happen, but if you are going to break your promise, then just rewrite redstone properly and stop beating around the bush. The observers were meant to detect block updates. What block updates are were well understood by people using them. However, it seems you are deadset on confusing everyone for the sake of new players. However, new players are going to confused as much as everyone else because the tutorials they look up will simply no longer be working. We're talking a number of tutorials that were made over many many years. I understand you want consistency but I think what you are doing is making the underlying issue even worse.
I understand the change in case of the observer, but I don't see where it makes sense for pistons. It seems very confusing and inconsistent that repeaters and comperators still power pistons through air blocks, but pistons don't get updated unless updates on them are forced by other means (like placing a block, running redstone next to it, ...).
I don't mind old redstone contraptions breaking due to feature changes as it's fun to design new contraptions, but it's frustrating if the entire system loses its consistency to a point where it doesn't make sense anymore, at least in my and some others mind.
To the devs: I don't blame you if you keep this change as it is, but I'd still be happy seeing some rethinking of this.
Everybody, this is a bug tracker and not a forum, for further discussion please go to the mojira reddit.
You clearly do not read the comments.
I did read them, and discussion = discussion, please go to the reddit.
Well - if you did, you'd know that it isn't the air block not being powered.. In fact the air block in front still behaves, as it always has. If you were to manually update one of the pistons, when the repeater is powered, it would stay on, if you deactivate the repeater. The original "fix" was related to observers, not repeaters (and not only with air, but all unsolid blocks). Thanks.
The behaviour you describe in that comment is caused by Quasi Connectivity.
Negative. And Quasi Connectivity works as intended, so that's a very bad example, and thus not a valid argument.
I hate to be that guy but this comment section is for a reason. If you don't believe that a discussion concerning the reported issue is a valid reason, then the comment section should just be removed/disabled all together. On top of that, some users have no interest in using reddit. That's all I'm going to say on the matter because this discussion really does not belong here but I do believe it had to be said.
The comment section is for providing usefull information (facts too) concerning the ticket, discussions are not of use to the ticket itself.
I'm in fact providing information - yes Quasi Connectivity has everything to do with this, but it isn't why the issue is happening. Either way there is a bug regarding this ticket, and that should be respected. Extending the layer of budding even more was previously not a thing and will therefore confuse many who're used to the normal behaviour of repeaters. This ticket will keep popping up, so it's better to look at it now and resolve it with multiple viewpoints.
I don't know how much clearer we can say this: This report was incorrectly "resolved". We were trying to prove that this is indeed a bug, and should be fixed. Things are starting to lose focus because we have to keep repeating ourselves to an inexperienced redstoner, who does not seem to understand the difference between block updates and powered blocks.
I'll explain it again in simple words so there is no confusion.
The 3 images on the OP show repeater/comparator "powering" the block above a piston. The fact that the piston is getting powered is QUASI-CONNECTIVITY. When the piston does not immediately react to that power, the piston is said to have received no UPDATE.
Redstone components UPDATE up to 2 blocks away in taxicab distance (aka manhattan distance)
All redstone components power AND update in a consistent way regardless of the adjacent blocks.
Because a repeater strongly POWERS the space above the piston, the piston is powered by QC.
Repeaters and comparators /should/ UPDATE 2 blocks away (taxicab distance) like the rest of the RS commponents, like RS torch and dust.
The POWERED space is above the piston, and the source of power is within 2 blocks from the piston. Therefore, the piston /should/ receive an UPDATE. When the piston receives an UPDATE, it will check for POWER and react to it appropriately.
The bug is that repeaters and comparators (and only these 2) do not cause UPDATE consistently, depending on the adjacent blocks. This is a major inconsistency, and as many bug tracker mods said, inconsistency should be regarded as a bug.
Was that clear enough? We have been providing important evidence and reasoning that contributes to the report, so disregarding it as "discussions" is either not understanding it, or intentionally ignoring it. If you are too inexperienced in the field in the bug report, please just leave it be for another mod, and don't make baseless assumptions.
I understand what was intended by the introduction of this, but it was done in completely the wrong way.
How it should've been done: Repeater doesn't power non-solid blocks, and shouldn't update them either.
How it actually was done: Repeater does power non-solid blocks but doesn't update them.
Proposed fix: disable repeaters from powering non-solid blocks, and keep the change regarding block updates.
Note: this proposed fix will still probably annoy many redstoners, myself included, but it seems like a significantly more logical solution.
Alternative solution: Allow the repeater to update the piston itself directly.
This just adds inconstancy to the game, if repeaters don't give block updates, then why can you do this with a redstone torch or redstone dust?
I hope that this gets reopened and fixed.
Agreed that is is introducing a large inconsistency amount redstone components and breaking a large number of contraptions that have worked for many years.
Why would ANY component not update a block that it is powering, regardless of whether the powered block is solid?
IMO this introduces much more strange behaviour than it resolves. It is also important to point out that other components like torches and dust still provide updates, it is only the repeater, comparitor and observer that do not.
I am honestly shocked this has not been more rapidly recognised as breaking years worth of redstone contraptions and introducing confusing strange mechanics.
This is a separate issue from observers updating air blocks. Although i do feel that they should update blocks they power, it is much more serious when the change effects other components that have been in the game for many years.
It's way too late to fix that issue, Mojang should have left it like it was before. It's never a good thing when the fix doesn't allow as much possibilities as the old one.
I get why many people are upset that this issue was resolved as WAI, but I will try to explain why.
I'm trying to structure the post strictly logical, so if you disagree with anything you can hopefully put your finger on it.
Grum stated several times that air blocks (non-solid blocks) should not pass on power.
No matter if you like this or not, if you see it was an axiom of redstone it makes the resolution to WAI understandable.
Block updates are not a game mechanic, but a technical way to make surrounding blocks aware of changes.
I don't have a Dev-source on that, but if you accept that this is the intention behind block updates (which I believe is the case) then we can draw some conclusions from it.
The only change caused on surrounding blocks when triggering a repeater/comparator is the provided power.
Trivial, but necessary to connect axiom 1 and 2.
If power is the only change caused by repeaters/comparators (Axiom 3) and non-solid blocks do not pass on power (Axiom 1), then non-solid blocks do not change when powered by repeaters/comparators.
If non-solid blocks do not change when powered by repeaters/comparators (Conclusion 1) and the only reason for block updates is to make surrounding blocks aware of changes (Axiom 2), then there is no reason for non-solid blocks to pass on updates.
So the described behavior "Repeaters and comparators don't update non-solid blocks in front of them" is in fact as intended.
But there is something wrong here:
As seen here repeaters in fact still provide power to the non-solid block in front.
Given Fact 1, Axiom 1 is violated here, so there is in fact a bug.
However, this is not the bug described in the title of this issue (Conclusion 2). It is an related, well known issue (
MC-108).That said, I'm not interested to discuss here whether QC should be fixed or not. That is a whole other discussion. This post is simply to explain why, given a set of simple starting points, this issue is WAI.
If you disagree with any of my axioms or conclusions please let me know which one.
As some people pointed out that torches and redstone wire do still cause unneeded updates and that this is inconsistent with this change I want to add:
Yes, you are right. But it's very likely torches and redstone wire just didn't get fixed yet. Especially the recoding of redstone wire takes a lot of time and effort.
For further discussion please use this reddit post.
"We mods have contact with the devs, and a dev also comented here that this is intended (I actually asked him to comment)." See comment above
Actually, Grum didn't say this worked as intended, he only stated that this behavior was introduced when they "fixed" the observer block updating air blocks.
[~paquetteantoine@gmail.com] Don't blame the messenger. Read my other post for further insides on why this change was made
I understand your post and I see why this is 'almost' working as intended, but I was just trying to clarify the situation that for the java coded game, this new behavior needs to be considered as a bug, otherwise, as you say in your post, the entire redstone code needs to be reworked.
Very well put, panda. Assuming your axiom's are all correct, I can understand that perspective. It would be nice if the devs could provide a bit more feedback as to why this is considered working as intended, so that we can better challenge or accept their position.
I personally feel like making these sorts of changes without fixing QC leads to even more confusion, especially if it is not done consistently across all redstone components.
WAI?
https://www.youtube.com/watch?v=eeS_dn0QwWo
Dale Ehrhart if you read[Mojang] Panda's comment, you'd know that that is caused by a combination of QC and a block update because air still updates air blocks, which will be changed eventually too.
@Panda. You're just nitpicking.
Let me do the same thing you just did:
I can also create an arbitrary axiom, that would be violated.
If I put a piston in front of the repeater, which updates the bottom piston, the conclusion would be that a piston does conduct power.
But you would only get this impression by disregarding how QC works.
Your arbitrary axioms are just an attempt to justify one specific issue in disregard of the WAI quasi-connectivity. Axiom 1 already conflicts with the WAI quasiconnectivity. Axiom 2 isn't even an axiom, but a design guideline. Axiom 3 conflicts with the way things work at the moment. The piston still gets powered, but doesn't receive the information.
Psst guys! I posted the inverse of this bug, taking the changes as intended.
MC-109315andMC-109316. If Mojang make these changes, they should at least finish them.ilmango There's a Redditpost on Mojira for further discussions.
But as you brought up QC and insist on it being WaI, I have to get this straight here before even more people blindly believe this and hold onto that hope forever:
I don't know how many times I already said this, but I will continue to do so:
Any bug - and that includes QC - can get fixed at any time, sometimes not even intentionally just as some "side effect" of fixing other bugs, so personally I wouldn't bet that QC stays in the game forever, at least not as bug, as they want to fix all bugs, and that includes also QC of course.
So even if they'd continue to declare QC as "WaI" (which was just a temporary thing from how I understood the discussants, Microsoft as well as Mojang) it might be that it gets fixed over time anyway automatically.
QC as a "clean" feature* is another thing, but given feature parity across all platforms doubtable.
I play this game since 6 years and Minecraft changed a lot throughout the versions. And no matter if I personally like some changes (and, no, some I don't like at all):
It is close to impossible for a vivid game like this to stay the same for so many years, even more so given the circumstances, new players, new owner, the other platforms and future plans.
My personal stance is: If I don't like 1.11 or 1.12, I'll just play in an older version (at least Survival; Creative is awesome).
So either adapt, or play an old version you like, or stop playing.
There'd be another thing one could do, but that'd afford a lot of time, maturity, flexibility, diplomacy, amicability, perseverance, and most people who don't like changes and close up completely against valid counter-arguments usually lack in some or all of them.
In my opinion the repeater should either power the piston or not, but powering it without sending a block update makes no sense
@SkillHax123
MC-108is the report for that issue.@bob uhh, no it isnt. Im talking about repeaters powering pistons from above like in this bug
I completely agree with SkillHax123; when the redstone repeater no longer gives an update like demonstrated in this report, then it only makes sense that the repeater would also not be able to power the items it does not update.
That IS
MC-108, all that was changed is that it no longer updated non solid blocks, as such the piston receives no update and doesn't check if it's powered, againMC-108.MC-108is very similar, but it is about pistons, etc, receiving *diagonal* power *and* not always getting updates.This bug is about transparent blocks being powered *but no longer* giving out updates when powered by *some* redstone components.
This is what this ticket is about, and is an intended change. That the piston is still powered, but not updated is
MC-108.MC 108 is about pistons, and where they can recieve power from. This bug is about the components that power the pistons, and when they send block updates. I feel like removing repeaters sending block updates when there are no solid blocks in front of them makes sense, but if that is changed, then pistons should no longer be able to be powered this way.
Third time, that is
MC-108, not this ticket.Did you even read what I just wrote
Why do pleople keep asking that? :|
Yes I did, and your request is requesting to fix
MC-108.No im not asking for quasi conductivity to be fixed, im asking for pistons in this very situation pictured above to either be powered and updated or not powered
That they are powered is because of
MC-108, and this ticket is indended, that the block update got removed for non-solid blocks is an intended change.If you want the "old" behaviour, place redstone wire on a upside down slab instead of a repeater on a block.
Is the piston being powered diagonally or from 2 blocks above? No, this is not because of MC 108
Look at the image in the description of
MC-108, the orange wool is the repeater in this case. It ISMC-108there's no denying that.MC108 applies to blocks providing power, not repeaters. The repeater itself is not powered, it powers the block in front of it
It is quasiconnectivity. The repeater gives power from the side of the repeater to the block in front of it. The piston checks for power from that side in the block above it, thus receiving power from the repeater. It's not diagonal in the normal sense, but it's diagonal from the internal sense. It makes sense if you look at the way that quasiconnectivity occurs in the code. Even though it used to be a well-defined behavior where there was always an update and that many machines relied upon, it was quasiconnective power.
The powering is quasiconnective, and this change (where there is no longer an update where there was one) is what causes it to no longer be updated. And, for better or worse, the removal of the update was intended.
Thank you. Sanity returns I see. It's funny how dressing up quasi like this suddenly makes people hate it. "What do you mean, power doesn't synchronise with updates?" Also I'm pretty sure the actual definition of quasiconnectivity is when a component is powered but does not receive an update.
Still doesn't explain why introducing *more* cases of QC is considered WAI
If you accept that QC is a 'won't fix' bug, you have to make it consistent. This used to be an exception to buggy behaviour. This does throw up some interesting questions about whether it would be better to just fix QC completely though.
To maybe put these arguments on hold - at least for right now. Grum himself stated that repeaters are broken - see
MC-109297. To my mind, comparators are too; but for now I am going to wait and see what happens whenMC-109297is fixed.you guys promised not to remove quasiconnectivity, but right now you are removing it. plz listen to the redstone community. you can check the wiki for the definition of quasiconnectivity for if you think you aren't removing it.
It should be obvious at this point that an overwhelming majority of the people in the community that actually understand this change oppose it strongly. I hope that you are swayed by public opinion as you have listened to the community multiple times in the past.
Updates have always been the very basis of not just redstone but the entire block paradigm of minecraft, and for many people manipulation of updates and their order is an integral part of playing with redstone. It has always been the case that components can and do give out updates separately from power. The simplest example is: a redstone line that stretches NS or WE will still update blocks not only next to itself (even though it doesn't point there) but 2 blocks away in ALL directions. The same applies for torches, repeaters, comparators, and now observers: if they CAN power 2 blocks away through a solid block then they MUST give out updates to those blocks independently of whether something is in front of them or not. The ONLY exception to this rule is QC and
MC-108has been confirmed WAI and the devs promised not to remove it because about half the redstone community would stop playing immediately if they did. Summary: power is simply a separate mechanic from updates, and changing anything about the update system of minecraft is a ridiculous idea in the first place. It would break EVERYTHING. An overhaul of the update system is something for minecraft 2.0 NOT something to be done behind our backs in a "bugfix" for something (MC-107730) that SHOULD have been WAI in the first place.This seems to be in direct conflict of the several times stated re-assurance that Quasi-connectivity, although a 'bug', would NOT be changed by the introduction of the Observer Block, yet the behavior has changed specifically due to an observer block behavioral change. Highly disappointing.