query-is_hungry
- query-is_hungry
- JIRAUSER733262
- Europe/Stockholm
- Yes
- No
MCPE-176607
When using queries like query.ground_speed and query.vertical_speed on non-local players, the output of those queries will continuously flop from its real speed all the way down to zero, which ends up giving the client untrue values and makes it difficult for creators to work with them on resource packs.
The way this should work is:
These queries should consistently return their actual value at all times and not erratically drop down to zero when zero should not be its true output.
An example of this is the video with the pig in it. These queries don't seem to have a problem giving off consistent values from entities.
Demonstration:
A couple of videos have been attached to this issue to demonstrate how these queries suddenly return false values real time.
In order to visually demonstrate this bug, I've created a resource pack which is attached to this issue
[[^bug_demonstration.mcpack]]. It uses particles right next to our characters to represent the values that these queries return (I applied these particles to playes and pigs). It uses a blue bar to represent our character's overall speed (query.ground_speed's output), and one red arrow to represent our character's vertical direction (query.vertical_speed's positive or negative output).All of it can be replicated by simply walking and/or jumping around from a non-local player on a multiplayer world (or realm).
When using queries like query.ground_speed and query.vertical_speed on non-local players, the output of those queries will continuously flop from its real speed all the way down to zero, which ends up giving the client untrue values and makes it difficult for creators to work with them on resource packs.
The way this should work is:
These queries should consistently return their actual value at all times and not erratically drop down to zero when zero should not be its true output.
An example of this is the video with the pig in it. These queries don't seem to have a problem giving off consistent values from entities. consistent speed values.mp4
Demonstration:
A couple of videos have been attached to this issue to demonstrate how these queries suddenly return false values real time.
In order to visually demonstrate this bug, I've created a resource pack which is attached to this issue bug_demonstration-1.mcpack
. It uses particles right next to our characters to represent the values that these queries return (I applied these particles to playes and pigs). It uses a blue bar to represent our character's overall speed (query.ground_speed's output), and one red arrow to represent our character's vertical direction (query.vertical_speed's positive or negative output).
All of it can be replicated by simply walking and/or jumping around from a non-local player on a multiplayer world (or realm).
Current bug:
Shield patterns stop displaying entirely once a new shield geometry replaces the vanilla one within a resource pack, even if both geometries are identical.The way it should work:
Shield Patterns should still be displayed when a resource pack changes the geometry of the shield.Bug demonstration:
A Shield_patterns_bug.mcpackCurrent bug:
Shield patterns stop displaying entirely once a new shield geometry replaces the vanilla one within a resource pack, even if both geometries are identical.The way it should work:
Shield Patterns should still be displayed when a resource pack changes the geometry of the shield.Bug demonstration:
A Resource PackShield_patterns_bug.mcpack
Current bug:
Shield patterns stop displaying entirely once a new shield geometry replaces the vanilla one within a resource pack, even if both geometries are identical.The way it should work:
Shield Patterns should still be displayed when a resource pack changes the geometry of the shield.Bug demonstration:
A Resource Pack (Shield_patterns_bug.mcpack
Expected Results:
Villagers should sprint away fromRavagers within 12 blocks.Actual Results:
Villagers do not sprint away from Ravagers unless they get hit by them. Even then, the "is_avoiding_mobs" query will read 0 in this scenario.Expected Results:
Villagers should sprint away from creatures that are hostile toward them when they get near them. They should run away from Zombies and all Illagers (including Ravagers).Actual Results:
Villagers do not sprint away from Ravagers unless they get hit by them. Even then, the "is_avoiding_mobs" query will read 0 in this scenario.
1.20.31 (the way particles should look).mp4
Water splash particles pop up above the water when the player enters it (this is indeed a duplicate)
I've also found out about this issue. Today I was changing some custom variables from a resource pack I'm making, and I decided to use this query function as well. Turns out, just by setting up a custom pre-animation variable with this query in it the bug will appear each time a menu character is rendered... as if those weren't considered entities or something. Very odd.
Also, I hope you are having a good day dear person who hopefully reads my comment
I forgot to mention, I'm on the latest version, which is 1.19.41
Someone please change the description. What actually triggers this bug is having a 'player.entity.json' file in the resource pack. Animations have nothing to do with this. Even if you download the sample resource pack from their official github, or extract the original files (via other methods) and try use an unmodified 'player.entity.json' file, the same bug will happen.
I think this works as intended. However, a simple pause button would be great
It is offset by exactly 48 pixels at a resolution of 256, but in your case, it is double that due to the higher resolution. Good bug report!
This issue affects other mobs as well, I've recorded a video with the ones I could find. All of them are coincidently big mobs. I tried many more, but i could only replicate the bug with:
-Iron golem
-Hoglin/Zoglin
-Ravager
-Warden
We could add to that list:
-minecraft:arrow
-minecraft:egg
-minecraft:ender_pearl
-minecraft:lingering_potion
-minecraft:snowball
-minecraft:splash_potion
All of these also share a namespace with an entity. The way to fix this is properly done in scenarios like:
-'minecraft:firework_rocket' (which is the name of the item) and
-'minecraft:fireworks_rocket' (which is the name of the entity).
Just by adding a letter you gave us two different namespaces for two different things, which is perfect. Something similar is done with bottles of enchanting:
-'minecraft:experience_bottle' (item)
-'minecraft:xp_bottle' (entity)
I would suggest changing namespaces of the entities involved, since changing item names would probably break more things? Or alternatively make it so that the game recognizes "minecraft:attachable": {} as what it is, and not as entities.
As much as I hate this, I believe it works as intended.
This issue is already being tracked in
MCPE-117062, and it has been duplicated about a hundred times.Also, I'm afraid to tell you, you won't receive any personal help to recover your world form any moderators, since this is not a help center. But you may seek for some assistance maybe within Community Support.
It is not very clear to me what is expected to occur if this "issue" was fixed. Also, it might be useful to attach the resource packs presumably used to replicate this issue within it. Remember that whoever reviews your issue must be able to replicate it.
This whole report seems a little incomplete.
This is not a bug. Your friends must have checked the Require players to accept resource pack to join box for their own worlds. If that option is checked without a resource pack (RP), that world can only be played without a RP.
Your friends could have done this for any reason. That could be either because they only want players to use their RP or because they don't want players to use any RPs (Including X-ray).
However. If this is truly an issue, you have to make sure whoever reviews your report is also able to replicate the issue. How is anyone supposed to know who your friends are and what online settings they're using.
Enough context should be given for people to review this report. Remember people have to be able to replicate the issue.
Maybe attach the packs you are using.
I suspect this issue may have something to do with the output of the variables v.short_arm_offset_right and v.short_arm_offset_left on mobile, since the animations that reposition the player's hand and 3d wielded attachable objects use those variables to compensate for the character's height or arm position on the player's model. However, these two variables don't return the correct values on mobile; in fact, they always return zero on Pocket Edition.
This issue rarely happens on Windows 10, although I've seen it happen a few times, but I haven't found a consistent way to replicate it.
Do they need to? I mean, they can't use them anyway.
How is it supposed to look?
Nevermind my last comment. I actually found out what the issue is. This query does not update properly:
"q.get_default_bone_pivot"
This query is used in "animation.player.first_person.empty_hand" which is the animation responsable for the right hand and item positioning in first person. Said query is used to compensate for offset pivots due to different posible player heights in the animation. However, this function occasionally returns a value of 0 regardless of how it is used and the animation in which it is used ends up with this bug.
The game has had this bug for a long time; probably since 1.17 or so. I remember finding it a long time ago, but I assumed someone else would have noticed it and would hopefully report it.
This is not a duplicate of MCPE-51268. This is a different bug.
MCPE-51268 describes clearly villager running towards the entity who hit them.
MCPE-175018 is a bug where villager specifically do not run away from ravagers when they are near them. They are currently not triggering the is_avoiding_mob behavior
[MCQA] Bartłomiej Słodkowski Please read both bug descriptions carefully. They are both two different issues; this is not a duplicate.
This bug was introduced in 1.20.40, but since 1.20.41 came out today which is the same day I'm reporting this, I was only able to put the most recent one as the affected version.
Water splash particles worked correctly on previous versions, and they would appear as soon as the projectile entered the water.
I just added more footage. It's from 1.20.31 on mobile, since this was the only way I could downgrade. In this new video, particles work as they should. I suspect the issue might be related to MCPE-175528 since both bugs were introduced during the development of 1.20.40, and they both involve water splash particles.