mojira.dev

Berni U

Assigned

No issues.

Reported

MC-64789 Tripwire changes value when an entity occupies the same block even if it's not connected to a hook Works As Intended MC-57873 All resource packs get deselected when only one is broken Invalid MC-56298 Command blocks not executing while triggered by a very fast clock Duplicate MC-44702 Selector arguments not working in the expected location Fixed MC-35295 FallingSand Entities rotate texture not correctly Won't Fix MC-11268 Vertical double piston extender retract wiredly Duplicate MC-9632 GUI and entities are flashing randomly Duplicate MC-9243 TNT doesn't cause any damage Duplicate MC-4541 Items in hotbar disapears after rightclicking dispensers Duplicate

Comments

Duplicate of MC-68399

Not only while writing a sign, for me it happens every time I press the key.

I don't think that this is a duplicate of MC-42192 as it appears regular and not just in the tick while summoning.
Also I can confirm it for 14w34d.

I think for the hooks to track if an entity is in the tripwire.
I don't knwo if it really is works as intended, but I think so.

Ah. You're right that the tripwire changes its data value when an entity occupies the same block, so it works as intended. Apparently I was tired when I came across this and it confused me.
qmagnet, thank you for your pacience and helpfulness.

Can a mod please mark this as works as intended or just close it, if only Mojang can mark it as works as intended?

Ok, I'm sorry, I was wrong. I've missinterpreted it as I didn't looked at the coordinates I was using.

BUT what I actually discovered was that when typing in

/testforblock ~ ~ ~ minecraft:tripwire 0

while standing at 9, 101, 130 it returned "The block at 9,101,130 had the data value of 1 (expected 0).". (Image 1)
Now I go 1 block north, so I'm standing at 9, 101, 129 and entered

/textforblock ~ ~ ~1 minecraft:tripwire 1

and it returned "The block at 9,101,130 had the data value of 0 (expected 1).". (Image 2)

I have updated the description and title to correct it.

Can confirm. See http://gfycat.com/FrenchFaroffBrahmanbull

Also commands which relay on that data don't work. Some seem to work with absolute coordinates (e.g. blockdata) and not relative coordinates but others don't work at all (e.g. testforblocks).

Also comparators.

This has nothing to do with signal strength as in the other bugreport. Here clearly get blocks swapped between a redstone block and stone which should cause a block update, even when it happens 20 times a second.
I'm sorry that I wasn't specific about the clock, but I use a command block based clock (one command block sets all blocks to stone the other in the same tick to redstone blocks, wich triggers all command blocks again for the next tick).

This is still a bug in 14w20b.
Last Username, please update the affected versions list to help Mojang.

That would be more logical that the piston can push stronger than the friction force is between the slime and stone

It is not a concern in Minecraft 1.7.9 as it has something to do with the "smooth relative teleportation" introduced in one of the 1.8 snapshots, but it is still a concern in 14w11b.

The same in 14w05a, but as Grum said (MC-17802), it may be intentionally.

Can someone please mark this as fixed or something similar? (It was fixed in 14w03a)
Thank you.

Confirmed in 13w24b.

Confirmed for 13w21a

I get the same error after about 10 minutes on Windows.
error log: http://db.tt/KRevkWwZ

If you build the same setup but downwards, the upper piston doesn't retract the lower one, as it was in earlier versions.

No, I have about 100 fps and for 1 fps the GUI and all entities are flashing.
Sorry I thought a bit wrong about the time.