MrRedi

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 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.

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.

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:

^{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".}

By the way, it is not the issue of datapack. I checked everything.

Any idea how to fix it? I made similiar datapack in the past, but I didn't have issue like that. How should I optimize it? And how is it caused by lag if I break it slowly, but when I break it fast, it breaks normaly.

It does work in 1.19.3. But then crashes when it is in 1.20 and above.