So I have heard a lot about using modules instead of normal scripts. The things that I have questions about are why use them over regular scripts? What do they add to scripting that can make it better? One thing I was also wondering was that why shouldn’t you use normal scripts, as module scripts that are in replicated storage can be taken and leaked by exploiters who hack your game. If you use normal scripts, then your scripts are safe. Why should you use modules instead?
1 Like
UPDATE : This statement below is wrong, special thanks to @posatta for correcting my false belief here, the decompilation only applies to Localscripts and Modules.
Scripts / LocalScripts & ModuleScripts are all obtainable by Exploiters if they have the ability to decompile your scripts ( This is currently thwarted due to the new lua vm but don’t rely on it to secure your code ), as long as it is stored in a place the client have access to.
With that aside, among the primary reason they added Modules was for developers to have a much more organized manner of scripting where you don’t need to repeat the same function more than once. Personally I feel that modules also encourages more Functional Programming since you can also require this module from any script within the same environment ( server/client ), but this could also be just my own biased opinion because I’m almost religiously a Functional Programmer.
Modules can also be required via an asset id ( you can make this private or public as explained in here )
In short, think of it as a global dictionary ( _G.Dictionary ) except it has more features as compared to a global dictionary ( _G.Dictionary ). All of which is explained in the link above 
P.S : If among your concerns is source-code security, make a plugin / program that takes a lua source as input and produces the obfuscated version of it as the output. Basically the goal of a solid obfuscation is to make it so that even if someone reads your script source, they won’t be able to understand it
3 Likes
This isn’t true, server-sided scripts and anything in ServerStorage/ServerScriptService isn’t replicated to the client and can’t be stolen by exploiters.
3 Likes
Scripts in the workspace (or anywhere else) can’t have their sources stolen.
1 Like
You mean can right, because you just said in serverstorage and serverscript service are safe.
Here’s a post that explains this more clearly (specifically Kampfkarren’s answer, not the whole thread):
Basically, everything in ServerStorage/ServerScriptService is safe. Normal (server-sided) scripts anywhere are safe.
3 Likes
I learn something new everyday, I’ve never had any server-sided scripts be available outside of SS or SSS for the longest time ever because of this belief I had
Just confirmed this with a few white hats that I know. It appears I misunderstood, greatly appreciate the lesson and apologies to OP for the misinformation on that part, already corrected the original post!
1 Like
What about modules, as that is the question I am asking here.
Modules are only safe in ServerScriptService or ServerStorage. Since they can be required by a LocalScript if they’re in ReplicatedStorage (or anywhere else), they’re not safe there.
Modules aren’t really used for their security, since they’re not any more or less secure than a normal script; they’re just a way of organizing your code. Modules are mostly used so that you don’t have to type the same function across multiple different scripts, or so that you can put similar functions all in one place to make debugging easier.
4 Likes
The place stealer thing was back when Roblox had an exploitable website flaw though, that’s something out of developer’s control, one of my games was among those that was stolen back then as well, alongside Quenty’s Whatever floats your Boat,
Ever since then I just make it a habit to obfuscate every scripts in my games and sneak in a hard-coded check to crash the game in several different manners if the game’s place id isn’t equal to mine and the game’s creatorid isn’t my userid
Have that obfuscated in different methods almost everywhere in your code and you’re pretty solid already
Another thing you can do in concept is to initialize the game through a private module, so even if the place itself gets stolen, all they really get is an obfuscated code that requires the private module’s asset id.
@CaptainD_veloper MainModules or modules loaded in via require(id) can’t be decompiled either, but then again this is irrelevant really because it doesn’t matter on the client since u can’t use require(id) locally
It’s better you keep it this way anyway. Scripts canonically belong in ServerScriptService and realistically shouldn’t have any presence outside of that service unless it’s associated with a specific physical object where streamlined behaviour isn’t something you can settle for (behavioural control via ServerScriptService on an object in the workspace).
Other tidbit I want to throw out: ModuleScripts don’t necessarily encourage OOP, in fact they don’t at all. OOP-in-Lua is just a common use for ModuleScripts since it’s capable of achieving that. ModuleScripts encourage reusability and abstraction. Emphasis on reusability, which is a core point to them. OOP-in-Lua isn’t bad though, a lot of developers are definitely fond of it. You’ll see that around here often.
ModuleScripts also help you run code on-demand, as the code of a ModuleScript does not run without being required. It can help you set up many different kinds of systems, such as frameworks (my personal favourite is Aero Game Framework) or library loaders (I often flock to Nevermore for this). It can even just be as simple as distinguishing bootstrapped code from code you want to hold off from running until you explicitly call on it to do so.
1 Like
Aye, it’s a habit I picked up misunderstanding that Scripts also can be decompiled but even now with it corrected, I don’t see how I will ever put Scripts outside of SS or SSS. In a way it was a good habit to have picked up from a misunderstanding haha
This is actually my mistake, I was really sleepy when I first made that post, I’ve since updated the original post. I meant to say Functional Programming not Object Oriented Programming cause to me I see much easier use of that paradigm with modules, but then again this could just be my own bias because I personally am addicted to Functional Programming. Except cases where something doesn’t need to be repeated, I barely code in a different paradigm.
There is something I wanted to add though @CaptainD_veloper, having thought about this carefully, you can’t really compare Modules with a Script especially in terms of Security, a Script won’t be able to return a functional table to your LocalScript, whereas a module can do that for you. So whether or not Scripts are safe doesn’t change the fact that it cannot return a functional library that your localscripts can use.
Only for Client-Sided modules, if you’re using a module on the server, it shouldn’t be outside SS / SSS. The reasonable comparison you can make is between a ModuleScript and a Global Functional Dictionary, in which modules still hold more in terms of functionality. In short, if the main reason stopping you from exploring modules is Security, I would say explore it, there’s just a lot of great habits you could pick up if you use modules correctly imo.
3 Likes