Eta740

TNT, Ice, Glowstone, Sea lanterns look just like "full blocks" as stone do, but they have different redstone properties, so I don't see what point you're trying to make when you say "they should act like them" in terms of redstone conductivity.

Looks like MC-49981 (a bug that was incorrectly marked as a dupe of an unrelated report) is back. And if my guess is correct, then MC-88959 (broken DP retraction) should now be fixed..? Afaik MC-49981 (persistent double headed piston) was "fixed" back in 1.9 by introducing MC-88959, rather than fixing MC-89146 (lost block event). Hopefully MC-89146 gets fixed this time.

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.

In that case, title should be changed to "Opaque blocks at the top of subchunks (chunk sections) do not increase the world height to the next subchunk" or something similar. Also, summary is misleading, since empty subchunks should not attempt to spawn mobs other than this 1 exception.

The skull projectiles would be "spawned in" inside the block, and explode without escaping into another block. Possibly have something to do with not having a hitbox from the inside? Also, I believe arrows still work fine as a projectile intuitively in 1.12, so this might be something worth looking into in case the other projectile fix (for enderpearl, snowball etc) needs to be tweaked as well.

Subchunks are calculated individually for x/z since 1.9 or 1.10. Maybe the height map is not being adjusted properly when there's an opaque block at the top of a subchunk (previously, an opaque block at the top of a subchunk would also make the subchunk above it eligible for spawning)

To test this theory, try it at any other place where y = 16n - 1 (so 15, 31, 47, 63 etc) and see if you get the same results.

Of course light is affected... Look at the debug screen. If there's no reduction, skylight is 15, but clearly it's not.

Hey, each time you make an edit, you send out email notifications to everyone watching, so try to edit in bulk before you hit "save". And there's no need to repeat your edits in the comments since it's already recorded in the "activity" tab, and also sent via email notification as well.

Another reason to fix: This change implies something has changed with how observers react to change.
The reason why pushing with a piston created a 4gt clock is that when the piston pushes, it places the piston extension (aka block36) directly in front of the observer, which the observer detects. This creates the offset of 2gt between the observer pair, making them trigger every 4gt by detecting each other's change.

Elytra still heavily affected by ping. I can easily fall down by 10-20 blocks before the elytra activates

EDIT: For 1.12.2

Note: If you check the hitbox by using F3+B, it still shows the normal 1x1 size

Correction: Llama's hitbox is slightly less than 1 block in width. They are 0.9 x 0.9, with a height of 1.87

This bug also affects enderpearls, snowballs, thrown potions

> you have BUD piston lines
I was referring to pistons. The are far superior to observers in flying machines as they can instantly transmit signals. You cannot use a torch for this unless you can place blocks on top of the piston base, which most of the time you cannot.

For static structures, this is not really that much of an issue. The real problem is for complex flying machines, where you need everything to be movable, and not stick to other components.

More often than not, you have BUD piston lines facing sideways or upwards, which means you cannot place torches or flower pots on top of them. If you place a block, it would stick, and if you break it again, you need to do it in the same gametick, in the correct part of the tick, or else the sticky piston would recognize being updated twice, and lose the block.

The reason why flint and steel was so useful was because it was block-update-instant in placing AND destroying the fire, leaving no room for double triggering of components. A valid replacement for this mechanic would need to achieve the same thing, create an update that cannot double trigger anything - even within the same gametick.

@Guerin Since 1.11, they don't spawn anymore, because they are separate entities and no longer variants of a skeleton. But I guess it would be fine to make any rider control a horse, in case map makers want to use it.

I'm suggesting how it can be fixed with quite more detail than the average complaint. Besides, when minecarts were first added, there was still more cases of mobs not controlling than when they did. The only jockey at that time would've been the spider jockey (if they even existed at that time), and then there's the player. Meanwhile, you still have pigs, cows, and chicken. Not sure if the nether came before, but if they did, there's also the pigman and ghast.

Here's what I don't get: Why do you assume the entity riding it will always control it? There should be far more cases of where it shouldn't, than when it should, so doesn't it make sense to assume the rider doesn't control it unless it's the player/jockey?

I'm not a programmer, but my logic suggests it would make sense to code for:

• no entities would control a minecart except a player

• no entities would control a horse except a player, skeleton (skeleton horse trap)

• no entities would control a spider except a skeleton (spider jockey)

• no entities would control a chicken except zombie, husk, pigman (chicken jockey)

Those rules would have far fewer exceptions than coding for every mob in the game to not control an entity, and it wouldn't increase unless a new jockey was added (which doesn't happen that often compared to how often new mobs are added)

Put the dust on top of glowstone. Wouldn't work if you need to QC-power something below the dust as well, but should work for other cases.

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.