MCPE-189187Invalid query.get_default_bone_pivot output is indistinguishable from valid output in animations
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack: invalid_vs_valid_query_tester.mcpack
- Understand the sample resource pack:
- Screenshot:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- The default value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- The leg rotation while walking has been made more dramatic to prove the animation is working.
- Screenshot:
- Ignore the content errors on the main menu and pause menu. These are not related to the issue. The animation will work fine in-game, as seen in Step 7.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe the dramatic swinging, indicating the animation has been applied successfully.
- Observe that both legs are in the normal position below the body.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);
This line would use the value returned by the query unless it is invalid, in which case the 30.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
To Fix
Make query.get_default_bone_pivot return "null" instead of 0 for invalid calls.
Linked Issues
Created Issue:
Invalid get_default_bone_pivot output is indistinguishable from valid output in animations
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce{}{}
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- This value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe that both legs are in the normal position.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(query.get_default_bone_pivot('leftarm',1) ?? 22.0)This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce{}{}
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- This value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe that both legs are in the normal position.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(query.get_default_bone_pivot('leftarm',1) ?? 22.0)This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- This value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe that both legs are in the normal position.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(query.get_default_bone_pivot('leftarm',1) ?? 22.0)This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- This value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe that both legs are in the normal position.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(query.get_default_bone_pivot('leftarm',1) ?? 22.0)This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- This value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe that both legs are in the normal position.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(query.get_default_bone_pivot('leftarm',1) ?? 22.0)This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- This value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe that both legs are in the normal position.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- Th
isvalue should raise the leg above the player's head to indicate a problem with the query.- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe that both legs are in the normal position.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- The default value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe that both legs are in the normal position.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- The default value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- The leg rotation while walking has been made more dramatic to prove the animation is working.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe the dramatic swinging, indicating the pack has been applied successfully.
- Observe that both legs are in the normal position below the body.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- The default value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- The leg rotation while walking has been made more dramatic to prove the animation is working.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe the dramatic swinging, indicating the pack has been applied successfully.
- Observe that both legs are in the normal position below the body.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- Screenshot:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- The default value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- The leg rotation while walking has been made more dramatic to prove the animation is working.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe the dramatic swinging, indicating the pack has been applied successfully.
- Observe that both legs are in the normal position below the body.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- Screenshot:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- The default value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- The leg rotation while walking has been made more dramatic to prove the animation is working.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe the dramatic swinging, indicating the
packhas been applied successfully.- Observe that both legs are in the normal position below the body.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- Screenshot:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- The default value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- The leg rotation while walking has been made more dramatic to prove the animation is working.
- Ignore the content errors on the main menu and pause menu. These are not related to the issue. The animation will work fine in-game, as seen in Step 7.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe the dramatic swinging, indicating the animation has been applied successfully.
- Observe that both legs are in the normal position below the body.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack:
- Understand the sample resource pack:
- Screenshot:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- The default value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- The leg rotation while walking has been made more dramatic to prove the animation is working.
- Ignore the content errors on the main menu and pause menu. These are not related to the issue. The animation will work fine in-game, as seen in Step 7.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe the dramatic swinging, indicating the animation has been applied successfully.
- Observe that both legs are in the normal position below the body.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack: invalid_vs_valid_query_tester.mcpack
- Understand the sample resource pack:
- Screenshot:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- The default value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- The leg rotation while walking has been made more dramatic to prove the animation is working.
- Ignore the content errors on the main menu and pause menu. These are not related to the issue. The animation will work fine in-game, as seen in Step 7.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe the dramatic swinging, indicating the animation has been applied successfully.
- Observe that both legs are in the normal position below the body.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack: invalid_vs_valid_query_tester.mcpack
- Understand the sample resource pack:
- Screenshot:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- The default value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- The leg rotation while walking has been made more dramatic to prove the animation is working.
- Ignore the content errors on the main menu and pause menu. These are not related to the issue. The animation will work fine in-game, as seen in Step 7.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe the dramatic swinging, indicating the animation has been applied successfully.
- Observe that both legs are in the normal position below the body.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);This line would use the value returned by the query unless it is invalid, in which case the 22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
To Fix
Make query.get_default_bone_pivot return "null" instead of 0 for invalid calls.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack: invalid_vs_valid_query_tester.mcpack
- Understand the sample resource pack:
- Screenshot:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- The default value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- The leg rotation while walking has been made more dramatic to prove the animation is working.
- Ignore the content errors on the main menu and pause menu. These are not related to the issue. The animation will work fine in-game, as seen in Step 7.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe the dramatic swinging, indicating the animation has been applied successfully.
- Observe that both legs are in the normal position below the body.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);This line would use the value returned by the query unless it is invalid, in which case the
22.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
To Fix
Make query.get_default_bone_pivot return "null" instead of 0 for invalid calls.
When using query.get_default_bone_pivot in an animation in a resource pack, it is impossible to tell whether an output of 0 is due to an invalid call or a valid call which resulted in 0. This is because an invalid call also returns 0, when it should be returning "null".
If this were fixed, it would provide resource packs a way to avoid the problem described in my comment on MCPE-126660: "On some devices, Minecraft references the cape geometry instead of the player geometry when running q.get_default_bone_pivot, which fails because the left and right arms are not listed in this geometry."
If packs could distinguish between a valid 0 output and a 0 output due to an invalid call, we could detect when Minecraft incorrectly queries cape geometry and use a fallback "default" value instead. Some skin types have valid bone pivots of 0, so detecting a 0 output is not sufficient to differentiate between valid and invalid output.
To Reproduce
- Apply the attached sample resource pack: invalid_vs_valid_query_tester.mcpack
- Understand the sample resource pack:
- Screenshot:
- The left leg walking animation will query an invalid bone: "i_do_not_exist".
- The right leg walking animation will query a valid bone: "rightleg", and the requested pivot value is 0 in the wide-arm custom skin model.
- The null coalescing operator provides a default value for both legs. If a query fails, the default value should take its place. (See Expected Result)
- The default value should raise the leg above the player's head to indicate a problem with the query.
- When the player starts walking:
- The left leg query will fail, as i_do_not_exist is not a real bone.
- The right leg query will succeed, as rightleg is a real bone.
- The built-in null coalescing value should be used for the left leg, raising it above the player's head, but should not be used for the right leg, as the query was successful.
- The leg rotation while walking has been made more dramatic to prove the animation is working.
- Ignore the content errors on the main menu and pause menu. These are not related to the issue. The animation will work fine in-game, as seen in Step 7.
- Enter a world.
- Switch to third-person back camera.
- Start walking.
- Observe the dramatic swinging, indicating the animation has been applied successfully.
- Observe that both legs are in the normal position below the body.
- Notice that this means our failed query was not processed as invalid output (null), but as a valid 0.
- Notice this means that valid and invalid 0s cannot be distinguished from this query's output.
Expected Result
An invalid query.get_default_bone_pivot call returns "null", so the null coalescing operator can be used to configure a fallback value in invalid cases:
(variable.pivot = query.get_default_bone_pivot('i_do_not_exist',2); return (variable.pivot ?? 30.0);This line would use the value returned by the query unless it is invalid, in which case the 30.0 value would be used instead. Minecraft includes a MoLang "fixer" which processes "null" values as 0 for math already, so this will not break existing packs.
Observed Result
An invalid query.get_default_bone_pivot call returns 0, in the same way as a valid call. The null coalescing operator is unusable. Adding a "fallback value" is impossible because you cannot distinguish between a valid output of 0 and an invalid call.
To Fix
Make query.get_default_bone_pivot return "null" instead of 0 for invalid calls.
Invalid query.get_default_bone_pivot output is indistinguishable from valid output in animations
![[Mod] LateLag](../../../data/avatars/users/92884.png){kind=small}
![[Mod] GoldenHelmet](../../../data/avatars/users/18951.svg){kind=small}