G4me4u

That is a good point, Lukas Fink (this comment). I think the primary concern was that you can get something similar to the chain bug, if you have a comparator chain facing into a single comparator on subtract mode. If you have a quick off-pulse through that chain, you would end up with the chain bug at the last comparator:

The concept of the solution to the chain bug is simple. The priority for any diode turning off must to be lower than or equal (meaning processed first) to the priority of any diode turning on in a chain. Thus, we had to change it to fix the abovementioned issue.

The dust shown in the video is actually not a 1 tick pulse. The dust is powered by the repeater through the block, however, the block is moved away by the piston in the same gametick (just later). So this pulse is what's known as a zero tick and the power persists logically and visually for less than a frame. This is not a valid bug.

Confirmed 20w07a

Yes, I can explain.

The bug has been around for so long that the change has to be made in such a way that it doesn't break things that are not directly related to this bug. Therefore the priority relations between all these setups should remain the same. This is very important to ensure when fixing this. The main fix for this issue is actually the first three lines of my comment (after "The following is the fix"). As I mentioned the bug is super simple to fix, but that doesn't mean that it wouldn't affect other stuff to use the simple solution. To ensure that no other setups got affected we had to consider the following setups that people are using:

1. A chain of repeaters or comparators that are pulsing quickly. This is what we are trying to fix as mentioned by the code above doing so is rather simple.

2. A comparator facing into a repeater should pulse if powered by observer. This is widely used in the tech community in their treefarms and other contraptions. To fix this we do the check "if (frontBlock != this) return true;" to ensure that it stays the same as in the previous versions.

3. Make sure it is only applied to repeaters and not comparator, comparator. The original intentions for this method is to fix directionality issues when locking a repeater. Hence only check for repeaters when doing the last check for direction.

All af the scenarios are fixed by that code, however..! It's not enough to just theorise about it. We tested a setup and realized that when having 2 repeaters in a row and a similar setup of a comparator followed by a repeater it was inconsistent with previous versions. Namely the 2 repeaters had the exact same priority as the comparator and repeater setup. Previously the priority was higher for the repeaters. This is caused by the comparator priority now overlapping the repeater priority in that setup. To fix this the only way to keep everything in 1-3 working was to increase the priority of the repeater (since priorities are negative this would mean decrementing that value by 1), which can be done without harm since nothing uses the same priorities except for that 1 instance as mentioned before.

All of this was considered when making that comment and stating the fix for the bug. It is important that all of the above considerations are made since they should not be affected by the fix. Thanks for reading 🙂

The solution to this problem is super simple and has been known for years now. Since then we have talked more technical and come up with an idea how a fix would affect as little other things as possible. Explaination in this comment. The following is that fix:

In the class called net.minecraft.world.level.block.DiodeBlock there is a function called boolean shouldPrioritize(BlockGetter, BlockPos, BlockState) where the issue originates from. In the last line there is an inequality which is incorrect. The last line frontState.get(FACING) != direction should be changed to frontState.get(FACING) != direction.getOpposite().

There is also a usecase where another alteration is needed. To fix this we have to also return true if the diode is of a different type.

Finally in this function we have to check the direction only for repeaters so it only applies to locking repeaters. The following is the code for that using close to official mappings (optimized for fewer calls to getOpposite()).

public boolean shouldPrioritize(BlockGetter blockGetter, BlockPos pos, BlockState state) {
    Direction direction = state.get(FACING);
    BlockState frontState = blockGetter.getBlockState(pos.offset(direction.getOpposite()));
    if (!isDiode(frontState))
        return false;
    Block frontBlock = frontState.getBlock();
    if (frontBlock != this)
        return true;
    return frontBlock == Blocks.REPEATER && frontState.get(FACING) != direction;
}

For the fix to not break other contraptions we found that it is also needed to change all 4 scheduled update priorities that are used in the DiodeBlock to be 1 higher. This would require to make a new Priority in the enum that is -4. For example -1 would become -2, -2 would become -3 and so on. I know that it is an enum now, but using integers is easier for explaining. Note that the values in the enum should still stay the same, only an introduction of -4 is needed!

Changing this fixes the mentioned bug and affects only the specific case where the chain bug is present. E.g. the repeater lock stable which is intended behavior relies on the correct priority to be set and remains functional from the abovementioned fix, etc.

Clicked wrongly, sorry 🙂

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.

Negative. And Quasi Connectivity works as intended, so that's a very bad example, and thus not a valid argument.

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.

You clearly do not read the comments.

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.

It doesn't break it - in fact it's part of the code. Even if so, it was said in the newest snapshot (16w41a), that the observers should now power for 1 redstonetick rather than 1 gametick. The thing is, that there is no such thing as redstone tick, however it is said to be equal to 2 gameticks

Confirmed - 1 redstone tick is 2 gameticks ie. 1/10th of a second

Confirmed - The redstone dust doesn't get updated properly

Turns out, the bug is very easy to recreate from scratch. It turns out, that if you simply build a grand wall of around 70 or so pistons and power them all, the client will crash, when you unpower them. If you wanna recreate this bug, you can download the attachment ("Piston Crash Demo") and flick the lever, to turn off all the pistons. If the bug does not appear, you can add more pistons to stress the packets even more.

There can be multiple reasons for this, but from my perspective, I'd say that the pistons are simply creating so many packets, that the client get's out of sync with the server. When this happens, the tileentity might not have been deleted or the block might not have been set before the next gametick. This will cause the tile-entity to look at a blockstate on an airblock rather than the actual moving tile (as it's not been updated on the client yet).

Confirmed.. Reason is correct too. When they're updated the moment before they're pushed, they'll stay in powered state 🙂

Observers activate on a block update. Observer blocks in this case will update any block with a Manhatten distance (search it up, if you're confused) of 2. 😉

However.. The problem here should be changed. Yes, it is stange, that the observer blocks stay activated, and I see no real reason for this.

Observers activate on a block update. The redstone dust in this case updates any block with a Manhatten distance (search it up, if you're confused) of 2

In that case, many things would go against expected behaviour. I'll leave it to Jeb to decide, but seeing no legitament "fix" for this, as it is how redstone works, there wouldn't be a point in looking into it. I'm simply trying to save time on mojangs part, and make them fix bugs instead. But as you say, it's up to mojang to decide.

Works as intended - just like the repeaters, the observer block will update adjecent blocks, when powering the block at it's face. This applies even if there is no block in front of it. Since the observer block checks for updates, it will power, when this happens.

Making a loop of observerblocks however is something different, and does not seem to work correctly.