Can I STOP certain modules in ReplicatedStorage from being replicated to the client?

I know this sounds like a paradoxical question. ReplicatedStorage is meant to hold stuff both the client and server can see and access. If you only want the server to access something, you need to use ServerStorage.

The problem is that I’m trying to make my game as easy-to-edit as possible and I really like having all my code stored in one place; namely, a folder in ReplicatedStorage:

download

Obviously, no matter how easier and pretty it would be, I’d be pretty stupid to put my main, server-sided code in ReplicatedStorage. Unless there is a way I can stop that code from replicating to the client at all?

I know I could just move my code to ServerStorage but then I’d have my code in two separate places and that’s harder to use and maintain. I also am aware that I could write my code in ReplicatedStorage and then move it to ServerStorage at runtime, but that would affect my beloved intellisense and make writing code much more painful.

So again, can I stop certain code in ReplicatedStorage from being replicated to the client?

1 Like

I can’t imagine there would be any functionality behind that as that would essentially deconstruct the purpose of ReplicatedStorage’s existence.

Assuming the main concern about the server-side code being replicated is people stealing it / using it for exploits, then in theory you could destroy it client-side as soon as the player connects to the game, but that’s a risk I wouldn’t fancy taking for ease in studio.

1 Like

Plus they would always be able to get it somehow anyway.

I’m probably gonna just suck it up and code the same thing twice. I might even make a feature request for this ability. Thank you

2 Likes

ServerScriptService is where you should put your important, game-running server-sided code. It is never replicated to clients. I don’t think I need to explain this further.

If you need clients to read some of that code (for example, if you have a ModuleScript) you can use a BindableFunction from client to server and return the requested value. If you simply don’t want to redo the paths of a dozen scripts, well, I can only recommend you to stick to this. I consider it a fundamental practice.
Also, I personally love the feeling of having scripts inside different services communicating with each other :stuck_out_tongue:

2 Likes

That’s a neat idea. I still lose my absolutely precious intellisense though!

You monster! (I’m kidding)

Everything in ReplicatedStorage will be replicated to the client. That’s why it’s Replicated Storage

In my experience, although it is nice to have server and client code in the same place, it’s just not worth the security vulnerabilities and potential for having your whole game’s code stolen.

I personally have bitten the bullet of separating server and client code in two different places.

It’s not as bad as it sounds though, and there are organizational things you can do to make it easy for yourself. Plus, whenever you need to search for a module you can now hit Ctrl+Shift+X to search for the client and server modules.

By convention, I always use the same name for subfolders in the client and server structures. So if I create a folder named “Entities” in ReplicatedStorage for client code, I’ll create another one named “Entities” in ServerStorage so it’s easy to find everything.

Additionally, a good convention to have in naming modules is to prefix server modules with “S”, client modules with “C”, and shared/replicated modules with “R”. This does not have to be on all modules, but it helps distinguish which module is which when glancing at the script editor tabs. So if I have a module named “Monster” that controls logic for monsters on the server/client, I would rename the server module to “SMonster” and the client module to “CMonster”.

3 Likes