In what situations should i use ModuleScripts?

[IcyMizu]

so im trying to get into using module scripts and i know how to use them i just dont know why i should use them and what i should do in the module script and what i should do in the normal scripts im just kinda confused about the use of module scripts :P, like to “organize” ur code better what do they mean with this?

[slothfulGuy]

Oh, you can upload a public ModuleScript to your inventory containing codes or functions. Then, you can easily call it using require() function in any game, as long as they’re not set to private.

ModuleScript | Documentation - Roblox Creator Hub

Mostly, it’s been used for anti-exploit systems and admin commands. It used to be able to hide codes from the users who calls that function, but due to safety concerns, only public modules are allowed now. This was specifically helpful if users wanted to hide their codes from others, while still letting them use it. Refer to this thread.

[Noxielotl (Nox)]

ModuleScripts are commonly used to house code that you’ll use often across Scripts and Local Scripts.

For example, lets say you have a Dictioanary with info on items like below

local ItemInfo = {
    ["Item 1"] = {
        Price = 50,
        Description = "Like it's name, it's 1 of a kind!"
    }
}

You’ll need this data in two places. On the Server as when the Player buys an item, you’ll want to check if the they can actually afford the Item and on the Client because you’ll need to display the price of the Item in the shop.

Having this code in a ModuleScript means that you won’t have to duplicate that Dictionary.

I also use have a ModuleScript called Team Handler which I use to make adding / removing Players to a team, checking if a Player is in a team, checking the team of a player, etc much easier.

And sometimes, people just use ModuleScripts for organisation and clean code.

I have a module script called Data which just handles Player Data (Loading, Getting, Saving). It doesn’t really need to be a Module Script because I only use it in one script, but it makes my code look clean and more organised.

[Operatik]

Short Summary

---

A ModuleScript should be treated like OOP; object-oriented programming. Each module can be organized into specific areas. One example of such module should be for the player’s datastores. You will need a script that runs require() and the directory to the ModuleScript.

What a ModuleScript can do:

• Also use require() for another ModuleScript
• Saving arrays, variables, values etc.
  • Either local values or accessible such as module.Value = 10
• Saving functions; which allows the main script to run them

Does not run without require().

Misconception Corrected 2x
Metatables are for OOP.

The complete view on OOP is now adjusted to feedbacks below.

[Quoteory]

Storing player data in game

Yes modules are what you want to use ModuleScript local Data = {} local PlayerData = {} function Data.AddPlayer(Player, Data) -- adds a player to the PlayerData Table (Do this when a player joins) PlayerData[Player] = Data end function Data.ReturnData(Player) -- Retrieves a player's data from the PlayerData Table return PlayerData[Player] end function Data.RemovePlayer(Player) -- Removes a player from the PlayerData Table (Do this when a player leaves) PlayerData[Player] = nil end retu…

This is my reply in another scripting support post, but I believe it could be of use to you it’s a basic data storage module that I believe is commonly used

@Kymaraaa

I have a module script called Data which just handles Player Data (Loading, Getting, Saving). It doesn’t really need to be a Module Script because I only use it in one script, but it makes my code look clean and more organised.

I think this is what @Kymaraaa is referring to

[Avigant]

Modules don’t have anything to do with OOP at all.

[Elttob (dphfox)]

I use ModuleScripts for pretty much everything:

Why? ModuleScripts are absolutely brilliant for making your code more clean, modular and easy to use.

• You can precisely control when your code will run since you have to require() modules to run them. I usually have one or two scripts which require some of the modules, and those modules will, in turn, require all the other modules they need, and so on. This lets you make more guarantees about what your scripts have access to (especially useful when dealing with things like replication!)

• Since you can return tables from modules, you can expose neat APIs for your scripts to use. This makes your code neater and easier to reuse!

• It’s easier to enforce things like the Single Responsibility Principle when you use modules; one module = one responsibility. That way you don’t end up with any ‘god scripts’ or anything like that.

[colbert2677 (ImagineerColbert)]

A few misconceptions there, my friend.

Neither metamethods or ModuleScripts are related to OOP. OOP is a coding paradigm. Both ModuleScripts and metamethods serve their own respective purposes, which you can use standalone or combine. Paradigms are separate and related to how you code (imperative, functional, OOP, etc).

Local variables will not be accessible to other scripts unless you have a reference to the variable to prevent it from being garbage collected AND have a public method which other scripts can use to fetch said private value.