When I was making an addon, I found an weird behavior with the currently experimental entity properties and molang "query.actor_property" / "query.has_actor_property".
The Behavior:
Entity properties has an option named "client_sync" that when set to true, the Behavior Pack (server) will send the property to the Resource pack (client) to be able to use on animations, render controllers and other client-sided features. When you first summon an entity or join a world, the client will load the property value that are the default or saved in the server.
When the value are changed with an entity event using "set_actor_property" (see attachment 1), It doesn't send the update to the client side, causing some issues like not updating entity rendering or animations for example.
The Workaround:
As I said in the bug behavior section, the property are updated in the server side, but not sent to the client. After some tests, I figured out some unexpected ways to make the client load the updated value:
When the property value is updated, you simply quit the world and then re-join. This will make the client fetch again the saved value on the server side, updating the stored value in the client side. This work only one time per world join.
Apparently, you can "force" the client to sync in live by making the event updating other thing in the entity (like a component group). An easy way to show this, is making a dummy component_group (as shown on image 2) and then making the event in addition to change the property state, also updating the component group by an action like add/remove (image 3). This will make the client side update the property every time normally (the expected behavior of this feature). With some aditional tests, other actions like "run_command" in the event will not make the property to sync.
Aditional Tests:
The property don't update when leaving the area (unloading the chunk) and then approaching again to reload the chunk. (The same with simulation distance)
I tested in the most recent release (1.17.41) and the most recent beta (1.18.10.20), the bug happens in the both versions with the same unintended behavior.
Enabling more experimental features than the necessary also don't change how this behavior occurs.
I also tested on a LAN world, and the bug happen with all the players. When using the first workaround (re-joining the world), will fix only when the HOST re-join the world, it will not update for any other player when they re-join. Using the second workaround (dummy component group), the update will happen in live for everyone.
Demonstration:
I made an addon using the queries on the client to enable/disable the rendering of a hat in a dummy mob. I recorded a video showcasing the property not live-updating with the re-joining world workaround, and showcasing the second workaround that I mentioned using a dummy component group to "force" the client-side update.
The addon used for the tests are attached, it's possible to change the property by right-clicking (interacting) with the entity. and in the behavior files of the entities also have some notes about this bug.
Attachments
Comments 4
To add to this, it also affects all the actor property values if only one is changed. If you reload a world and "save" an entity with multiple actor property values (workaround 1), and change just a single value, all the actor properties will use their default values instead.
I also can confirm that issue.
This bug is quite annoying, because it defeats whole purpose of Actor Properties as alternative of variant, mark_variant and skin_id components.
Also, properties are not refreshing for players who join for the first time with particular RP (for example: after re-downloading buffered pack). Instead, it throws constant stream of Molang errors. In that case, rejoining or using workaround provided by OP fixes this issue
I am also experiencing this with my own experimental addon.
Found it very frustrating at first when the actor property was reverting to its default value, instead of the new value set by set_actor_property. I only noticed it when I was out of range of the entity (when the entity disappears visually by distance - not affected by simulation distance) and returned to see the entity not rendering the same texture value it was set it to using set_actor_property and determined by query.actor_property in the render controller.