Moderator Muting Ownership
Let's say I have an AvatarSync on my RealtimeAvatar that has the bool _isMuted. I believe that RealtimeAvatarManager spawns VR Player Character with ownership belonging to the client who is the actual player. If I want a moderator to be able to set _isMuted on another player to true, do I have to RequestOwnership()? Then how do I give ownership back once the client who owns it updates it? Call RequestOwnership() inside the DidChange callback if MyClientID == originalOwner or something?
3 Replies
Hi @khoi. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
You're correct that by default, the RealtimeAvatar (and its components like AvatarSync) is owned by the client representing that player. This means only the owning client can update values on its RealtimeComponents, including your _isMuted property. This is intentional to prevent other clients from modifying another player's avatar state directly, as described in the documentation:
You would need to call
However, this is not a recommended or robust pattern for avatar control, as it can lead to race conditions and desyncs. The documentation specifically warns against trying to clear or transfer ownership of avatars for this reason. Recommended Approach Instead of storing _isMuted on the avatar's RealtimeComponent (which is owned by the player), store mute state in a shared, moderator-controlled data structure, such as a
RealtimeAvatar sets the ownership of the root RealtimeView to the local client. This is to ensure that only the local client can modify the avatar. Only the local player can update values in realtime components on their own avatars. This is intentional! We recommend that you don’t try to clear ownership of the avatar—you’re going to be in a world of hurt if you do.Common Questions – RealtimeComponents Can a Moderator Set _isMuted on Another Player? - Yes, but only if the moderator takes ownership of the relevant RealtimeComponent or its model.
You would need to call
RequestOwnership() on the component or its model to make the change. However, this is not recommended for avatars, as it can cause ownership contention and unexpected side effects, especially if the original owner is also trying to update their state.
Giving Ownership Back
- You could, in theory, track the original owner and call SetOwnership(originalOwnerID) or have the original owner call RequestOwnership() after the change.However, this is not a recommended or robust pattern for avatar control, as it can lead to race conditions and desyncs. The documentation specifically warns against trying to clear or transfer ownership of avatars for this reason. Recommended Approach Instead of storing _isMuted on the avatar's RealtimeComponent (which is owned by the player), store mute state in a shared, moderator-controlled data structure, such as a
RealtimeDictionary or StringKeyDictionary. This allows moderators to update mute states for any user without needing to take ownership of their avatar:
Instead, try storing data like health and scores in a RealtimeDictionary or a StringKeyDictionary.Common Questions – RealtimeComponents - The avatar can then read its mute state from this shared dictionary and update its local behavior accordingly. - This avoids ownership issues and is the recommended pattern for moderator or server-authoritative state. Summary - Do not try to take ownership of another player's avatar to set _isMuted. - Store moderator-controlled state in a shared, non-avatar-owned model (e.g., RealtimeDictionary). - Let avatars read their mute state from this shared model. If you need code examples or further details on how to implement this pattern, let me know! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@412870643533479936> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
you shouldn't request ownership of other people's avatar, instead you can create a realtime dictionary that only the moderator owns with a mute setting for each player which every player can read but not write to