Repeaters and comparators don't update non-solid blocks in front of them

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.

@unknown That's Quazi Connectivity.

@unknown 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.

Axiom 1

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.

Axiom 2

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.

Axiom 3

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.

Conclusion 1

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.

Conclusion 2

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:

Fact 1

As seen here repeaters in fact still provide power to the non-solid block in front.

Conclusion 3

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.

@unknown 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

@unknown if you read@unknown'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.

• Pistons don't conduct power.

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-109315 and MC-109316. If Mojang make these changes, they should at least finish them.

@unknown 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-108 is 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, again MC-108.

MC-108 is 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.

all that was changed is that it no longer updated non solid blocks

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.

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 IS MC-108 there'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.