Uploaded image for project: 'Minecraft (Bedrock codebase)'
  1. Minecraft (Bedrock codebase)
  2. MCPE-149139

Entity properties doesn't client-sync automatically when updated

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • 1.18.20.23 Beta
    • 1.18.20.22 Preview, 1.18.20.21 Beta, 1.18.10.28 Beta, 1.18.10.27 Beta, 1.18.10.24 Beta, 1.18.10.20 Beta, 1.17.41 Hotfix, 1.18.0, 1.18.2 Hotfix
    • None
    • Plausible
    • Multiple

      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.

        1. 1 (not work alone).png
          6 kB
          Sprintermax
        2. 2 (dummy component group).png
          5 kB
          Sprintermax
        3. 2021-11-29 00-27-21.mp4
          7.55 MB
          Sprintermax
        4. 3 (updating other things with the property).png
          9 kB
          Sprintermax
        5. ExampleAddon.mcaddon
          5 kB
          Sprintermax

            Sprintermax Sprintermax
            Votes:
            5 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved:
              CHK: