yes, modulescripts are the alternative, but what if i want global mutability? how do i achieve this with modules, when they are cached once. what other choice do you have except shared or _G?
to specify, global mutability across client.
3 Likes
You could use Bindable Events or you could use Remote Events to pass information.
The only way to use actual global variables are shared.variableName or _G.variableName, which both I would highly recommend not to use, when passing information through all kinds of different scripts, it could be altered in a time were you don’t want it to be altered, and are insecure. Passing information through Bindable Events or Remote Events Are WAY more secure, because you can do layers of checks.
1 Like
What did I just read
The only way to replicate data to the client is to use RemoteEvents/RemoteFunctions or automatically replicating instances. (e.g. StringValue parented to workspace or ReplicatedStorage)
_G and shared are just global tables. They don’t replicate. There is one per machine.
1 Like
my post buddy
mutability does not mean im asking for replication
So what exactly is the question buddy?
It sounds like you want something to replicate to the client.
its fine i dont think you understand what im quite getting at here
global table = mutable data
looking for alternative to global table, but modulescripts arent mutable, cached once
im asking on how i could viably use modulescripts for mutable data
I think what you are trying to do is return a table from a ModuleScript
--ModuleScript
local Module = {1,2,3}
return Module
When you call require on the ModuleScript you will recieve what it returns
local t = require(ModuleScript) -- {1,2,3}
-- t is a table like any other table
-- _G and shared are also tables like any other tables
You can mutate the tables as much as you want.
What problem are you trying to solve here? Remember it’s better to make a post about the problem you are facing, rather than a possible solution to the problem. (XY problem again). From what i can tell, there might be a better way to solve the problem that using globals.
Anyways, I think the closest you can get to a “global data mutable structure” is by using a single ModuleScript GlobalData with functions to set and get the data. This way the data isn’t just cached once
local data = {}
local GlobalData = {}
function GlobalData.set(key, value)
data[key] = value
end
function GlobalData.get(key)
return data[key]
end
return GlobalData
The only ways to share data globally is with shared, _G, or with a single ModuleScript like i shown above.
2 Likes
i am trying to solve what i mentioned; global data mutability alternatives
modulescripts are cached once. i cant have script1 require it, and 2 seconds later script2 adds an index. script1 would read that as nil
Script 1 wont read it as nil.
When you require a module script a second time, it wont run the module script again, but it will return what was returned the first time, in this case, the table. And that wont be a cloned table either, it will be the same table
The GlobalData.set and GlobalData.get functions mentionned above are also useless as you can modify the table directly without the need of functions inside the module
I also want to add that SharedTables are quite bad performance wise, mainly because they are made to work with parallel lua (almost 100% sure that _G isn’t shared across multiple parallel threads)
(wrong type of shared lol)
1 Like
shared =/ SharedTables
Summary
it’s simply not possible, it is referenced once, solely. you can test it out for yourself. it’s a unique reference always.
Script1 will read that index. The reference to the table returned by the module is cached, so all scripts will require the exact same table when they need to require the module. It’s not like passing tables through bindable events, which are deep copied.
Example:
Create two local scripts in your game and put a module script in ReplicatedStorage.
One local script will require the module first and add an index:
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Global = require(ReplicatedStorage.Global)
print("First require: ", Global)
Global.AddedKey = 100
print("Modified: ", Global)
The second will wait a bit before requiring the module:
task.wait(5)
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local Global = require(ReplicatedStorage.Global)
print("Second require: ", Global)
Module script:
local Global = {
StartKey = 10,
}
return Global
Result:
2 Likes
i’m really tired, and i only realized now that i was returning the module instead of the table 
thats why my shit didnt work
yes your code works
1 Like
It is wrong to require a ModuleScript multiple times! You should be passing in a table with every descending ModuleScript, which are either siblings or inherit a parent.
It is not wrong to require a module script multiple times. If you are doing so in a single script, it’s odd practice (as you can simply index it once per script), but requiring the same module from various scripts throughout your game is very effective and generally is how OOP is implemented.
It depends on the codebase, but I usually dislike looking for instances to require instead of just having them. I believe it is better for performance to do so.
However, it is not necessarily wrong if all that is being returned is a table.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.