Hi, I got a model on the server, and on the client. It’s got a lot of parts with the name Part. Now the local model is instantiated locally, so if you try to pass that instance it’ll turn into nil.
I want to know how I can communicate to the server that I need the exact same part in the server copy as the local part to which I can’t pass.
If I understood your question correctly, perhaps you could give every part in the model a unique name, then pass to the server the name of the part you want to modify?
I’d think that’d work.
That’s constraining; worse than redundant, as is my still putrid idea of assembling a Lua table with all the parts in it in the ReplicatedStorage model for dissemination to server and client copies.
A more reasonable request on my part: A link to the Studio feature rollout schedule. Somewhere in there they have something, even if it is internal, that is the exact lead I need. I forgot what such mass editable models are called, they’re going to be like corporeal classes or something, but that’s the exact kind of relative identity I’m looking for!
The only way I can think of to correlate an item on the server and client which are different userdatas would be to give each part a unique name. You could just run a script through the master model and give every part a randomly unique name.
edit: perhaps if you can give us more details on your use case, we can provide other solutions
Exactly what C_Sharper said, I think I got my lead though, even if it’s not particularly… Lua-able:
The Roblox Studio Roadmap, as it’s called:
and the feature of relevance, “Packages”!:
(I am checking this out just now, and I will edit my post after learning, applying and concluding.)
Based on my understanding of the wiki page, packages are a sort of version control that allow you to sync objects across places. This would not be an appropriate solution for client/server replication.
So what I can think of is using remote events.
Make the server create the part first, then use the remote event and send it to the client, and when the client is done with that part, send the part to the server. The info should not be the part, but the things that changed on the client, such as position and colour.
Then the server will dictate on what the part should look like from the info sent from the client.
While the client can receive that part, it has no way to correlate that part to the parts it is modifying on the local model.
TOP, you’re violating a lot of necessary conditions I described. There is to be no transfer of parts. There cannot be any transfer for it would be unidirectional from the server the local client. Local client has its own copy and that’s that.
As for Packages, as with idk’s statement there isn’t the kind of referential API I was looking for, atleast in Lua form. but that sort of relative to model part identity is a perfect nod at what I want.
Are both models created(cloned) off of a shared source model such as something in replicated storage/workspace or are they generated in runtime on the server and the client individually?
As in my second post “… my still putrid idea of assembling a Lua table with all the parts in it in the ReplicatedStorage model for dissemination to server and client copies.”, the former is the case, yet this solution (a wacky array transfer idk how to do yet) is something I kind of want to hold off on. Feel free to dissent my decision of course.
My suggestion would be to have the server assign a unique id to each part in the model and then store said parts in a dictionary with the ids as the keys. Then either through using remote events or putting instance values in the parts in the model in replicated storage, get these unique ids to the client, where they can also catalog each part in the dictionary to its id. This allows for fast access to parts by id when changes are being made to them through client-server communications.
Yeah I think that’s what it’s gonna have to be. Now the question becomes how I’m going to make an efficient dictionary to store thousands of local references. Should it even be concern? Might be the case for another discussion if I don’t find a preexisting one.