I am trying to create a GUI which lets players load in models, I don’t want these models to be loaded unless they press the button. If I leave it in replicated storage, I can set it’s parent to workspace (locally). But surely if it’s on ReplicatedStorage then it loads in the client to.
Thanks. (I’m aware of storing it in a table then reforming it in a local script, rather not do this.)
Descendants of ServerStorage aren’t replicated to the client.
Yeah but at some point I would need to load this to a specific player, and that player only.
Ah okay, then you would have to store every single object and property into a table and then pass it to the client so the client can construct it, don’t think there’s any other way as trying to pass the instance actually passes a reference to the instance, otherwise it can’t exist on the client.
I store everything, weapons, tools, etc in ServerStorage. The client then fires a RemoteEvent to request an item, Server checks if it is allowed, then clones the item to the Player/Workspace as required.
How do you clone it to one single player? Putting it into the workspace will be for all players.
What are the Models you are loading in? Is it something the player places in to the Workspace?
When you fire a remote from Client to the Server, it automatically sends the Player ass the first variable. So imagine the following:
-- Client script as part of your Gui in a Button
local toolName = "Dummy" -- Just a name for an item
local button = script.Parent
local equipTool= game:GetService("ReplicatedStorage"):WaitForChild("equipTool") -- RemoteEvent in ReplStorage named "equipTool"
button.Activated:Connect(function()
print("Ask for ", toolName)
equipTool:FireServer(toolName)
end)
-- SERVER script to receive RemoteEvent
local equipTool= game:GetService("ReplicatedStorage"):WaitForChild("equipTool") -- The same RemoteEvent in ReplStorage named "equipTool"
equipTool.OnServerEvent:Connect(function(player, toolName)
-- Add checks in here to see if player can have the item
print(player, " asked for ", toolName)
local toolClone = game:GetService("ServerStorage"):FindFirstChild(toolName)
toolClone:Clone()
toolClone.Parent = player.Backpack
end)
The above is meant to show how to clone an item from ServerStorage to a player using a RemoteEvent.
You can still put your assets in ServerStorage even if they need to be shown to just one player. If it’s in ServerStorage then you have full replication control and can have the server deliver the asset to the client whenever they request it or reasonably need it. Above is a great example, a tool giver.
ServerStorage descendants aren’t replicated to the client as pointed out earlier, so if you want to store assets without replicating them then ServerStorage is your friend. There’s not too much effort involved in hand replication, it’s just duplicating and migrating objects around as needed.
If a single client needs to catch a reference to it, you can do something like putting it in their PlayerGui and then firing a remote to the client so it can grab a reference to the replicated instance, then immediately parent the instance to nil. Just one such example, though a bit of a more complicated one.
It has to be put inside the workspace, it needs to go directly from the server to the client’s workspace. So only that client can see it, it can’t exist anywhere else for anyone else.
@7z99 :
Ah okay, then you would have to store every single object and property into a table and then pass it to the client so the client can construct it, don’t think there’s any other way as trying to pass the instance actually passes a reference to the instance, otherwise it can’t exist on the client.
I’m pretty sure cody’s method is the only one.
I think you’re missing the point of my responses and therefore not seeing it as a valid way of doing this, even though this is a strategy I’ve known a few top developers to implement.
It is still possible to have the client place something in workspace after hand-replicating it from the server from within ServerStorage. The crux of that response is that you’re having the server manually and directly replicate an instance from its storage to the client and then firing it with a reference to the instance that it can actually access and thus place as it wants.
Eventually at some point the server is going to be sending the client something, whether you have the server send pure data and make the client construct the object or you have premade assets that you replicate yourself. In the former case however, how exactly do you intend to go about “creating” the object? Why not just have it already made? You can save yourself quite a bit of network footprint by just sending references and keep your traffic free to send other more critical, larger data.
There’s an aversion I’m sensing here to apply or even try proposed solutions; you’re using the phrase “put instances from server to client directly in the Workspace” as a hand-wave dismissal for ServerStorage solutions, for whatever reason? You can still do that using the method I proposed; you can’t avoid following due steps to get this done.
It’s a valid solution but imho not the best one; don’t set yourself up for failure by having the client instance everything when you can just replicate precreated objects from the server to the client which it can then cache and interact with as needed. Goes for you, or anyone else reading this thread.
You keep volleying back responses suggesting use of ServerStorage but you aren’t seeing why it’s being suggested, so it’s important to really hit the point home. ServerStorage doesn’t replicate to anyone and gives you the ability to control that replication. If you need to replicate it to a specific player, you create a locally accessible reference to that instance and give it to the client.
EDIT: For the sake of example I’ve come up with a crude custom replication system. It is best tested by starting a local session of two or more players. After 4 seconds, check both client windows in ReplicatedStorage for the replicated asset and see that they are different and exclusive.
CustomReplicationExample.rbxl (30.8 KB)
*This is based off of Tomarty’s method of replication for Shard Seekers.
In this case though I’m putting it into a folder in ReplicatedStorage rather than back in Workspace but the same principles are still applicable.