Confusing MetaModel Ownership Situation
Version: 2.15.5
So admittedly, this could be down to a fundamental misunderstanding of MetaModels and how they interact with the hierarchical ownership structure, but here is the situation:
We have a RealtimeComponent "VehicleInteractionSystem" that includes TValue<PassengerManagerModel> which is a meta model:
This RealtimeComponent sits on a child object under a child view of a vehicle.
The goal of the system is pretty simple:
- Players jump on a vehicle and add themselves as a passenger to the realtimeDictionary in the PassengerManagerModel.
- This triggers a ModelAdded event callback which allows each client to handle preparing said player's network proxy avatar to be a passenger on this vehicle
We do this by:
1. Requesting ownership of the child realtimeView
2. Requesting ownership of the component
3. Requesting ownership of the meta model
4. Updating the model with ourselves as a passenger
Problem:
- The update to the model is evidently not pushed if I'm jumping on a vehicle which parent realtimeView I don't own.
- Even if I own the child view, the component & the metamodel associated, the update to the model is seemingly rejected.
- So the other clients are never recieving the call back that someone was added even though often if I own the vehicle I've added them in my model seemingly in some configurations of our approach.
We could just own the parent view to push the update, but the problem is the driver of the vehicle needs to own that in order to properly own the realtimeTransform etc.
We could do some sort of external manager that can be owned separately, but looking at the docs makes us think we should be able to use a meta model here given the example of the collaborative board you guys talk about.
Admittedly a bit lost here and would love some help / clarification. We've tried several different versions of ownership transfer, different model types, data structures (e.g. realtimeSet vs realtimeDictionary) and still seem to be getting stuck.
Huge thanks guys!
8 Replies
Hi @foundrey. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
You're running into a core aspect of how Normcore's ownership and meta-model system works. The behavior you're seeing is expected based on the hierarchical ownership enforcement in Normcore.
Key Points from the Docs
- Ownership is Hierarchical: If a parent
Even if you own the child view, component, and meta-model, if the parent
If the driver owns the vehicle (parent view), only the driver can update any child models/components. Passengers cannot add themselves unless they also own the parent view, which is not what you want for your use case. - External Manager Pattern:
Your idea of using an external manager (e.g., a separate object or model outside the vehicle hierarchy) is valid. This manager could be owned by the passenger or a neutral party, allowing updates without conflicting with the vehicle's ownership. This is a common pattern for collaborative or shared data that shouldn't be locked to a single object's owner. - Collaborative Board Example:
The collaborative board example works because the board's model is not a child of an object with conflicting ownership. If you want multiple users to update a shared model, it must not be under a parent with exclusive ownership. Summary - You cannot bypass parent ownership enforcement with meta-models. - To allow multiple clients to add themselves as passengers, use a model or manager outside the vehicle's ownership hierarchy. - Meta-models allow fine-grained ownership, but only within the limits set by the parent hierarchy. If you need more flexibility, consider restructuring your data so that shared, collaborative state is not a child of an exclusively owned object. Let me know if you need more details on how to implement the external manager pattern or restructure your models! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
RealtimeView is owned by another client, you cannot update any child models or components, even if you own them directly. The server enforces the parent’s ownership on all descendants. This is by design to prevent conflicting updates and ensure a single source of truth for a hierarchy of objects."If a model is owned by one client, all other clients are blocked from making changes to the model or any of its child models."Server Authority + Ownership + Lifetime Flags - Meta-Model Ownership: Adding a meta-model to your custom model (e.g.,
PassengerManagerModel) allows you to request ownership at the model/component level, but this does not override the parent view’s ownership."All ownership calls to RealtimeComponent just update the state of the model to reflect the new owner. However, for ownership to work, you need to compile your model with a meta-model..."Requesting ownership of any RealtimeComponent or RealtimeModel - Why Your Updates Are Rejected:
Even if you own the child view, component, and meta-model, if the parent
RealtimeView is owned by another client, the server will reject your updates."The RealtimeView's model contains the models for all child RealtimeViews and all RealtimeComponents, so any ownership settings on the RealtimeView apply to child views and to components as well."Server Authority + Ownership + Lifetime Flags What Can You Do? - Only the Owner of the Parent Can Update Descendants:
If the driver owns the vehicle (parent view), only the driver can update any child models/components. Passengers cannot add themselves unless they also own the parent view, which is not what you want for your use case. - External Manager Pattern:
Your idea of using an external manager (e.g., a separate object or model outside the vehicle hierarchy) is valid. This manager could be owned by the passenger or a neutral party, allowing updates without conflicting with the vehicle's ownership. This is a common pattern for collaborative or shared data that shouldn't be locked to a single object's owner. - Collaborative Board Example:
The collaborative board example works because the board's model is not a child of an object with conflicting ownership. If you want multiple users to update a shared model, it must not be under a parent with exclusive ownership. Summary - You cannot bypass parent ownership enforcement with meta-models. - To allow multiple clients to add themselves as passengers, use a model or manager outside the vehicle's ownership hierarchy. - Meta-models allow fine-grained ownership, but only within the limits set by the parent hierarchy. If you need more flexibility, consider restructuring your data so that shared, collaborative state is not a child of an exclusively owned object. Let me know if you need more details on how to implement the external manager pattern or restructure your models! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@719968242445058051> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
So the hierarchical ownership enforcement makes sense and I've seen that in the docs (though admittedly sometimes the normcore AI suggests that I can make edits to a MetaModel even if the parent is owned and sites the same lines in the docs), I guess in that case I'm just confused what the ownership purpose of MetaModels is in that case..
is it just persistence? so that you can log back in and keep owning the same thing? the collaboration example doesn't make sense to me so I'm struggling a bit with it 😅
you can make changes to models if it's unowned, you'd only request ownership to prevent other players from making changes
So I shouldn't expect to have the ability to make changes to models nested under a parent view that is owned by someone else.
That makes sense. I've seen in the docs that it's often recommended the root view is left unowned when a realtimeTransform with physics is also used on the root so I can do that, and in that case I assume I'd have no problem pushing updates to the child views because nobody owns the parent?
yep, for a realtime transform you only need ownership of the RT to make it work, you can leave the view unowned so other people can take ownership of the RT
Makes a lot of sense in hindsight..
I was looking at normcore's ownership system as an "affirmative" system (i.e. it allows players to do things) as opposed to a "negative" system (it denies players from doing things).
Guess I was stuck in a more traditional distributed authority mindset tbh hahaha but appreciate the clarification!
If you guys want any feedback on the docs, my suggestion would be making that fundamental difference more spelled out. Me and the guys on our team were definitely scratching our heads wondering, but tbh also could have just been on us misinterpreting.
docs could do with improvement