I'm building a map and I'm using a scoreboard objective do determine how long a player is TPed vertically (Z/-Z) and these are the commands I've used:
execute @a ~ ~ ~ detect ~ ~-1 ~ quartz_block 0 execute @p ~ ~ ~ detect ~ ~-2 ~ redstone_block 0 scoreboard players set @p Cannon X
scoreboard players remove @a[score_Cannon_min=1] Cannon 1
tp @a[score_Cannon_min=1] ~ ~1.7 ~
Cannon is a 'dummy' objective and X is because I've tried mutliple scores to determine distance AND when the bug happens.
I'm not sure why but when the player hits something and starts falling, they'll fall to the ground, and suddenly they'll get returned to where they were they bumped into something, in this case the roof. If the score is set high enough to go over the roof it'll land and tp once again after landing. Bouncing on the block like a trampoline and landing outside of it will cause the bug to happen too. The only time when it does work correctly is when the score is so low that you basically tp up and down on a loop, which is what I'd expect.
So what I'm trying to say is that sometimes /tp does mutliple TPs to the destined location, be it specific or relative coordinates.
Related issues
Comments
migrated
migrated
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.
migrated
Ok, this is a bug which I had noticed a long time ago, but I guess I forgot to report it. It's actually a different bug then what you thought, it's not teleporting you too many times, it's that when the teleport command is run very fast, it will not update your position fast enough. Run the command "tp @p ~ ~1 ~" on a 20 hz clock and you will see the bug. It's not just client side, other players can see it too.
migrated
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.
migrated
No, it will teleport you partway, then let you fall, then finish the teleports. If you want to get around this, you can slow down the clock.
migrated
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.
migrated
One thing you could try would be to summon an invisible armor stand and move it around with entitydata, which should hopefully not be a glitchy as teleport, and then teleport the player to the armor stand. About this bug, do you want me to post a report of the actual bug, or do you want to maintain this one?
migrated
Feel free to post the report. I'll try entitydata + motion, and see what happens.
migrated
Alright. Could a mod please resolve this as a duplicate of MC-76463.
Could you provide a better explanation of what you are doing? Are you executing each of those commands once, or over and over? In what order are you executing them? Also, try to simplify the bug to its most basic form. For example, remove the execute commands.