I’ve seen a lot of developers clone items without parenting them & then store them in a table & :Destroy() the original items. Are there any benefits to this over just letting them be in ServerStorage to clone from?
Also would parenting items to ReplicatedStorage a moment before parenting it to workspace make them load quicker for players, or is this a bad idea?
1 Like
Well, In my opinion i don’t think there’s ALOT of perks about that, But i found that interesting, If you were to use the “Void” method, It would only be useful if you don’t want to keep stuff inside ServerStorage nor either Replicate it to Clients.
The Void method is useful if you only want to use the Part/Instance inside a single script (or you can maybe store it inside a shared/_G Variable if you want to use it for more stuff) and use it at a certain time.
Here’s an example code that i used for it, It works pretty fine:
-- Main Variables
local SomeTable = {}
local SomePartName = "SomePart"
-- Part
local SomePart = Instance.new("Part")
SomePart.Name = SomePartName
SomePart.Parent = workspace
-- You could Replace it with the table length + 1;
-- But it would be harder to find if you store alot of
-- Instances/Objects together.
SomeTable[SomePartName] = SomePart:Clone()
-- Destroying the Original Part
SomePart:Destroy()
SomePart = nil
-- Trying to print the Cloned Version's name:
-- Works.
print(SomeTable[SomePartName].Name)
-- Trying to Create a Copy of the Cloned Part:
-- Works.
SomeTable[SomePartName]:Clone().Parent = workspace
Summarizing up, Both methods can be used if you want to store Instances and use them anytime you want. (Besides the Void one, You can use it but you would need to make it accessible to the whole Server-Side somehow)
4 Likes
The void method is most useful for script portability. Rather than needing to wrap a bunch of separate objects into some kind of package or writing a bunch of extra methods to move things to different directories you can create the instances dynamically in the script that uses them.
1 Like
Regarding your first point, I don’t think there’s any performance benefits to parenting pre-existing objects to nil. It might be used to strictly enforce private access and prevent other scripts from unexpectedly changing the objects, but that seems a little excessive for static models that are simply copied.
Parenting objects to ReplicatedStorage before the workspace might bring performance gains by separating the replication process from the workspace parenting process (rendering, physics, etc). This might be beneficial by a) spreading out the operations to reduce lag spikes, and b) preloading models so that models appear faster without having to wait for server data to be sent. You’d have to profile it to see if it makes a noticeable difference for your use case.
1 Like
One word:
Module
You could turn it into a module & literally create a storage service. Why would you? I don’t know that’s why I’m asking lol. Thanks for your insight!
I’ve just seen it done a lot which is why I ask, but the whole process of cloning & destroying objects just for void storage seems like a lot of waste in processing & possibly time over just letting it be in ServerStorage. If it had any benefits performance-wise, I would look into it. Thanks for your insight!
Scripts which instantiate objects with the instance class constructor function “Instance.new()” may opt to not set the “Parent” properties of those objects. When parenting an instance to a location under the DataModel hierarchy which replicates you enforce that instance to be replicated from the server to each and every client individually (this can be a highly resource intensive task, especially for greater populated servers). The same applies when the instance method “:Clone()” is called on an instance, it returns a copy of the instance which has its “Parent” property set to nil by default.
1 Like