I've tried 5 different clocks, whereas 3 where fast and 2 were adjustable, the 3 first worked as I thought, bad. The adjustable ones didn't work either, IF you had a too high relative number. I do however not know if this affects Z/-Z or X/-X. So I'll have to limit my contraption to very few TPs, which unfortunately will make it "chunkier" and not as smooth. Do you know a workaround to make it a smooth TP (perferably with a low Y value, like 0.4) but work on a fast clock? If not I'll settle with what I can do but thanks if you do.
Does that mean that it sometimes delays the teleportation but takes the previous location as relative marker?
What I mean is, I fall to the ground, and I'll be teleported to right beneath the roof, or pos A and then teleported again. Where pos A is where I was before I landed.
Well, the commands are run on a /fill clock, /fill ~ ~-1 ~ ~-4 ~-1 ~ redstone_block + /fill ~ ~1 ~ ~-4 ~1 ~ stone, the commands are executed from nearest to furthest away from the clock:
1. execute @a ~ ~ ~ detect ~ ~-1 ~ quartz_block 0 execute @p ~ ~ ~ detect ~ ~-2 ~ redstone_block 0 scoreboard players set @p Cannon X
2. tp @a[score_Cannon_min=1] ~ ~1.7 ~
3. scoreboard players remove @a[score_Cannon_min=1] Cannon 1
Simplified: The TP command (2.) activates/executes multiple times when it should not, most often it happens after the contraption has done what it's supposed to do, it suddenly TPs again after I've landed (which I should). The bug only happens when these commands are run on a clock. Perhaps only on a /fill clock.
Nah Mustek is right, since I didn't have an entity with the name of "notgate" and some items have weird codenames, like "sulphur" for gunpowder.
Feel free to post the report. I'll try entitydata + motion, and see what happens.