Long story short, I am using the "rotate" command combined with "datapack macros". I am using it to rotate multiple entities to their own relative rotation. The value of macro is "~0.0". This works with "tp" command, but for some reason, it always gives me rotation [0.0f,0.0f]. I'm sending the visual showcase in the attachments. More information about this bug is in the pinned comments.
What I think is happening:
The rotate command has problem reading macro data that contains relative rotation "~", if it is used by command "execute on". It does read the value, but it always forgets to use that value with the relative "~".
Edit:
I think I found the issue. I have command that looks something like this: "execute on passengers run execute as @s at @s run rotate @s ~$(variable_1) ~$(variable)". As you can see in that command, the macro value is located after the "~" symbol. It seems like the command doesn't register the "~" symbol after it is followed by the macro value.
How to recreate this issue?
Have macro data and use them in the function like this: "rotate @s ~$(macro_1) ~$(macro_2)". Instead of "moving" your rotation based on your current rotation, it should "set" it so it's exact same as in those macros.
Thank you for your hark work as always!
Attachments
Comments 9
I do actually. My command is something like this: "execute at @s as @s run rotate @ $(variable_1) $(variable_2)".
Here is the .mcfunction file:
[media]
Entity_1 is interaction, Entity_2 is donkey and Entity_3 is item_display. Both item_display and donkey are riding the interaction. Player is riding the donkey. Whole function is being run by the item_display. (item_display it the entity executing the function.)
The macros are:
PosMain: "0,0,0", PosPreset: "~0,~0,~0", PosOffset: "0,0,0", RotMain: "45,45", RotPreset: "~0,~0,~0,~0,~0,~0", RotOffset: "0,0,0,0,0,0".
Try simplifying your setup:
function rotate {y:0.0f,x:0.0f}rotate:
$execute as @a at @s run rotate @s ~$(y) ~$(x)This works fine, so it's a problem with your setup
I understand what you are getting at, but the script is correct. It may be complicated, but just because it is complicated doesn't mean it shouldn't work.
I have tested the macros ,just like it is visible in the video in the attachments, and the macros are correct.
In the video, I copied the line with the "rotate" command, pasted it right below it and then I replaced the "rotate" command with the "say" command. So there is no way that there is error in the script.
Even if it is not bug with the "rotate" command, then it's either bug with macros or the "execute on" command.
Also, there similar command with "main" macro values. That command works and the rotation was changed correctly when I removed the rest of the script. It is pretty much the exact same command, just the macros have different value.
I'm starting to think that the bug has something to do with "execute on" command and the relative values in macros (I mean this: ) not interacting properly, since there weren't any "main" macros with the relative "" value.
I'm gonna change the title of the bug report to more fit this situation.
We do not have enough information to reproduce this issue.
Please include the following information to help us understand your problem:
Steps to Reproduce:
1. (Explain what needs to be done for the issue to happen)
2.
3.Observed Results:
(Briefly describe what happens)Expected Results:
(Briefly describe what should happen)
Please also attach any needed commands, add-ons/behavior packs, data packs, resource packs, screenshots, videos, or worlds needed to help reproduce this issue.
Refer to the Bug Tracker Guidelines for more information about how to write helpful bug reports. Bug reports with insufficient information may be closed as Incomplete.
This issue is being temporarily resolved as Awaiting Response. Once the requested information has been delivered, the report will be reopened automatically.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
I am responding to the mod's comment about the lack of information how to recreate this bug, so I'm making this comment to give instructions.
These are the two scripts in my datapack that are making trouble:
"get.mcfunction" and "put.mcfunction"
They are in the attachments.
The "get.mcfunction" might look scary, so here is brief explanation:
There are a lot of macro variables, so there is a lot of commands, but most of them do the same thing. Our main points of focus are the "Position" and "Rotation" parts. What it does is that it creates "Position" array of arrays in the "item.components."minecraft:custom_data"" of item display, in which arrays can be of a certain type/name. Those types are "main", "preset" and "offset". In each array, there is another array of arrays called "Variables". This array of arrays contains arrays that have the name and the value of certain variable (It is made this way because, sometimes I may not only need the value of variable, but also its name {as macro value}). This "Position" array of arrays is pre-generated with "safe to use values". Those "safe to use values" are values that fill space in function in a way that function doesn't have error or blank space, since that would break the function (For example, if we had blank macro values "#blank, #blank, #blank" and we were to put them in the "tp" command like this: "tp @s #blank #blank #blank", then it would cause error, because we didn't specify the "tp" location., since they are just blank spaces. And if we were to set macro values with real values "0.0, 0.0, 0.0", then the "tp" command would work, but it would then really teleport us at coordinates "0.0, 0.0, 0,0", because those were the values we set it to. But we do not want to change our location, because we don't know the location we want to be teleported to, so that's why we use relative coordinates "~0.0, ~0.0, ~0.0", because they would not change our location and would just teleport us to our current location). Those "safe to use values" are then replaced with values that we really want to use, if we have them. Once all of those values were changed (or not, and stayed as "safe to use values"), then they are all converted into macro data. Macro data is in the "MacroData" array. This same principle works with "Position" and "Rotation" sections. It's just that in "Rotation" section we are looking for more values, because in the "Position" section we are looking for position, which is same for all of the entities, while in the "Rotation" section, each entity can have different rotation.
Once we have these macro values. We use them in the "put.mcfunction". And set them for four entities: interaction, donkey, item display and player. Donkey and item display are passengers of the interaction. Player is riding the donkey.
Both of these functions are run by item display entity.
If you have any questions, let me know in the comments.
The problem seems to be that the "rotate" command has trouble with the "relative ~" value in the macro. For some reason, it reads it as "0.0", instead of "~0.0". That's what I think at least.
Please attach a minimal-setup data pack to recreate the issue then. These functions are too convoluted to understand (you also only attached "put").
Ok. So I tried to attach the datapack, but it didn't work, because it was a folder and I completlly forgot that zip files exist. I'm sorry that I'm dumb.
The said files are in the:
"Datapack\data\datapack\function\backpacks\trigger\main\behaviour\activated\data"
How to use:
Write this command into the chat:
"/function datapack:backpacks/trigger/main/behaviour/activated/data/give"
This command gives player dummy item that should contain data for testing. If you find this "give.mcfunction", then you can also modify it. There is "Position" data. If you want to test the "Rotation" data, then just copy the "Position" data and rewrite it into "Rotation". Names of the variables are a little bit different, so go check their names in the "get.mcfunction" file.
Even if you don't modify the variables, it should still rotate player to have rotation values [0.0f,0.0f]. It shouldn't do that. It should keep player's current rotation.
I have tried to reproduce this with a simplified macro matching the description of this report. This is what I tried:
$execute as @a at @s run rotate @s ~$(x) ~$(y)and also:
$execute as @n[type=#minecraft:boat] on passengers at @s run rotate @s ~$(x) ~$(y)Running this with
/function neun:test {x:0.0,y:0.0}and other values did the expected thing.
I suspect there is probably an issue in your datapack rather than the game.
If you think there is still a bug, please try to find a more minimal reproduction of this issue by consecutively removing parts of your functions to narrow it down. As it stands, I cannot confirm that there is an actual issue with the game here.
This issue is being temporarily resolved as Awaiting Response. Once the requested information has been delivered, the report will be reopened automatically.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
You're not executing at/rotated as the target. This works fine for me.