Curtis Stofer
- Silicon42
- silicon42
- America/Los_Angeles
- Yes
- No
MC-116819
MC-118129MC-118508![[Mojang] Jasper Boerstra](../../../data/avatars/users/18951.svg){kind=small}
Attempting to place tripwire hooks on the sides of pistons
andglowstone blocks succeeds even though it should not. When they receive a block update, they check if they are in a valid position, realize that they are not, and pop off. This is likely related to MC-117019Attempting to place tripwire hooks on the sides of pistons, glowstone blocks, and sea lanterns succeeds even though it should not. When they receive a block update, they check if they are in a valid position, realize that they are not, and pop off. This is likely related to MC-117019
Tripwire hooks can be placed on the sides of pistonsandglowstone blocksTripwire hooks can be placed on the sides of pistons, glowstone blocks, and sea laterns
Tripwire hooks are now placeable on many things that they should not be able to be placed on including "glassy blocks" such as glass, glowstone, sea lanterns, ice, and more, such as leaves and pistons. This is relative to what they were placeable on in prior versions, which is assumed to be the originally intended behavior. In prior versions, they shared the same placing and valid attachment requirements as redstone components that attached to the sides of blocks such as levers and buttons, unless other components are going to be able to attach to such things as well going forward, it would be confusing to have some of these attach to certain blocks and have other things not attach to the same blocks due to seemingly arbitrary conditions.
A list of blocks that tripwire hooks and ladders are attaching to that are erroneous according to precedence in previous versions: glass, stained glass, ice, frosted ice, leaves pistons (full sides only, when extended only the back is "valid"), the face of piston heads, glowstone, sea laterns, shulker boxes, beacons, and cauldrons.
Upon reloading a world that had boats with multiple passengers, only the boats' primary passengers still existed. Any further passengers that were in the boats were seemingly deleted. This only seems to affect boats, other entities with multiple passengers reload fine.
Upon reloading a world that had boats that were summoned with with multiple passengers, only the boats' primary passengers still existed. Any further passengers that were in the boats were seemingly deleted.
{id:"pig"}
Ex: /summon boat 0 6 0 {Passengers:[,
{id:"creeper"},
{id:"creeper"}]}
In certain cases with multiple secondary passengers, not all of the secondary passengers disappear.
{id:"creeper"}
Ex: /summon boat 0 6 0 {Passengers:[,
{id:"pig"},
{id:"creeper"}]}
This only seems to affect summoned boats, other entities with multiple passengers reload fine.
Saving and reopening a world with boatswith twopassengers deletes the rear passengerSaving and reopening a world with boats that were summoned with two or more passengers deletes the rear passengers
If you are being pushed by flowing water, such as having the block adjacent to the ladder being flowing water, and attempt to climb a ladder (and presumably vines as well), you will not be able to climb the ladder until you fully exit the flowing water.
Ideally,being pushed intotheladder or other solid area while in the climbingarea of the ladder would cause you to climb the ladder just as the player attempting to use a ladder normally would, this would allow it to be used as a mob elevator or potentially as a trap of some sort.If you are being pushed by flowing water, such as having the block adjacent to the ladder being flowing water, and attempt to climb a ladder (and presumably vines as well), you will not be able to climb the ladder until you fully exit the flowing water.
This is especially bad in the case where the water in a waterlogged ladder is considered to be pushing the player, creating an unclimbable ladder, as in the 2nd screenshot.
Ideally, being pushed into the ladder or other solid area while in the climbing area of the ladder would cause you to climb the ladder just as the player attempting to use a ladder normally would, this would allow it to be used as a mob elevator or potentially as a trap of some sort.
Windows 7 64-bit running Java 8 Update 171 64-bit
When attempting to flow, water typically uses the shortest path if there is one, however this is currently considering waterloggable blocks as places it can attempt to flow into. This means that it will fail to flow at all if there are waterloggable blocks in the shortest path.
This only seems to affect sources and waterlogged blocks but not flowing water.
When attempting to flow, water typically uses the shortest path if there is one, however this is currently considering waterloggable blocks as places it can attempt to flow into. This means that it will fail to flow at all if there are waterloggable blocks in the shortest path.
This only seems to affect sources and waterlogged blocks but not flowing water as the the latter two screenshots demonstrate.
The top texture of the Librarian villager and Zombie villager professions is rotated 180 degrees. Looking in the assets shows this to be a problem with the texture itself and not any coding error.
The blue arrows denote where the white strap should be if the texture were correct.
It's possible that this applies to other villager related textures as well, but it only seems noticeable to me on the Librarian textures
The top texture of the Librarian villager and Zombie villager professions is rotated 180 degrees. Looking in the assets shows this to be a problem with the texture itself and not any coding error.
The blue arrows denote where the white strap should be if the texture were correct.
It's possible that this applies to other villager related textures as well, but it only seems noticeable to me on the Librarian textures
Edit for clarification: I found this while making a resource pack which is why the librarian profession texture is overlayed over the villager texture.
Player's verticalheadrotation jumps when moving up and downPlayer's vertical rotation jumps when moving their head up and down
Player's vertical rotation jumps when moving their head upand downPlayer's vertical rotation jumps when moving their head upwards
When the player moves their head up
and down, the vertical rotation will occasionally jump.To reproduce, look straight down and then
slowlylook up. The player's vertical rotation jumps instantaneously from near 90 degrees (straight down) to between 0 degrees and -90 degrees (straight up).While the effect does occur at other angles, it is most noticeable if performed as above.
When the player moves their head upwards, the vertical rotation will occasionally jump.
To reproduce, look straight down and then look up. The player's vertical rotation jumps instantaneously from near 90 degrees (straight down) to between 0 degrees and -90 degrees (straight up).
While the effect does occur at other angles, it is most noticeable if performed as above.
Slow upwards motions when rotating upwards between 0 and -90 seem to not trigger the effect but slow motions upward between 90 and 0 do. Fast motions upward between 0 and -90 seem to make the vertical rotation jump to between 90 and 0 and fast motions upward between 90 and 0 seem to make it jump to between 0 and -90.
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
@Curtis Stofer, 19w42a is this ticket MC-161849.
This also applies to vines, buttons, levers and tripwire hooks. It also effects snapshot 17w17b. I'm afraid I don't know how to update the issue myself, so I can only comment here.
I also find it strange that torches can be placed on the sides of observers but that other redstone components can not be and that redstone components can be placed on top of pistons and observers regardless of their orientation but not on the other sides when rotated differently but those details have precedence and may not be bugs.
The vine behavior has not changed since 1.11.2. I didn't check prior versions but I assumed that was likely the intended behavior since they have to attach to leaves and other things. I also assumed that the difference in side attachment for torches and for redstone components might not be a bug because no one had mentioned it since we got observers and in all other aspects, components attached to observers the same as they did to pistons.
Ultimately that ties in with whether or not all blocks that "hang on" or attach to other blocks such as redstone components, ladders and torches should be able to attach to the sides and undersides of pistons and observers in the first place as they were not able to previously. That being said, components attaching to the tops of pistons was added so why not the sides and bottom as well?
I guess you didn't see my edit, I did add a list of blocks that they are currently attaching to that they should not be after some more experimentation.
As far as torches attaching to redstone blocks, I'd check some of the older versions to see if that might actually have been intended behavior. I'm pretty sure they always have been able to attach to them. If anything, I'm all for things being able to attach to more blocks, so long as it's consistent and makes some small amount of logical sense.
I just checked release 1.8.9, torches were able to be placed on the sides of redstone blocks back then and were probably always able to be as I seem to remember a lot of people using that behavior to start redstone contraptions that required a short pulse.
The ability to place torches on the sides of redstone blocks is very likely an intended feature. I can't necessarily say the same about observers although this behavior did appear in the 1.11 releases, but if anything, it's stranger that buttons and levers can't be attached to the sides and undersides of redstone blocks, observers and pistons than it is that torches can be placed on the sides of the first two.
It seems that I was slightly wrong about the nature of the bug. It instead involves only boats summoned with multiple passengers. I will update the bug report to reflect this.
JIRA seems to have mangled the NBT tag in the description. You'll have to remove the newlines if copying and pasting.
Yes, Cobblestone and Mossy Cobblestone walls.
Previously, normal pistons when short pulsed would not cause the blocks they were pushing to be dropped immediately in the new position, the moving block would instead take as long as it normally would to arrive at its new location as if the piston had not been short pulsed. I don't know if the piston head itself immediately retracted though so can someone else weigh in on that part?
You could just use a world download of an existing large scale flying machine like one of the more recent quarry designs that the technical community makes and remove the roof that they have, rather than building something yourself.
This is intended behavior. Collision boxes that intersect with itemframe hitboxes cause them to fall off.
This is intended. In what way would mixing concrete powder with lava make sense for turning it into concrete? When you get concrete mix from the hardware store, do you think that you have to drill a hole through the earth's crust to get lava to mix with it? No. You add water...
This is intended. Torches don't react to 1 redstone-tick pulses and never have. They need at least 2 redstone-ticks to react.
IIRC, this is that minecart derail "feature" that was added awhile back that nobody really likes. It made it so that high momentum minecarts would fly off corners as an incentive to make people have slower minecart speeds.
What render distance were you using? If it's below 10, there's a good chance this is a duplicate of
MC-2536.This is a likely a duplicate of
MC-2536.I too have this problem, however my current location is NOT in a Germany speaking locale. I am located in the US and have tried clearing the cookies for the site, as well as the cache. This occurs on all computers in my house, regardless of which browser is used. So far, I have tested Opera and Chrome browsers. I have not yet tested if the same occurs at other locations.
@ZeNico13
From the looks of your video, your worldborder is not perfectly aligned to a block boundary, while the worldborder may not always visually line up perfectly with the edges of blocks, any blocks that it partially includes are treated as being within the worldborder. This means that you weren't actually pushing the blocks outside the worldborder.
Confirmed for 19w42a. It also affects the UI, color now, tinting it blue and darkening it. Should I make a separate bug report for that?