When loading player data in my game, I have a remote function listening for the server to send a table of data. When that data is received, I define a global variable on the client so that any local script can reference player data at any time. When the player data is changed (By the server), the global table is also updated. Would this be an appropriate use case?
Yes if your script architecture is single script with bunch of modules loaded in order, that way _G is always loaded because the first starter script can be used to setup _G and require other module scripts aswell, for multi script architecture its not recommended unless you want to do repeat wait() until _G.something everytime you want to access something, use module scripts for that case
1 Like
In simple terms, it’s a global.
This means that anything you set to “_G” can be accessed globally from other scripts, which can be really useful in some cases.
For example, in one script:
_G.var = "This is a string!"
If you write this in another script:
print(_G.var)
Output:
"This is a string!"
This isn’t as in-depth as other people’s explanations, but this is just a heavily simplified version so it’s easier to understand. 
Lol my topic helps a lot of people i see 
Can you use this inside of a function?
For example:
-- script 1
kb.Touched:Connect(function(hit)
--code blah blah blah
_G.Touch = hit.Parent -- ik this wont work but just for an example lol
end)
-- script 2
print(_G.Touch)You could, but it’s probably not good because if you get into the habit of using global variables, there’s a very good chance you’ll use _G.touch again and create a very sneaky bug.
1 Like
Why does everyone want to use _G so bad. It sucks. Race conditions and back doors. Real nice huh?
2 Likes
people have nowhere to put modules in, and the location of it can be ugly, and I agreed, which is why I use ModuleScripts instead of _G
Chill, it has it’s uses. Calling a module script at the start of each script can be damaging to work speed.
Back doors? In what way is it less secure than a module script ;-;
Tons of games use it for things such as utility functions and shared states, I don’t recommend using _G if you don’t know the downsides, but it also has its benefits.
As in typing one more line of code? _G will just cause more problems down the line when you come back to read the code, see a random global variable, and spend several minutes trying to track down where it comes from.
No, spending an hour debugging only to realize you had accidentally overwritten something in _G is damaging to work speed.
1 Like
I honestly don’t understand why that comes up in everyone’s arguments, as long as you understand what _G is it’s easy to circumvent.
Otherwise, it’s also quite easy to debug, quite literally just use print commands like with any other bugs.
But yes, as I said, _G has its downsides, but also has its upsides. there’s many reasons large projects use it.
There is an entire thread on why global state is evil, so yeah, it is actually pretty bad.
No it isn’t? How do you know where the global state is being changed from? How can you be sure that all the data has been loaded in before you run your code on it?
At that point, why bother with _G at all? Just use a module script.
2 Likes
Everyone says “use modulescript” but what does it mean to “use modulescript instead of _G”.
2 Likes
My life has been changed. Thank you random stranger on devforum lol
2 Likes
Module scripts can contain variables or functions that can be accessed anywhere (by requiring them), just like with _G variables (note that one _G variable cannot be accessed from server to client or vice versa), the only difference is that the modifications you bring to a _G variable will actually be changed cross script.
That is what makes _G variables so useful. We all know it has its ups and downs, but if you play your cards right with the _G var it can be pretty damn useful.
I do, however, recommend that people use Module Scripts if they have never played with _G vars before. Years ago it was worth learning, but now it is not.
_G in my opinion is pretty bad, exploiters can do
for i, v in pairs(getrenv()._G) do
print(i, v) -- I Is the name and v is the type
end
Exploiters have their own environment (if im right) and getrenv() lets them access roblox’s environment (ur game environment)
Same with shared too like this:
for i,v in pairs(getrenv().shared) do
print(i,v) -- Can also be tables, functions, etc
end
Plus, all the things the exploiters can do to your global variables (eg, if it’s a function they can ruin it by doing hookfunction to it and changing it to a custom function & same with variables, they can change it easily)
So it’s pretty bad when storing Important variables such as Money, Data, etc.
ModuleScripts also are pretty bad since they can require it and do a for loop to check all the stuff inside the ModuleScript table (or anything else you return in the ModuleScript)
for i,v in pairs(require(modulepath)) do
print(i, v) -- if im right, I is the index and v is the type.
end
2 Likes
If thats what you are worried of, modules also won’t be of any help:
--> assuming module returns a table; this is an exploiters script
for i,v in pairs(require(modulepath)) do
print(i,v)
end
4 Likes
just a thing to note, you can use += 5, it makes the code shorter.
4 Likes