KlepSauce
- klepsauce
- klepsauce
- Australia/Sydney
- Yes
- No
MC-5215![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
When an entity teleports to a player, that entity receives its yaw and pitch rotation data regardless of if they are moving or stationary.
When either a player or entity teleports to a (this is not tested for all) mob or presumably any non-player entity with yaw and pitch values, the rotation data is only copied when the entity being teleported to is in motion. If they are standing still and simply looking around, it's rotation data will not be copied.
As far as I can tell, this seems to be an issue of non-player entity rotation data only being updated when they are in motion. I remember seeing a comment Searge made in another bug thread in which he mentioned that 'mobs don't serialise their orientation':
Is there potential that this could be the issue?
Edit: u/TimMinChinIsTm-C-N-H from MinecraftCommands subreddit (http://www.reddit.com/r/MinecraftCommands/comments/2raklr/teleporting_to_mobs_and_other_nonplayer_entities/) correctly mentioned that I should clarify that if you teleport to a non-player entity, the rotation data you receive will be the final rotation when they were last in motion. This is regardless of whether they have since rotated but remained stationary, meaning you can be rotated in a completely random direction unless you teleport as they are moving. Hopefully this better explains the issue at hand.
When an entity teleports to a player, that entity receives its yaw and pitch rotation data regardless of if they are moving or stationary.
When either a player or entity teleports to a (this is not tested for all) mob or presumably any non-player entity with yaw and pitch values, the rotation data is only copied when the entity being teleported to is in motion. If they are standing still and simply looking around, it's rotation data will not be copied.
As far as I can tell, this seems to be an issue of non-player entity rotation data only being updated when they are in motion. I remember seeing a comment Searge made in another bug thread in which he mentioned that 'mobs don't serialise their orientation':
Is there potential that this could be the issue?
Edit: u/TimMinChinIsTm-C-N-H from the MinecraftCommands subreddit (http://www.reddit.com/r/MinecraftCommands/comments/2raklr/teleporting_to_mobs_and_other_nonplayer_entities/) correctly mentioned that I should clarify that if you teleport to a non-player entity, the rotation data you receive will be the final rotation when they were last in motion. This is regardless of whether they have since rotated but remained stationary, meaning you can be rotated in a completely random direction unless you teleport as they are moving. Hopefully this better explains the issue at hand.
This is a very specific bug and took lots of testing to reliably discover what the problem is and find a pattern in the behaviour. However, I am no closer to discovering the reason why this happens.
Set up steps:
1. Build a standard fill clock with the following commands:
fill ~ ~1 ~ ~4 ~1 ~ minecraft:stone (on bottom)
fill ~ ~-1 ~ ~4 ~-1 ~ minecraft:redstone_block (on top)
2. Create a score called Test and set it to the sidebar.
3. Spawn an armor stand.
4. Along the fill clock, place the following four commands, in ascending x order (does not necessarily have to be x, just ensure that the order the commands are run is preserved)
tp @e[type=ArmorStand] @p
scoreboard players set @e[type=ArmorStand] Test 0
execute @e[type=ArmorStand] ~ ~ ~ scoreboard players set @e[type=ArmorStand,r=1] Test 1
tp @e[type=ArmorStand] ~-8 ~ ~If one tries to run this fill clock, the expected behaviour would be for the ArmorStand to constantly have a Test score of 1 at the end of the cycle, regardless of the player's position. This expected result occurs if the final /tp command is omitted. However, if left in, very unusual behaviour occurs.
With that particular /tp command included, if the player is positioned between the internal chunk x coordinates 3 and 8, the execute command will fail and Test will be 0. If the player positions themselves from 8 to 15 or 0 to 2, Test will be 1 (i.e. expected behaviour)
A pattern arises where the relative teleport value becomes the chunk x coordinate which will provide the upper end of the failure interval. i.e. tp @e[type=ArmorStand] ~-9 ~ ~ will cause the /execute to fail from 3 to 9, tp @e[type=ArmorStand] ~-15 ~ ~ will cause the /execute to fail from 3 to 15, tp @e[type=ArmorStand] ~-17 ~ ~ will cause the /execute to fail from 3 to 1 in the next chunk, and anything larger than -19 will cause the execute to fail regardless of the player's position.
If a formula were to be applied to this, the execute will fail within the range of 3 to (-tpX % 16). To summarise, for negative tpX if -tpX is smaller than 3, the /execute will always succeed and if larger than 19, will always fail.
This same issue also occurs on all other coordinate axes and also occurs if positive relative teleports are applied, however the range will instead be ((15-tpX) % 16) to 12, as it instead hangs at the upper end (15 - 3) of the chunk range and extends backwards from there.
Modifying the r value in the /execute command to be larger will ultimately have a threshold for each tpX value at which the /execute will no longer fail, however I have as yet not been able to find a pattern which correlates.
Obviously this behaviour is completely unintended and can cause major failures in more complex command systems. Hopefully my explanation is not too convoluted, as I mentioned at the beginning this is a very specific bug but has major consequences.
I have also attached four pictures. The first shows my setup. The final three show the results with a /tp command of tp @e[type=ArmorStand] ~-8 ~ ~. You can clearly see that at internal chunk x coords of 3 and 7, Test is 0 (/execute failed) and at 8, the /execute has succeeded.
Thanks very much and hope this was helpful, Klep
EDIT: Here is a more generalised case in which a similar arrangement will fail for no particular reason.
tp @e[name=Test1] @e[name=Test2]
say @e[r=1]
tp @e[name=Test1] @pCreate two armor stands named Test1 and Test2. Test2 should be situated directly above the second command block. Put all these on a fill clock and ensure they are in ascending order as usual.
While one would expect that the say command should always report that Test1 and Test2 are in the same position, this is not the case and will fail if the player is outside a certain range of Test2. Changing r to be bigger will modify that range to be large, but this has no conceivable pattern.
It almost seems as if the second teleport cancels the first teleport when the player is too far away?
I'd appreciate if mods could help me clean up this report to be more clear.
Edited the report to include a much more generalised case and possibly more concerning. I believe the underlying principles behind both bugs still apply, however the second case leads me to conclude that /execute is not to blame, but rather teleportation itself is. Unsure how to change the title to be more clear and would appreciate any help in clarifying the report itself.