ReplicatedStorage and ServerStorage have different use cases. As each name implies, one is replicated, while the other is simply stored on the server. If you have models that you wish would not be replicated to the client, use ServerStorage. In many cases, however, you need the client to be able to access models. Then you would use ReplicatedStorage.
Yeah I need the client to access the stuff I put in it- i’m sure a lot of other devs do. Is there some reason why their models cannot be replicated into the client by an exploiting script? Does FE help?
FilteringEnabled simply prevents client-side changes from replicating to the server automatically. For example, if the client deletes a part in workspace, it will remain on the server. An exploiter can steal almost anything that the client has access to. This includes: models, local scripts, module scripts, and other assets.
Edit: There is virtually no way to prevent asset stealing (in the case that the client needs to access said assets).
Then what should I do if the client needs access to those models, but at the same time I want to keep my content to myself only?
1 Like
Yes this is true. Its “Replicated” hence the name, to the client, anything on the client can be eploited/stolen.
I don’t know why.
Yes, I for one, do use server storage for my models/parts/meshes, Its safer that way from exploiters who try stealing assets.
Also you can clone models/parts/meshes/unions from ServerStorage as well, so I dont know why people use ReplicatedStorage over ServerStorage.
Well I wish I knew this before making my game- but how do you access something from ServerStorage, is it the same way as ReplicatedStorage- you just use ServerStorage:FindFirstChild(“etc.”), thanks!
This means that you should just structure your game in a way that things required by the client are replicated, as asset stealing is (as far as I know) unpreventable.
I explained the use cases in one of my replies earlier on. ServerStorage cloning should be only things accessed by server scripts (since local scripts can’t access them), whereas ReplicatedStorage is used for instances shared by both the client and the server.
Yes, this is correct. Keep in mind local scripts have no way to identify instances parented under ServerStorage.
Yes, its exactly the same:
local ServerStorage = game:GetService("ServerStorage")
local part = ServerStorage:FindFirstChild("part")
local clone = part:Clone()
clone.Parent = workspace
Thanks for the info! 
I guess I learn something new everyday.
1 Like
And both localscripts and normal scripts can access ServerStorage this way? I need to access it mainly from the client.
ReplicatedStorage is the storage you use for client access. Clients can not access ServerStorage at all.
Why not use a server script to clone what you need?
Because only server scripts can access ServerStorage.
Also another use for ReplicatedStorage is the directory for Remote Events.
He is accessing said models from the client. Cloning models on the server (for the client to use only) is pointless and just an extra, unnecessary step to make things more difficult.
Could I call a RemoteFunction() from the client, in order to get a copy of the model for me and pass it back to me? Would that work- can models be passed this way?
Yes, you could use a Remote function from a local script to trigger a server script that will clone the Model.
This way you could clone the one specific model to ReplicatedStorage, and the other models stay safe from exploiters/hackers
Thanks, I might do it. I’ll seriously consider it and look further into it tomorrow. And by doing this that makes the model in client client-only or only their computer or does it make it public?
Cloning it from ServerStorage will make it public, but you could make it only clone to that one specific player.
To clone it to one specific player, you could do something like, clone it to ReplicatedStorage (its currently public on this step), then using a local script make a clone of the model that’s in ReplicatedStorage and parent the clone to workspace where the player can see it, then Destroy() the model from ReplicatedSorage, (now the model is only by that one player).
Now I see how complicated it gets just to clone one model locally, I can see why most game makers prefer using ReplicatedStorage… also I have a question that just came to mind- if you clone a model from ServerStorage and it goes eventually to the client… then can’t that be stolen in the same way through using scripts/injections to get that model now that it is in the client? Do you see what i’m saying, it’s not a 100% fool-proof way in my view. Unless that is if I am wrong, and if I am please tell me. Thanks.
You are right, Its not 100% fool-proof, But by using said method, they will only be able to steal the cloned model, while the other models will stay safe inside of ServerStorage.
In that case I think i’ll stick with ReplicatedStorage since all my models there are accessible by the client through buttons (customization/crafting frame)… I hope this is a wise choice for me. It certainly is the easiest.