GUID Component
This has been discussed in the past and AFAIK is planned to be added but figured I'd add it as a thing to this new forum. Basically, the idea of some standalone component that you could add one or multiple of to a game object and it would sync some ID across all clients when the object is awake / spawned. This is extremely useful for keeping a shared reference over network of some object you want to keep track of. An additional very useful addition would be the case of the GUID Component having a component reference on it, something like "assigned component", so when you receive a reference to that GUID component over network you could perhaps do guidComponent.assignedComponent to fetch the component it's bound to over network, saving a GetComponent call and allowing for multiple of the same component type to be synced via this component. Would be a great official addition as doing it manually right now is kind of a pain. Hope it can get added at some point and happy that it's already being considered!
24 Replies
This is something I would love to see as well.
It's on the list!
:party_blob:
@Camobiwon @Endasil @cryptomax @Yips we're working on this component now. Can you all tell me how you use this component in your projects? We want to make sure we solve all of your use cases.
Yo, currently of course at a baseline it's fundamentally used as a synced component reference for me (Specifically in my case syncing unity components, manager registers them into a dictionary, ofc I can use component.gameObject for additional refs). On that point I just mentioned, I'd specifically need a reference to the component itself I'd want to sync via the GUID component, as let's say if you had 2 of the same component types you wanted to network, you couldn't get both if you didn't have a hard reference to what you wanted, as doing GetComponent would only return the first with no way to distinguish.
My current main use cases would include: Player hand attaching to grips (Grips holding an ID), hit rigidbody references for scripts requiring that, holster slots for items (Using rigidbody ID), magazine sockets, references for damagables being hit, additionally this one larger system which generically passes around a sender and target GUID, and I have a bunch of future use cases I'd certainly need it for.
Having this official would be awesome, the way I plan on using it in the way I imagine it'd work would be on Reset to have components that require it add one alongside themselves, set themselves as the networked component reference, then have their own reference to the GUID component so that other items needing it's ID could do something like myComponent.guid.ID or something, perhaps you guys could get that even more intuitive
There's still a lot of work we need to do to ensure this is possible, but I think our current interface would allow you to serialize a reference to any RealtimeComponent in a model via a new RealtimeReference model type. Normcore would take care of the ID stuff behind the scenes, you wouldn't need a new NetworkGUID component, you'd just be able to get the reference out of the model.
Would that work for all of your use cases?
Ooh got it, yeah I believe that would work. Was gonna question the hypothetical of syncing references to components that are not a RealtimeComponent, but in my current case anyway they need to be realtimecomponents purely for an ID int reference, which would be very nice to get rid of.
So if I imagine this correctly, something would directly reference a component via a RealtimeReference, send it over network, then fetched on the other end / handled when received?
yeah exactly. you’d store a ref to your RealtimeComponent in the model and on the receiving end the reference is filled out for you by Normcore automatically
so you don’t have to do a custom lookup even
My only question is how is the type handled?
[RealtimeComponent(1, true)] private RealtimeReference<MyComponent> _myReference;
and it’ll have a property to get the reference that’s typed
This would be setup in your own model?
yup
where ever you’d plan to save the GUID string essentially
Actually wait worded this wrong and am confused on this. Let's say if my hand needed a reference to a grip. Would the grip's model be storing a reference to itself, or would the hand's model store a realtimeref to the grip?
Reading this it reads like the hand would store it, unsure how that may exactly work for some cases
the hand would store a reference to the grip
essentially any place you’d store the GUID string, Normcore does the work internally to assign a GUID and store it without requiring you to explicitly add a NetworkGUID component anywhere
And at any point this reference can swap around to a different thing, right? Like if my hand changed grips / ungripped
yeah def. you can change it whenever
and also set it to null
Got it, assuming callbacks would exist and whatnot
yeah we’d support change events
Sweet
I'll have to try it out for myself when it comes out but that sounds pretty nice thus far. If I need more advanced stuff for weird cases then I can always implement myself
lmk if you think of any weird cases. I’d love to see if we can cover them before we commit to an API
Got it, I'll lyk if anything comes to mind, it's currently just the opposite way of how I implement it but I believe it should work for my cases
Just to be able to look up any game object by it's ID that would be persistant, unchanging, and networked, if anyone can easily access the same ID then it's super easy to handle local/or realtime dictionaries of those ID's and do things with them. For instance I need to track single level parent child relasionships as well. (which lets me do complete branching since you can just check the next parent etc.) That all gets soo much easier if any instantiated object has a fixed networked ID. Is that helpful at all?
yeah but can you elaborate on that more? I don’t fully get the parent/child thing
I have a realtime dictionary with parent child sets so anyone can tell if an object has a parent or a child without any actual hiarchal realasionship. I just means you can keep checking if parent or child exists for an object to propigate through a branching chain of relasionships to accomplish something like child destruction when they aren't otherwise connected in any way, thats how i'm using it.