Your module script:
local mod = {}
mod.my_var = 1
Script 1:
local my_mod = require(game.Workspace.ModuleScript)
print(my_mod.my_var) --prints 1
my_mod.my_var = 20
Script 2:
local my_mod = require(game.Workspace.ModuleScript)
print(my_mod.my_var) --prints 20
my_mod.my_var = 5
Script 3:
local my_mod = require(game.Workspace.ModuleScript)
print(my_mod.my_var) --prints 5
Hope that makes it understandable.
I’d also like to add on, client and server don’t share the same memory, since they are on different machines after all.
So not only is lua’s global table not replicated from server - > client, or client → server. But no table is replicated or shared over the boundary unless user defined.
Lets say you have some table and pass it in as an argument to a remote event/ function. Internally this table is encoded/decoded to/from a JSON-formatted string. This then creates a different table (on client if sent from server and vise versa) with a reference which can only be accessed on the machine its stored on.
Like…?
This is a year old thread and it’s not particularly related to the question OP is asking, but there is virtually no reason to be using _G in 2021. ModuleScripts can do what _G would commonly be used for. Developer globals have almost no place in Roblox development.
As for your latter post, bumping is making a comment on an old thread that doesn’t add discussion value to a thread. This is fine but if you’re asking as a question and if it’s related to OP’s topic.
_G is useful if you don’t necessarily NEED huge tables of variables and stuff and you only need to make one variable global to other scripts.
You can still use ModuleScripts for that or pass them around as variables either through pure Lua, attributes or ValueBase objects. _G is unnecessary. Don’t use globals if you don’t need them, which in nearly all cases you don’t and can import them from somewhere better.
Might just be me and my laziness but I use _G to store required modules lol
Ad hominem attacks aren’t what you should be getting out of this or any similar such conversation; it’s that using globals is unnecessary and dare I say bad practice. Local variables are faster, can be accessed right from the stack and there are better ways to do what you’re looking to do.
_G has virtually no place in production code as it stands now. All members of that table are globals unless you declare them locally which in that instance you can just settle for better solutions that involve them being in scope. You can easily pull your variables in using more conventional methods and even better if your code structuring is well done, e.g. a framework!
Feel free to look for a similar discussion topic or start a new one based on _G. This isn’t related to OP’s topic anymore which is seeking to prevent exploiters from accessing variables in the global table; it’s starting to veer off topic to hone in on one specific point that popped up during discussion when the thread was originally created. Don’t want to hijack the thread.
I just want to add that it is absolutely, undeniably exploitable (with considerable ease). Using module scripts is better is many facets, but you are able to modify and call anything that you return in the module script.
This is true only for the client side, although I agree that modules are superior.