unused
- KuriSan_Fox
- JIRAUSER610915
- Europe/Stockholm
- Yes
- No
MCPE-129268MCPE-143458
I also know that the view bobbing broke from 1.13 and the north or south sway was fixed in 1.14.1, but now the north or south view bobbing sways in the opposite direction to the east or west.
Due to that, the shaking in some directions does not work properly.~ FILE ~
Minecraft 2021-02-19 02-08-30.mp4 = North or South(Broken)
Minecraft 2021-02-19 02-06-58.mp4 = East or West(Normal?)
(It is not a duplicate of MCPE-56214 and MCPE-54645)
I also know that the view bobbing broke from 1.13 and the north or south sway was fixed in 1.14.1, but now the north or south view bobbing sways in the opposite direction to the east or west.
Due to that, the shaking in some directions does not work properly(MCPE-54645).~ FILE ~
Minecraft 2021-02-19 02-08-30.mp4 = North or South(Broken)
Minecraft 2021-02-19 02-06-58.mp4 = East or West(Normal?)
(It is not a duplicate of MCPE-56214 and MCPE-54645)
I also know that the view bobbing broke from 1.13 and the
north or southsway was fixed in 1.14.1, but now thenorth or southview bobbing sways in the opposite direction to theeast or west.
Due to that, the shaking in some directions does not work properly(MCPE-54645).~ FILE ~
Minecraft 2021-02-19 02-08-30.mp4 =
North or South(Broken)Minecraft 2021-02-19 02-06-58.mp4 =
East or West(Normal?)
(It is not a duplicate of MCPE-56214 and MCPE-54645)
I also know that the view bobbing broke from 1.13 and the X or -X sway was fixed in 1.14.1, but now the X or -X view bobbing sways in the opposite direction to the Z+ or Z.
Due to that, the shaking in some directions does not work properly(MCPE-54645).~ FILE ~
Minecraft 2021-02-19 02-08-30.mp4 = +X & -X(Broken)
Minecraft 2021-02-19 02-06-58.mp4 = +Z & -Z(Normal?)
(It is not a duplicate of MCPE-56214 and MCPE-54645)
North or south view bobbing sways in the opposite direction ofeast or westNorth or south view bobbing sways in the opposite direction of X+ or X
North or southview bobbing sways in the opposite direction ofX+ orXX or X view bobbing sways in the opposite direction of Z+ or Z
I also know that the view bobbing broke from 1.13 and the X or -X sway was fixed in 1.14.1, but now the X or -X view bobbing sways in the opposite direction to the Z+ or Z.
Due to that, the shaking in some directions does not work properly(MCPE-54645).~ FILE ~
Minecraft 2021-02-19 02-08-30.mp4 = +X & -X(Broken)
Minecraft 2021-02-19 02-06-58.mp4 = +Z & -Z(Normal?)
03/26/2021: Please do not trust the name of the direction written on the sign. I made a mistake.
(It is not a duplicate of MCPE-56214 and MCPE-54645)
The screen shakes in the opposite direction of 1.12.1 when it takes damage.
1.12.1 matched the Java Edition, but since 1.13 it now swings in the opposite direction.
The shaking of the hand seems to work normally.
FilmForth Project 2021_02_21_14_28_00.mp4 = Old(2019/8) screen shake
FilmForth Project 2021_02_21_14_29_47.mp4 = New(2019/11) screen shake
The screen shakes in the opposite direction of 1.12.1 when it takes damage.
1.12.1 matched the Java Edition, but since 1.13 it now swings in the opposite direction.
The shaking of the hand seems to work normally.
FilmForth Project 2021_02_21_14_28_00.mp4 = Old(2019/8) screen shake
FilmForth Project 2021_02_21_14_29_47.mp4 = New(2019/11) screen shake
Fixed 1.18.30.26 / 27!
The screen shakes in the opposite direction of 1.12.1 when it takes damage.
1.12.1 matched the Java Edition, but since 1.13 it now swings in the opposite direction.
The shaking of the hand seems to work normally.
FilmForth Project 2021_02_21_14_28_00.mp4 = Old(2019/8) screen shake
FilmForth Project 2021_02_21_14_29_47.mp4 = New(2019/11) screen shake
To be honest, I don't like removing the falling sound of 1.13, but it's a bug ...
The falling sound in creative mode was removed in 1.13, but it still remains when hitting a wall with Elytra.(It was a duplicate of MCPE-55119 , so set it to Resolved and Duplicate.)
To be honest, I don't like removing the falling sound of 1.13, but it's a bug ...
The falling sound in creative mode was removed in 1.13, but it still remains when hitting a wall with Elytra.(It was a duplicate of MCPE-55119, so set it to
Resolved andDuplicate.)To be honest, I don't like removing the falling sound of 1.13, but it's a bug ...
The falling sound in creative mode was removed in 1.13, but it still remains when hitting a wall with Elytra.(Please It was a duplicate of MCPE-55119, so set it to resolved and duplicate.)
1.16.210の更新が面倒だったため、自分で削除したため、リソースパックが残っていません。
しかし、あなたはそれをバニラで見ることができるはずです。
The reason is that the map ID of render_controllers and animation_controllers, the map ID of player_firstperson.animation in animations, etc. have not changed even though the map ID has changed in 1.16.100.
can fix it by changing'map'to'filled_map'.
Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is Glacier. I don't remember the first one (maybe 9)
Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is Glacier. I don't remember the first one (maybe
9)Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is "Glacier"(not "falco"). I don't remember the first one (maybe "9")
Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is "Glacier"(not "falco").
I don't remember the first one (maybe "9")Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is "Glacier"(not "falco").
Deleted because there was a screenshot with the same seed value. I'm sorry it's hard to understand.
Minecraft 2021_03_27 8_53_16.png
Old Description(03/27):
Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is "Glacier"(not "falco").
Deleted because there was a screenshot with the same seed value. I'm sorry it's hard to understand.
New Desc(04/21):
再現手順：
1.
2.
3.観察された結果
何が起こるかを簡単に説明してください）期待される結果
何が起こるべきかを簡単に説明します）
Old Description(03/27):
Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is "Glacier"(not "falco").
Deleted because there was a screenshot with the same seed value. I'm sorry it's hard to understand.
New Desc(04/21):
再現手順：
1.
2.
3.観察された結果
何が起こるかを簡単に説明してください）期待される結果
何が起こるべきかを簡単に説明します）Old Description(03/27):
Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is "Glacier"(not "falco").
Deleted because there was a screenshot with the same seed value. I'm sorry it's hard to understand.
New Desc(04/21):
Steps to Reproduce:
1.Enter Seed bot 'falco' or 'Glacier' to Create new world.
2.Command '/tp 0 80 0' to Teleport to XZ 0 Pos.
3.Please look at biome border / river.Observed Results:
(Briefly describe what happens)Expected Results:
(Briefly describe what should happen)
Old Description(03/27):
Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is "Glacier"(not "falco").
Deleted because there was a screenshot with the same seed value. I'm sorry it's hard to understand.
New Desc(04/21):
Steps to Reproduce:
1.Enter Seed bot 'falco' or 'Glacier' to Create new world.
2.Command '/tp 0 80 0' to Teleport to XZ 0 Pos.
3.Please look at biome border / river.Observed Results:
(Briefly describe what happens)Expected Results:
(Briefly describe what should happen)Old Description(03/27):
Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is "Glacier"(not "falco").
Deleted because there was a screenshot with the same seed value. I'm sorry it's hard to understand.
New Desc(04/21):
You can see most seed values without having to enter these seeds. Biome boundaries can be created, not just rivers. This is unlikely to be normal as it occurs with almost all seed values. Since rivers are likely to be generated at the biome boundary, I think that the reason why rivers are likely to be generated at XZ 0 is that biome boundaries are likely to occur at XZ 0.
Steps to Reproduce:
1.Enter Seed bot 'falco' or 'Glacier' to Create new world.
2.Command '/tp 0 80 0' to Teleport to XZ 0 Pos.
3.Please look at biome border / river.Observed Results:
A river or biome boundary is created in the biome.Expected Results:
It should be generated as the correct biome form (sorry, I don't know how to explain it).
Old Description(03/27):
Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is "Glacier"(not "falco").
Deleted because there was a screenshot with the same seed value. I'm sorry it's hard to understand.
New Desc(04/21):
You can see most seed values without having to enter these seeds. Biome boundaries can be created, not just rivers. This is unlikely to be normal as it occurs with almost all seed values. Since rivers are likely to be generated at the biome boundary, I think that the reason why rivers are likely to be generated at XZ 0 is that biome boundaries are likely to occur at XZ 0.
Steps to Reproduce:
1.Enter Seed bot 'falco' or 'Glacier' to Create new world.
2.Command '/tp 0 80 0' to Teleport to XZ 0 Pos.
3.Please look at biome border / river.Observed Results:
A river or biome boundary is created in the biome.Expected Results:
It should be generated as the correct biome form (sorry, I don't know how to explain it).The world generator has been updated so it no longer exists.
Old Description(03/27):
Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is "Glacier"(not "falco").
Deleted because there was a screenshot with the same seed value. I'm sorry it's hard to understand.
New Desc(04/21):
You can see most seed values without having to enter these seeds. Biome boundaries can be created, not just rivers. This is unlikely to be normal as it occurs with almost all seed values. Since rivers are likely to be generated at the biome boundary, I think that the reason why rivers are likely to be generated at XZ 0 is that biome boundaries are likely to occur at XZ 0.
Steps to Reproduce:
1.Enter Seed bot 'falco' or 'Glacier' to Create new world.
2.Command '/tp 0 80 0' to Teleport to XZ 0 Pos.
3.Please look at biome border / river.Observed Results:
A river or biome boundary is created in the biome.Expected Results:
It should be generated as the correct biome form (sorry, I don't know how to explain it).
The world generator has been updated so it no longer exists.
Old Description(03/27):
Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is "Glacier"(not "falco").
Deleted because there was a screenshot with the same seed value. I'm sorry it's hard to understand.
New Desc(04/21):
You can see most seed values without having to enter these seeds. Biome boundaries can be created, not just rivers. This is unlikely to be normal as it occurs with almost all seed values. Since rivers are likely to be generated at the biome boundary, I think that the reason why rivers are likely to be generated at XZ 0 is that biome boundaries are likely to occur at XZ 0.
Steps to Reproduce:
1.Enter Seed bot 'falco' or 'Glacier' to Create new world.
2.Command '/tp 0 80 0' to Teleport to XZ 0 Pos.
3.Please look at biome border / river.Observed Results:
A river or biome boundary is created in the biome.Expected Results:
It should be generated as the correct biome form (sorry, I don't know how to explain it).I believe this problem has been fixed since world generation was changed in 1.18.0. Please mark this as resolved.
Old Description(03/27):
Most world seed values have a biome boundary at XZ 0.
This will most likely generate a river in XZ 0 in most worlds.
It seems to exist in Java Edition, but it also exists in Bedrock Edition.
Some seed values are not generated, but there is something wrong with the biome selector because they are too likely to be generated.
The seed value for seeing Swamp and river is "Glacier"(not "falco").
Deleted because there was a screenshot with the same seed value. I'm sorry it's hard to understand.
New Desc(04/21):
You can see most seed values without having to enter these seeds. Biome boundaries can be created, not just rivers. This is unlikely to be normal as it occurs with almost all seed values. Since rivers are likely to be generated at the biome boundary, I think that the reason why rivers are likely to be generated at XZ 0 is that biome boundaries are likely to occur at XZ 0.
Steps to Reproduce:
1.Enter Seed bot 'falco' or 'Glacier' to Create new world.
2.Command '/tp 0 80 0' to Teleport to XZ 0 Pos.
3.Please look at biome border / river.Observed Results:
A river or biome boundary is created in the biome.Expected Results:
It should be generated as the correct biome form (sorry, I don't know how to explain it).
– old –
The fall animation has already been removed in Java Edition, but I don't think this is a vanilla parity issue.
Despite the removal of the view bobbing fall animation in 1.14.1, the first person's hand still changes height and orientation at fall speed.
Steps to Reproduce:
1.Open world
2.Enable 'view bobbing' toggle option.
3.Jump / FlyObserved Results:
Both hands move up and downExpected Results:
(Briefly describe what should happen)If your ticket does not look like the example given here, then it's likely to be closed as incomplete.
– old –
The fall animation has already been removed in Java Edition, but I don't think this is a vanilla parity issue.
Despite the removal of the view bobbing fall animation in 1.14.1, the first person's hand still changes height and orientation at fall speed.
Steps to Reproduce:
1.Open world
2.Enable 'view bobbing' toggle option.
3.Jump / FlyObserved Results:
Both hands move up and downExpected Results:
(Briefly describe what should happen)If your ticket does not look like the example given here, then it's likely to be closed as incomplete.
– old –
The fall animation has already been removed in Java Edition, but I don't think this is a vanilla parity issue.
Despite the removal of the view bobbing fall animation in 1.14.1, the first person's hand still changes height and orientation at fall speed.
Steps to Reproduce:
1.Open world
2.Enable 'view bobbing' toggle option.
3.Jump / FlyObserved Results:
Both hands move up and downExpected Results:
(Briefly describe what should happen)
– old –
The fall animation has already been removed in Java Edition, but I don't think this is a vanilla parity issue.
Despite the removal of the view bobbing fall animation in 1.14.1, the first person's hand still changes height and orientation at fall speed.
Steps to Reproduce:
1.Open world
2.Enable 'view bobbing' toggle option.
3.Jump / FlyObserved Results:
Both hands move up and downExpected Results:
(Briefly describe what should happen)– old –
The fall animation has already been removed in Java Edition, but I don't think this is a vanilla parity issue.
Despite the removal of the view bobbing fall animation in 1.14.1, the first person's hand still changes height and orientation at fall speed.
Steps to Reproduce:
1.Open world
2.Enable 'view bobbing' toggle option.
3.Jump / FlyObserved Results:
Both hands move up and downExpected Results:
The top and bottom animations have been removed from the view bobbing, so your hands should stay in their original position without shaking up and down.
– old –
The fall animation has already been removed in Java Edition, but I don't think this is a vanilla parity issue.
Despite the removal of the view bobbing fall animation in 1.14.1, the first person's hand still changes height and orientation at fall speed.
Steps to Reproduce:
1.Open world
2.Enable 'view bobbing' toggle option.
3.Jump / FlyObserved Results:
Both hands move up and downExpected Results:
The top and bottom animations have been removed from the view bobbing, so your hands should stay in their original position without shaking up and down.– old –
The falling animation has already been removed in Java Edition, but I don't think this is a vanilla parity issue.
Despite the removal of the view bobbing fall animation in 1.14.1, the first person's hand still changes height and orientation at fall speed.
Steps to Reproduce:
1.Open world
2.Enable 'view bobbing' toggle option.
3.Jump / FlyObserved Results:
Both hands move up and downExpected Results:
The top and bottom animations have been removed from the view bobbing, so your hands should stay in their original position without shaking up and down.
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.02;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { // why vanilla code was used '9.75'?(v1.16.220+ = Why '1.5'?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.3125", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.
(sorry not good my English...)
test video: https://www.youtube.com/watch?v=HR7j41UmmWg
(This bug report is shown as a clone of
MCPE-54072, but it is completely irrelevant. Don't get me wrong...)
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.02;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { // why vanilla code was used '9.75'?(v1.16.220+ = Why '1.5'?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.3125", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.
(sorry not good my English...)
test video: https://www.youtube.com/watch?v=HR7j41UmmWg
(This bug report is shown as a clone of
MCPE-54072, but it is completely irrelevant. Don't get me wrong...)
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.02;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { // why vanilla code was used '9.75'?(v1.16.220+ = Why '1.5'?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.3125", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.
05/21/21
When I reconfirmed, the symptoms were a little similar.
Some descriptions are quite similar toMCPE-54072, but this bug report is only affected by height.
Bob is hard-coded, so if you have an empty hand, you can either make it unaffected by the hard-coded Bob, remove animation.player.first_person.walk, or disable it from the controller and hard-coded left and right. I need to fix Bob who is too strong (I personally think I should remove the hard-coded Bob to give the creator more freedom).
(sorry not good my English...)
test video: https://www.youtube.com/watch?v=HR7j41UmmWg
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.02;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { // why vanilla code was used '9.75'?(v1.16.220+ = Why '1.5'?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.3125", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.
05/21/21
When I reconfirmed, the symptoms were a little similar.
Some descriptions are quite similar toMCPE-54072, but this bug report is only affected by height.
Bob is hard-coded, so if you have an empty hand, you can either make it unaffected by the hard-coded Bob, remove animation.player.first_person.walk, or disable it from the controller and hard-coded left and right. I need to fix Bob who is too strong (I personally think I should remove the hard-coded Bob to give the creator more freedom).
05/22/21 22:04
I said only the top and bottom bobs, but forgot that the left and right bobs are also included.
Organize the description:
Top and bottom = due to resource pack. The top and bottom hard-coded bob animations overlap with the top and bottom bob animations in the resource pack (this is close toMCPE-54072, so it may not have been necessary to explain here...).
Left / Right = Caused by a hard-coded Bob (BTU / 1.2.0+).
Left / Right = This is due to the resource pack and the hard-coded Bob animation overlapping.
(sorry not good my English...)
test video: https://www.youtube.com/watch?v=HR7j41UmmWg
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and old Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.02;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { // why vanilla code was used '9.75'?(v1.16.220+ = Why '1.5'?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.3125", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.
05/21/21
When I reconfirmed, the symptoms were a little similar.
Some descriptions are quite similar toMCPE-54072, but this bug report is only affected by height.
Bob is hard-coded, so if you have an empty hand, you can either make it unaffected by the hard-coded Bob, remove animation.player.first_person.walk, or disable it from the controller and hard-coded left and right. I need to fix Bob who is too strong (I personally think I should remove the hard-coded Bob to give the creator more freedom).
05/22/21 22:04
I said only the top and bottom bobs, but forgot that the left and right bobs are also included.
Organize the description:
Top and bottom = due to resource pack. The top and bottom hard-coded bob animations overlap with the top and bottom bob animations in the resource pack (this is close toMCPE-54072, so it may not have been necessary to explain here...).
Left / Right = Caused by a hard-coded Bob (BTU / 1.2.0+).
Left / Right = This is due to the resource pack and the hard-coded Bob animation overlapping.
(sorry not good my English...)
test video: https://www.youtube.com/watch?v=HR7j41UmmWg
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and old Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.02;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { // why vanilla code was used '9.75'?(v1.16.220+ = Why '1.5'?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.3125", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.
05/21/21
When I reconfirmed, the symptoms were a little similar.
Some descriptions are quite similar toMCPE-54072, but this bug report is only affected by height.
Bob is hard-coded, so if you have an empty hand, you can either make it unaffected by the hard-coded Bob, remove animation.player.first_person.walk, or disable it from the controller and hard-coded left and right. I need to fix Bob who is too strong (I personally think I should remove the hard-coded Bob to give the creator more freedom).
05/22/21 22:04
I said only the top and bottom bobs, but forgot that the left and right bobs are also included.
Organize the description:
Top and bottom = due to resource pack. The top and bottom hard-coded bob animations overlap with the top and bottom bob animations in the resource pack (this is close toMCPE-54072, so it may not have been necessary to explain here...).
Left / Right = Caused by a hard-coded Bob (BTU / 1.2.0+).
Left / Right= This is due to the resource pack and the hard-coded Bob animation overlapping.
(sorry not good my English...)
test video: https://www.youtube.com/watch?v=HR7j41UmmWg
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and old Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.02;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { // why vanilla code was used '9.75'?(v1.16.220+ = Why '1.5'?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.3125", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.
05/21/21
When I reconfirmed, the symptoms were a little similar.
Some descriptions are quite similar toMCPE-54072, but this bug report is only affected by height.
Bob is hard-coded, so if you have an empty hand, you can either make it unaffected by the hard-coded Bob, remove animation.player.first_person.walk, or disable it from the controller and hard-coded left and right. I need to fix Bob who is too strong (I personally think I should remove the hard-coded Bob to give the creator more freedom).
05/22/21 22:04
I said only the top and bottom bobs, but forgot that the left and right bobs are also included.
Organize the description:
Top and bottom = due to resource pack. The top and bottom hard-coded bob animations overlap with the top and bottom bob animations in the resource pack (this is close toMCPE-54072, so it may not have been necessary to explain here...).
Left / Right = Caused by a hard-coded Bob (BTU / 1.2.0+).
Up / down = This is due to the resource pack and the hard-coded Bob animation overlapping.- Fixed Typo
(sorry not good my English...)
test video: https://www.youtube.com/watch?v=HR7j41UmmWg
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and old Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.02;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { // why vanilla code was used '9.75'?(v1.16.220+ = Why '1.5'?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.3125", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.
05/21/21
When I reconfirmed, the symptoms were a little similar.
Some descriptions are quite similar toMCPE-54072, but this bug report is only affected by height.
Bob is hard-coded, so if you have an empty hand, you can either make it unaffected by the hard-coded Bob, remove animation.player.first_person.walk, or disable it from the controller and hard-coded left and right. I need to fix Bob who is too strong (I personally think I should remove the hard-coded Bob to give the creator more freedom).
05/22/21 22:04
I said only the top and bottom bobs, but forgot that the left and right bobs are also included.
Organize the description:
Top and bottom = due to resource pack. The top and bottom hard-coded bob animations overlap with the top and bottom bob animations in the resource pack (this is close toMCPE-54072, so it may not have been necessary to explain here...).
Left / Right = Caused by a hard-coded Bob (BTU / 1.2.0+).
Up / down = This is due to the resource pack and the hard-coded Bob animation overlapping.- Fixed Typo
06/20/21 18:42
Not only Bob in Y Position, but also X Position has become stronger.(
MCPE-54072)
(sorry not good my English...)
test video: https://www.youtube.com/watch?v=HR7j41UmmWg
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and old Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.02;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { // why vanilla code was used '9.75'?(v1.16.220+ = Why '1.5'?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.3125", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.
05/21/21
When I reconfirmed, the symptoms were a little similar.
Some descriptions are quite similar toMCPE-54072, but this bug report is only affected by height.
Bob is hard-coded, so if you have an empty hand, you can either make it unaffected by the hard-coded Bob, remove animation.player.first_person.walk, or disable it from the controller and hard-coded left and right. I need to fix Bob who is too strong (I personally think I should remove the hard-coded Bob to give the creator more freedom).
05/22/21 22:04
I said only the top and bottom bobs, but forgot that the left and right bobs are also included.
Organize the description:
Top and bottom = due to resource pack. The top and bottom hard-coded bob animations overlap with the top and bottom bob animations in the resource pack (this is close toMCPE-54072, so it may not have been necessary to explain here...).
Left / Right = Caused by a hard-coded Bob (BTU / 1.2.0+).
Up / down = This is due to the resource pack and the hard-coded Bob animation overlapping.- Fixed Typo
06/20/21 18:42
Not only Bob in Y Position, but also X Position has become stronger.(
MCPE-54072)
(sorry not good my English...)
test video: https://www.youtube.com/watch?v=HR7j41UmmWg
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and old Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.15;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { // why vanilla code was used '9.75'?(v1.16.220+ = Why '1.5'?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.0", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.
05/21/21
When I reconfirmed, the symptoms were a little similar.
Some descriptions are quite similar toMCPE-54072, but this bug report is only affected by height.
Bob is hard-coded, so if you have an empty hand, you can either make it unaffected by the hard-coded Bob, remove animation.player.first_person.walk, or disable it from the controller and hard-coded left and right. I need to fix Bob who is too strong (I personally think I should remove the hard-coded Bob to give the creator more freedom).
05/22/21 22:04
I said only the top and bottom bobs, but forgot that the left and right bobs are also included.
Organize the description:
Top and bottom = due to resource pack. The top and bottom hard-coded bob animations overlap with the top and bottom bob animations in the resource pack (this is close toMCPE-54072, so it may not have been necessary to explain here...).
Left / Right = Caused by a hard-coded Bob (BTU / 1.2.0+).
Up / down = This is due to the resource pack and the hard-coded Bob animation overlapping.- Fixed Typo
06/20/21 18:42
Not only Bob in Y Position, but also X Position has become stronger.(
MCPE-54072)
(sorry not good my English...)
test video: https://www.youtube.com/watch?v=HR7j41UmmWg
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and old Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.15;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { // why vanilla code was used '9.75'?(v1.16.220+ = Why '1.5'?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.0", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.
05/21/21
When I reconfirmed, the symptoms were a little similar.
Some descriptions are quite similar toMCPE-54072, but this bug report is only affected by height.
Bob is hard-coded, so if you have an empty hand, you can either make it unaffected by the hard-coded Bob, remove animation.player.first_person.walk, or disable it from the controller and hard-coded left and right. I need to fix Bob who is too strong (I personally think I should remove the hard-coded Bob to give the creator more freedom).
05/22/21 22:04
I said only the top and bottom bobs, but forgot that the left and right bobs are also included.
Organize the description:
Top and bottom = due to resource pack. The top and bottom hard-coded bob animations overlap with the top and bottom bob animations in the resource pack (this is close toMCPE-54072, so it may not have been necessary to explain here...).Left / Right = Caused by a hard-coded Bob (BTU / 1.2.0+).
Up / down = This is due to the resource pack and the hard-coded Bob animation overlapping.- Fixed Typo
06/20/21 18:42
Not only Bob in Y Position, but also X Position has become stronger.(
MCPE-54072)
(sorry not good my English...)
test video: https://www.youtube.com/watch?v=HR7j41UmmWg
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and old Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.15;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { // why vanilla code was used '9.75'?(v1.16.220+ = Why '1.5'?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.0", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.
05/21/21
When I reconfirmed, the symptoms were a little similar.
Some descriptions are quite similar toMCPE-54072, but this bug report is only affected by height.
Bob is hard-coded, so if you have an empty hand, you can either make it unaffected by the hard-coded Bob, remove animation.player.first_person.walk, or disable it from the controller and hard-coded left and right. I need to fix Bob who is too strong (I personally think I should remove the hard-coded Bob to give the creator more freedom).
05/22/21 22:04
I said only the top and bottom bobs, but forgot that the left and right bobs are also included.
Organize the description:
Top and bottom = due to resource pack. The top and bottom hard-coded bob animations overlap with the top and bottom bob animations in the resource pack (this is close toMCPE-54072, so it may not have been necessary to explain here...).
Left / Right = Caused by a hard-coded Bob (BTU / 1.2.0+).
Up / down = This is due to the resource pack and the hard-coded Bob animation overlapping.- Fixed Typo
06/20/21 18:42
Not only Bob in Y Position, but also X Position has become stronger.(
MCPE-54072)06/30/22 01:17
Left and right bobs are stronger was reported in MCPE-64824, so the text was removed.
Only issues that are almost identical toMCPE-54072are described here.The explanation is getting jumbled up, so I will rewrite it when I have time.
(sorry not good my English...)
test video: https://www.youtube.com/watch?v=HR7j41UmmWg
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and old Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.15;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { // why vanilla code was used '9.75'?(v1.16.220+ = Why '1.5'?) "position": ["math.sin(-query.walk_distance * 180.0) * variable.hand_bob *7.0", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.
05/21/21
When I reconfirmed, the symptoms were a little similar.
Some descriptions are quite similar toMCPE-54072, but this bug report is only affected by height.
Bob is hard-coded, so if you have an empty hand, you can either make it unaffected by the hard-coded Bob, remove animation.player.first_person.walk, or disable it from the controller and hard-coded left and right. I need to fix Bob who is too strong (I personally think I should remove the hard-coded Bob to give the creator more freedom).
05/22/21 22:04
I said only the top and bottom bobs, but forgot that the left and right bobs are also included.
Organize the description:
Top and bottom = due to resource pack. The top and bottom hard-coded bob animations overlap with the top and bottom bob animations in the resource pack (this is close toMCPE-54072, so it may not have been necessary to explain here...).
Left / Right = Caused by a hard-coded Bob (BTU / 1.2.0+).
Up / down = This is due to the resource pack and the hard-coded Bob animation overlapping.- Fixed Typo
06/20/21 18:42
Not only Bob in Y Position, but also X Position has become stronger.(
MCPE-54072)06/30/22 01:17
Left and right bobs are stronger was reported in MCPE-64824, so the text was removed.
Only issues that are almost identical toMCPE-54072are described here.The explanation is getting jumbled up, so I will rewrite it when I have time.
(sorry not good my English...)
test video: https://www.youtube.com/watch?v=HR7j41UmmWg
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and old Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.15;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { ?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.0", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.Note: It appears that the 1.14.0 bug has returned from version 1.17.0.
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and old Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.15;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { ?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.0", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.Note: It appears that the 1.14.0 bug has returned from version 1.17.0.
Steps to Reproduce:
1.Enable 'view bobbing' toggle option in video.2.walk on ground.
Observed Results:
Hand bob is too strong than Java Edition and older Bedrock EditionExpected Results:
Must match like Java Edition and old Bedrock Edition.
We have prepared sample code for fixing bugs:
animations/player_firstperson.animation.json
"animation.player.first_person.walk": { // copy here "loop": true, "bones": { // You can get closer to the Java Edition or old Bedrock Edition by preparing a 0.75x hand bob code that is the reverse of the normal direction. // This is enough, as the hard-coded animation will play. "rightArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] }, "leftArm": { "position": [ "math.sin(query.walk_distance * 180) * variable.hand_bob * 0.75", 0.0, 0.0 ] } } }
However, if you go underwater, the animation may be played by mistake. You can improve it by adding this code to variable.hand_bob.
entity/player.entity.json:
"variable.hand_bob = query.life_time < 0.01 ? 0.0 : variable.hand_bob + ((query.is_on_ground && query.is_alive * (1.0 - variable.swim_amount) ? math.clamp(math.sqrt(math.pow(query.position_delta(0), 2.0) + math.pow(query.position_delta(2), 2.0)), 0.0, 0.1) : 0.0) - variable.hand_bob) * 0.15;",
The cause of the bug that makes the top and bottom bobs stronger is that the hard-coded animation and the top and bottom animations coded in the vanilla resource pack are played at the same time.
The problem of stronger left and right hand bobs actually exists from 1.2. It's very annoying.
The top and bottom bob bugs only occur on some items and on empty hands.
These codes only work for items specified by 'attachable', and for empty hands (the animation when holding the item seems to be hard-coded at this time and cannot be changed).These are just samples.
If the empty hand animation is no longer affected by the hard-coded animation, we recommend using the following code:
"animation.player.first_person.walk": { "loop": true, "bones": { "rightArm": { ?) "position": [ "math.sin(-query.walk_distance * 180.0) * variable.hand_bob * 7.0", "-math.abs(math.cos(-query.walk_distance * 180.0)) * variable.hand_bob * 15.0 + variable.short_arm_offset_left", 0.0 ] } } }Finding these files can be very annoying.
The animations player_firstperson.animation.json in the 'vanilla' folder uses 9.75, and 'vanilla_1.16.200' folder is uses 1.5.
This is the cause.Note: It appears that the 1.14.0 bug has returned from version 1.17.0. (
MCPE-54072)
It may be similar to the previously posted
MCPE-120005.But the query is different, so I created a new ticket for the time being.
Steps to Reproduce:
1. Please Enable this Resource pack.
2. Switch First person to Third person
Observed Results:
There is a slight delay. It looks as if it is updated every 2 ticks.Expected Results:
You must always be facing the camera, as it was in 1.12.1 and earlier.
Player animation has nothing to do with it. However, I created a resource pack to make it easier to understand the bug situation.
If you sneak, the "head orientation" will be strange, but this time it doesn't matter, so don't worry. It does not occur in vanilla.
There is a lag in query.head_x_rotation and query.head_y_rotation.
I tried writing (query.head_y_rotation --query.body_y_rotation) to reproduce query.target_y_rotation, but there was a bug that didn't exist in query.target_y_rotation.
I think this is a bug that significantly reduces the freedom of resource packs.
Test Video: https://www.youtube.com/watch?v=FZkMf9yfWuI
Some MoLang queries take about 2 ticks to update (head_x/y_rotation & body_y_rotation and others)
It may be similar to the previously posted
MCPE-120005.But the query is different, so I created a new ticket for the time being.
Steps to Reproduce:
1. Please Enable this Resource pack.
2. Switch First person to Third person
Observed Results:
There is a slight delay. It looks as if it is updated every 2 ticks.Expected Results:
You must always be facing the camera, as it was in 1.12.1 and earlier.
Player animation has nothing to do with it. However, I created a resource pack to make it easier to understand the bug situation.
If you sneak, the "head orientation" will be strange, but this time it doesn't matter, so don't worry. It does not occur in vanilla.
There is a lag in query.head_x_rotation and query.head_y_rotation.
I tried writing (query.head_y_rotation --query.body_y_rotation) to reproduce query.target_y_rotation, but there was a bug that didn't exist in query.target_y_rotation.
I think this is a bug that significantly reduces the freedom of resource packs.
Test Video: https://www.youtube.com/watch?v=FZkMf9yfWuI
We have confirmed that some other queries can have the same behavior.
It may be similar to the previously posted
MCPE-120005.But the query is different, so I created a new ticket for the time being.
Steps to Reproduce:
1. Please Enable this Resource pack.
2. Switch First person to Third person
Observed Results:
There is a slight delay. It looks as if it is updated every 2 ticks.Expected Results:
You must always be facing the camera, as it was in 1.12.1 and earlier.
Player animation has nothing to do with it. However, I created a resource pack to make it easier to understand the bug situation.
If you sneak, the "head orientation" will be strange, but this time it doesn't matter, so don't worry. It does not occur in vanilla.
There is a lag in query.head_x_rotation and query.head_y_rotation.
I tried writing (query.head_y_rotation --query.body_y_rotation) to reproduce query.target_y_rotation, but there was a bug that didn't exist in query.target_y_rotation.
I think this is a bug that significantly reduces the freedom of resource packs.
Test Video: https://www.youtube.com/watch?v=FZkMf9yfWuI
Some MoLang queries take about2ticks to update (head_x/y_rotation & body_y_rotation and others)Some MoLang queries take about 1(0.05sec) ticks to update (head_x/y_rotation & body_y_rotation and others)
animation.player.bob has some problems(Missing animation)
I wrote these as players, but they also affect humanoid mobs.
The number here... in "query.life_time*(here...)" should be 103.13244 instead of 103.2.
So the code looks like this:
"animation.player.bob" : { "loop" : true, "bones" : { "leftarm" : { "rotation" : [ 0.0, 0.0, "-((math.cos(query.life_time * 103.13244) * 2.865) + 2.865)" ] }, "rightarm" : { "rotation" : [ 0.0, 0.0, "(math.cos(query.life_time * 103.13244) * 2.865) + 2.865" ] } } }Also, the X Rotation animation has disappeared.
This issue has been around since 1.2 and Bob on the leftarm is no longer present as of 0.14.0.
This is an issue that hasn't been fixed, even though player animations are now accessible in resource packs in 1.13.0.
You need to insert "Math.sin(query.life_time 76.776372) 2.865" in X Rotation.
The code is below:
"animation.player.bob" : { "loop" : true, "bones" : { "leftarm" : { "rotation" : [ "-Math.sin(query.life_time * 76.776372) * 2.865", 0.0, "-((math.cos(query.life_time * 103.13244) * 2.865) + 2.865)" ] }, "rightarm" : { "rotation" : [ "Math.sin(query.life_time * 76.776372) * 2.865", 0.0, "(math.cos(query.life_time * 103.13244) * 2.865) + 2.865" ] } } }
Also, the leftleg bob was removed in 1.13.0.
To revive the leftleg bob, you need to add the following code:
"leftleg" : { "rotation" : [ "-Math.sin(query.life_time * 76.776372) * 2.865", 0.0, 0.0 ] }So the animation code looks like this:
"animation.player.bob" : { "loop" : true, "bones" : { "leftarm" : { "rotation" : [ "-Math.sin(query.life_time * 76.776372) * 2.865", 0.0, "-((math.cos(query.life_time * 103.13244) * 2.865) + 2.865)" ] }, "rightarm" : { "rotation" : [ "Math.sin(query.life_time * 76.776372) * 2.865", 0.0, "(math.cos(query.life_time * 103.13244) * 2.865) + 2.865" ] }, "leftleg" : { "rotation" : [ "-Math.sin(query.life_time * 76.776372) * 2.865", 0.0, 0.0 ] } } }We know that this bug has a low fix priority, but it's fairly easy to fix.
I hope it will be fixed soon.
Also, the leftleg bob that existed until 1.12.1 may not be a bug but a specification, but it may be a bug, so I have reported it for the time being.
It is set to "Plausible", but you should be able to see that the x rotation is gone from the bob animation, compare it to the Java Edition.
I wrote these as players, but they also affect humanoid mobs.
The number here... in "query.life_time*(here...)" should be 103.13244 instead of 103.2.
So the code looks like this:
"animation.player.bob" : { "loop" : true, "bones" : { "leftarm" : { "rotation" : [ 0.0, 0.0, "-((math.cos(query.life_time * 103.13244) * 2.865) + 2.865)" ] }, "rightarm" : { "rotation" : [ 0.0, 0.0, "(math.cos(query.life_time * 103.13244) * 2.865) + 2.865" ] } } }Also, the X Rotation animation has disappeared.
This issue has been around since 1.2 and Bob on the leftarm is no longer present as of 0.14.0.
This is an issue that hasn't been fixed, even though player animations are now accessible in resource packs in 1.13.0.
You need to insert "Math.sin(query.life_time 76.776372) 2.865" in X Rotation.
The code is below:
"animation.player.bob" : { "loop" : true, "bones" : { "leftarm" : { "rotation" : [ "-Math.sin(query.life_time * 76.776372) * 2.865", 0.0, "-((math.cos(query.life_time * 103.13244) * 2.865) + 2.865)" ] }, "rightarm" : { "rotation" : [ "Math.sin(query.life_time * 76.776372) * 2.865", 0.0, "(math.cos(query.life_time * 103.13244) * 2.865) + 2.865" ] } } }
Also, the leftleg bob was removed in 1.13.0.
To revive the leftleg bob, you need to add the following code:
"leftleg" : { "rotation" : [ "-Math.sin(query.life_time * 76.776372) * 2.865", 0.0, 0.0 ] }So the animation code looks like this:
"animation.player.bob" : { "loop" : true, "bones" : { "leftarm" : { "rotation" : [ "-Math.sin(query.life_time * 76.776372) * 2.865", 0.0, "-((math.cos(query.life_time * 103.13244) * 2.865) + 2.865)" ] }, "rightarm" : { "rotation" : [ "Math.sin(query.life_time * 76.776372) * 2.865", 0.0, "(math.cos(query.life_time * 103.13244) * 2.865) + 2.865" ] }, "leftleg" : { "rotation" : [ "-Math.sin(query.life_time * 76.776372) * 2.865", 0.0, 0.0 ] } } }We know that this bug has a low fix priority, but it's fairly easy to fix.
I hope it will be fixed soon.
Also, the leftleg bob that existed until 1.12.1 may not be a bug but a specification, but it may be a bug, so I have reported it for the time being.
It is set to "Plausible", but you should be able to see that the x rotation is gone from the bob animation, compare it to the Java Edition.
It appears that the removal of the leftleg animation was an intentional change.
I wrote these as players, but they also affect humanoid mobs.
The number here... in "query.life_time*(here...)" should be 103.13244 instead of 103.2.
So the code looks like this:
"animation.player.bob" : { "loop" : true, "bones" : { "leftarm" : { "rotation" : [ 0.0, 0.0, "-((math.cos(query.life_time * 103.13244) * 2.865) + 2.865)" ] }, "rightarm" : { "rotation" : [ 0.0, 0.0, "(math.cos(query.life_time * 103.13244) * 2.865) + 2.865" ] } } }Also, the X Rotation animation has disappeared.
This issue has been around since 1.2 and Bob on the leftarm is no longer present as of 0.14.0.
This is an issue that hasn't been fixed, even though player animations are now accessible in resource packs in 1.13.0.
You need to insert "Math.sin(query.life_time 76.776372) 2.865" in X Rotation.
The code is below:
"animation.player.bob" : { "loop" : true, "bones" : { "leftarm" : { "rotation" : [ "-Math.sin(query.life_time * 76.776372) * 2.865", 0.0, "-((math.cos(query.life_time * 103.13244) * 2.865) + 2.865)" ] }, "rightarm" : { "rotation" : [ "Math.sin(query.life_time * 76.776372) * 2.865", 0.0, "(math.cos(query.life_time * 103.13244) * 2.865) + 2.865" ] } } }
Also, the leftleg bob was removed in 1.13.0.
To revive the leftleg bob, you need to add the following code:
"leftleg" : { "rotation" : [ "-Math.sin(query.life_time * 76.776372) * 2.865", 0.0, 0.0 ] }So the animation code looks like this:
"animation.player.bob" : { "loop" : true, "bones" : { "leftarm" : { "rotation" : [ "-Math.sin(query.life_time * 76.776372) * 2.865", 0.0, "-((math.cos(query.life_time * 103.13244) * 2.865) + 2.865)" ] }, "rightarm" : { "rotation" : [ "Math.sin(query.life_time * 76.776372) * 2.865", 0.0, "(math.cos(query.life_time * 103.13244) * 2.865) + 2.865" ] }, "leftleg" : { "rotation" : [ "-Math.sin(query.life_time * 76.776372) * 2.865", 0.0, 0.0 ] } } }We know that this bug has a low fix priority, but it's fairly easy to fix.
I hope it will be fixed soon.
Also, the leftleg bob that existed until 1.12.1 may not be a bug but a specification, but it may be a bug, so I have reported it for the time being.
It is set to "Plausible", but you should be able to see that the x rotation is gone from the bob animation, compare it to the Java Edition.
It appears that the removal of the leftleg animation was an intentional change.
Steps to Reproduce:
1.Join World
2.look third person arm bob animationObserved Results:
No up-and-down swaying, only side-to-side swayingExpected Results:
Rocking up and down just like Java Edition.
I wrote these as players, but they also affect humanoid mobs.
The number here... in "query.life_time*(here...)" should be 103.13244 instead of 103.2.
So the code looks like this:
"animation.player.bob" : { "loop" : true, "bones" : { "leftarm" : { "rotation" : [ 0.0, 0.0, "-((math.cos(query.life_time * 103.13244) * 2.865) + 2.865)" ] }, "rightarm" : { "rotation" : [ 0.0, 0.0, "(math.cos(query.life_time * 103.13244) * 2.865) + 2.865" ] } } }Also, the X Rotation animation has disappeared.
This issue has been around since 1.2 and Bob on the leftarm is no longer present as of 0.14.0.
This is an issue that hasn't been fixed, even though player animations are now accessible in resource packs in 1.13.0.
It is set to "Plausible", but you should be able to see that the x rotation is gone from the bob animation, compare it to the Java Edition.
It appears that the removal of the leftleg animation was an intentional change.
This is a bug that has existed since 1.16.210, when attachable items were implemented. The "breathing bob" of items with attachables applied (bows in vanilla (currently not noticeable due to other bugs), shields, tridents, crossbows, and spyglass) appear to bob up and down slowly. It appears to be slower than the default items and too large. Also, you can adjust the speed by changing the "n" in Math.sin(query.life_time * n), but due to the specification of query.life_time, it will be out of sync with other items. Also, there is a lack of X Rotation Animation.
Vanilla:
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.sin(q.life_time * 45.0) * 0.5", 0.0 ] }Fixed(I don't know if this is correct or not, as I just identified the values from the animation times of other items.)
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.cos(query.life_time * 115.385) * 0.1", 0.0 ], "rotation: [ "variable.bob_animation * Math.cos(query.life_time * 115.385) * 0.05", 0.0, 0.0 ] }
This is a bug that has existed since 1.16.210, when attachable items were implemented. The "breathing bob" of items with attachables applied (bows in vanilla (currently not noticeable due to other bugs), shields, tridents, crossbows, and spyglass) appear to bob up and down slowly. It appears to be slower than the default items and too large. Also, you can adjust the speed by changing the "n" in Math.sin(query.life_time * n), but due to the specification of query.life_time, it will be out of sync with other items. Also, there is a lack of X Rotation Animation.
Vanilla:
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.sin(q.life_time * 45.0) * 0.5", 0.0 ] }Fixed(I don't know if this is correct or not, as I just identified the values from the animation times of other items.)
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.cos(query.life_time * 115.385) * 0.1", 0.0 ], "rotation: [ "variable.bob_animation * Math.cos(query.life_time * 115.385) * 0.05", 0.0, 0.0 ] }
Test Video: https://www.youtube.com/watch?v=uRlkIqOqxOU
First Person's Attachable Item's Breathing Bob appears to be bobbing up and downloudlyand slowly.
This is a bug that has existed since 1.16.210, when attachable items were implemented. The "breathing bob" of items with attachables applied (bows in vanilla (currently not noticeable due to other bugs), shields, tridents, crossbows, and spyglass) appear to bob up and down slowly. It appears to be slower than the default items and too large. Also, you can adjust the speed by changing the "n" in Math.sin(query.life_time * n), but due to the specification of query.life_time, it will be out of sync with other items. Also, there is a lack of X Rotation Animation.
Vanilla:
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.sin(q.life_time * 45.0) * 0.5", 0.0 ] }Fixed(I don't know if this is correct or not, as I just identified the values from the animation times of other items.)
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.cos(query.life_time * 115.385) * 0.1", 0.0 ], "rotation: [ "variable.bob_animation * Math.cos(query.life_time * 115.385) * 0.05", 0.0, 0.0 ] }
Test Video: https://
www.youtube.com/watch?v=uRlkIqOqxOUThis is a bug that has existed since 1.16.210, when attachable items were implemented. The "breathing bob" of items with attachables applied (bows in vanilla (currently not noticeable due to other bugs), shields, tridents, crossbows, and spyglass) appear to bob up and down slowly. It appears to be slower than the default items and too large. Also, you can adjust the speed by changing the "n" in Math.sin(query.life_time * n), but due to the specification of query.life_time, it will be out of sync with other items. Also, there is a lack of X Rotation Animation.
Vanilla:
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.sin(q.life_time * 45.0) * 0.5", 0.0 ] }Fixed(I don't know if this is correct or not, as I just identified the values from the animation times of other items.)
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.cos(query.life_time * 115.385) * 0.1", 0.0 ], "rotation: [ "variable.bob_animation * Math.cos(query.life_time * 115.385) * 0.05", 0.0, 0.0 ] }
Test Video: https://youtu.be/3mS1VQuXxAE
This is a bug that has existed since 1.16.210, when attachable items were implemented. The "breathing bob" of items with attachables applied (bows in vanilla (currently not noticeable due to other bugs), shields, tridents, crossbows, and spyglass) appear to bob up and down slowly. It appears to be slower than the default items and too large. Also, you can adjust the speed by changing the "n" in Math.sin(query.life_time * n), but due to the specification of query.life_time, it will be out of sync with other items. Also, there is a lack of X Rotation Animation.
Vanilla:
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.sin(q.life_time * 45.0) * 0.5", 0.0 ] }Fixed(I don't know if this is correct or not, as I just identified the values from the animation times of other items.)
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.cos(query.life_time * 115.385) * 0.1", 0.0 ],"rotation: [ "variable.bob_animation *Math.cos(query.life_time * 115.385) *0.05", 0.0, 0.0 ] }
Test Video: https://youtu.be/3mS1VQuXxAE
This is a bug that has existed since 1.16.210, when attachable items were implemented. The "breathing bob" of items with attachables applied (bows in vanilla (currently not noticeable due to other bugs), shields, tridents, crossbows, and spyglass) appear to bob up and down slowly. It appears to be slower than the default items and too large. Also, you can adjust the speed by changing the "n" in Math.sin(query.life_time * n), but due to the specification of query.life_time, it will be out of sync with other items. Also, there is a lack of X Rotation Animation.
Vanilla:
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.sin(q.life_time * 45.0) * 0.5", 0.0 ] }Fixed(I don't know if this is correct or not, as I just identified the values from the animation times of other items.)
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.cos(query.life_time * (180 / Math.Pi)) * 0.1", 0.0 ], "rotation: [ "variable.bob_animation * Math.cos(query.life_time * (180 / Math.PI)) * 0.05", 0.0, 0.0 ] }
Test Video: https://youtu.be/3mS1VQuXxAE
This is a bug that has existed since 1.16.210, when attachable items were implemented. The "breathing bob" of items with attachables applied (bows in vanilla (currently not noticeable due to other bugs), shields, tridents, crossbows, and spyglass) appear to bob up and down slowly. It appears to be slower than the default items and too large. Also, you can adjust the speed by changing the "n" in Math.sin(query.life_time * n), but due to the specification of query.life_time, it will be out of sync with other items. Also, there is a lack of X Rotation Animation.
Vanilla:
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.sin(q.life_time * 45.0) * 0.5", 0.0 ] }Fixed(I don't know if this is correct or not, as I just identified the values from the animation times of other items.)
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.cos(query.life_time * (180 / Math.Pi)) * 0.1", 0.0 ], "rotation: [ "variable.bob_animation * Math.cos(query.life_time * (180 / Math.PI)) * 0.05", 0.0, 0.0 ] }
Test Video: https://youtu.be/3mS1VQuXxAE
This is a bug that has existed since 1.16.210, when attachable items were implemented. The "breathing bob" of items with attachables applied (bows in vanilla (currently not noticeable due to other bugs), shields, tridents, crossbows, and spyglass) appear to bob up and down slowly. It appears to be slower than the default items and too large. Also, you can adjust the speed by changing the "n" in Math.sin(query.life_time * n), but due to the specification of query.life_time, it will be out of sync with other items. Also, there is a lack of X Rotation Animation.
Vanilla:
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.sin(q.life_time * 45.0) * 0.5", 0.0 ] }Fixed(I don't know if this is correct or not, as I just identified the values from the animation times of other items.)
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.cos(query.life_time * (180 / Math.Pi)) * 0.1", 0.0 ], "rotation: [ "variable.bob_animation * Math.cos(query.life_time * (180 / Math.PI)) * Math.sqrt(2)", 0.0, 0.0 ] }
Test Video: https://youtu.be/3mS1VQuXxAE
This is a bug that has existed since 1.16.210, when attachable items were implemented. The "breathing bob" of items with attachables applied (bows in vanilla (currently not noticeable due to other bugs), shields, tridents, crossbows, and spyglass) appear to bob up and down slowly. It appears to be slower than the default items and too large. Also, you can adjust the speed by changing the "n" in Math.sin(query.life_time * n), but due to the specification of query.life_time, it will be out of sync with other items. Also, there is a lack of X Rotation Animation.
Vanilla:
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.sin(q.life_time * 45.0) * 0.5", 0.0 ] }Fixed(I don't know if this is correct or not, as I just identified the values from the animation times of other items.)
180 / Math.Pi)) * 0.1", 0.0 ], "rotation: [ "variable.bob_animation * Math.cos(query.life_time * (180 / Math.PI)) * Math.sqrt(2)", 0.0, 0.0 ] }
Test Video: https://youtu.be/3mS1VQuXxAE
This is a bug that has existed since 1.16.210, when attachable items were implemented. The "breathing bob" of items with attachables applied (bows in vanilla (currently not noticeable due to other bugs), shields, tridents, crossbows, and spyglass) appear to bob up and down slowly. It appears to be slower than the default items and too large. Also, you can adjust the speed by changing the "n" in Math.sin(query.life_time * n), but due to the specification of query.life_time, it will be out of sync with other items. Also, there is a lack of X Rotation Animation.
Vanilla:
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.sin(q.life_time * 45.0) * 0.5", 0.0 ] }Fixed
(I don't know if this is correct or not, as I just identified the values from the animation times of other items.)
We have updated the code in the description as we have found more accurate numbers than before.
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.cos(query.life_time * (360 / Math.Pi)) * 0.1", 0.0 ], "rotation: [ "variable.bob_animation * Math.cos(query.life_time * (360 / Math.PI)) * Math.sqrt(2)", 0.0, 0.0 ] }
Test Video: https://youtu.be/3mS1VQuXxAE
(Sorry for the multiple edits. I had to re-edit many times because I forgot how to write or update some of the code.)
This is a bug that has existed since 1.16.210, when attachable items were implemented. The "breathing bob" of items with attachables applied (bows in vanilla (currently not noticeable due to other bugs), shields, tridents, crossbows, and spyglass) appear to bob up and down slowly. It appears to be slower than the default items and too large. Also, you can adjust the speed by changing the "n" in Math.sin(query.life_time * n), but due to the specification of query.life_time, it will be out of sync with other items. Also, there is a lack of X Rotation Animation.
Vanilla:
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.sin(q.life_time * 45.0) * 0.5", 0.0 ] }Fixed
(I don't know if this is correct or not, as I just identified the values from the animation times of other items.)
We have updated the code in the description as we have found more accurate numbers than before.
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.cos(query.life_time * (360 / Math.Pi)) * 0.1", 0.0 ], "rotation: [ "variable.bob_animation * Math.cos(query.life_time * (360 / Math.PI)) * Math.sqrt(2)", 0.0, 0.0 ] }
Test Video: https://youtu.be/3mS1VQuXxAE
(Sorry for the multiple edits. I had to re-edit many times because I forgot how to write or update some of the code.)
This is a bug that has existed since 1.16.210, when attachable items were implemented. The "breathing bob" of items with attachables applied (bows in vanilla (currently not noticeable due to other bugs), shields, tridents, crossbows, and spyglass) appear to bob up and down slowly. It appears to be slower than the default items and too large. Also, you can adjust the speed by changing the "n" in Math.sin(query.life_time * n), but due to the specification of query.life_time, it will be out of sync with other items. Also, there is a lack of X Rotation Animation.
Vanilla:
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.sin(q.life_time * 45.0) * 0.5", 0.0 ] }Fixed
(I don't know if this is correct or not, as I just identified the values from the animation times of other items.)
We have updated the code in the description as we have found more accurate numbers than before.
"rightitem": { "position": [ 0.0, "variable.bob_animation * math.cos(query.life_time * (360 / Math.Pi)) * 0.1", 0.0 ], "rotation: [ "variable.bob_animation * Math.cos(query.life_time * (360 / Math.PI)) * Math.sqrt(2)", 0.0, 0.0 ] }
Test V
(Sorry for the multiple edits. I had to re-edit many times because I forgot how to write or update some of the code.)
「スペクテイターモード」と呼ばれる実験的なゲームプレイオプションが有効になっている場合、腕は表示されないようです。
スペクテイターモードの実験的なゲームプレイ専用のリソースパックに含まれるプレーヤーアニメーションコントローラーとレンダリングコントローラーは、vanilla_1.19.10の変更をまだ適用していません。
From 1.2, the left and right sway of the view bobbing has become more intense, but it has been fixed by the adjustment of 1.13.1.
The difference in view bobbing from 1.14.1 to the present is that the up and down sway seems to be the exact opposite of Java Edition / Bedrock Edition 1.12.1. Also, view bobbing is affected by direction, so if you look down or up, you'll see the (camera) Y coordinate swinging up and down (honestly it looks good, but it's a bug).
In Java Edition, it turns to shake its head up and down. As the camera goes up, it looks like it's going down little by little. It was removed in 1.14.1, but since 1.13 it has been rocking in the opposite direction of Java Edition.
The camera animation when jumping has been removed in Java Edition 1.14, so it's normal (I don't know why the first person hand goes up or down...).
Also, after the camera shakes, it returns too slowly to its original position. This can have a slight impact on gameplay.
The slightly tilted camera (rotation z to put it simply) animation is also too weak compared to Java Edition / Bedrock Edition 1.12.1 and earlier (Is it due to the view bobbing adjustment in 1.13.1?).
The Java Edition hand bob should shake due to the effect of view bobbing, so it is recommended to modify it to match the hand bob.
I hope the old view bobbing is back...
Even if these changes are planned changes, I think they are the worst changes (I honestly think they are bugs).
Addition:
When sneaking, I would like to ask you to return the specifications so that the camera will shift even if you go to the corner of the block and the player stops.
Addition(2):
If the developer is not willing to fix it, I hope that it can be changed by resource pack etc. and that the resource pack creator can make changes and fix it. (type miss fix)
Addition(4):
The swaying Bob actually exists in the Java Edition and the older Bedrock Edition.
Diagonal swaying is the exact opposite of 1.12.0, which may make Bob look even stronger. (Bob has a strong bug for a long time)
I'm sorry for making many additions...
oh sorry.
There is a bug that is cut slightly as of 1.11.0.
This seems to occur because the change from 1.13 causes the hand to return to its original position too slowly.
The bug itself has been around since 0.16.0.
The resource pack is not left because I deleted it myself because updating 1.16.210 was troublesome.
But you should be able to see it in vanilla.
I just noticed. I made a mistake in the name of the direction.
I don't think it's a bug because current Minecraft can't edit animations for all items except bows, shields, crossbows, and tridents.
can change it by using the "attachable" folder.
@EVGENSYPERPRO
No, this is due to the ability to change the shield's model, animation, position, etc. (Added Attachable. can change item animation, model, position, and more.).
The banner doesn't matter at all.
Will occur again 1.17.0
Affects 1.17.2 Hot Fix
Probably a specification.
It's too slow to fix, and I think the Legacy Console Edition used the old splash sound.
Bedrock Edition is close to Legacy Console Edition (with some parity), so it may be a specification.
If there is a difference in vanilla parity, we recommend that you send it as feedback.
If it is a bug, I hope it will be fixed as soon as possible.
It is very likely that the server-side player entity and the client-side player entity are ringing separately.
The bottom line is that the "player" entity on the client side of the player and the "player" entity on the server side go into the water and the splash sound is played separately at the same time.
If the lag is severe, the second play will be delayed.
@Shaughn Williamson
No, the change in arm position and orientation is due to the player's animation being changeable in the resource pack.
It has not been completely restored. Most animation bugs are caused by porting to resource packs.
I confirmed that the white heart is displayed only for a moment!
If the damage flashing is fixed, it will be completely fixed.
(Probably only if the "Cave and Cliffs" toggle is enabled)
The symptoms are still present in the current version because the code has not been updated in the first place.
Have you really checked Bob's animations and code, you should be able to see the difference compared to the Java Edition and the old Bedrock Edition.
Of course it affects you. Have you really checked MoLang?
It's especially noticeable with query.target_x_rotation, etc. When you move the head, there is a slight delay before it aligns with the camera orientation.
This may affect queries such as position, which gets the player's coordinates, etc.
The way to fix this bug should be very easy, but it has been neglected for over a year.
The "get_equipped_item_name" to get the item you have is still using "map" even though the map ID was changed in 1.16.100. In 1.16.100 and above, it has been changed to "filled_map", so please change all "maps" to Please change all "map" to "filled_map".
It should be very easy.
Oops, my lack of confirmation.
It may have something to do with
MCPE-153350.It appears that when the experimental gameplay option called "Spectator Mode" is enabled, the arms are not visible.
The player animation controllers and render controllers in the resource pack dedicated to the experimental gameplay of Spectator Mode have not yet applied the changes in vanilla_1.19.10.