What is _G and for what i can use it?

You shouldn’t use _G or shared at all, they’re age old practices from a time when RemoteEvents/ModuleScripts didn’t exist yet.

3 Likes

@dthecoolest @Forummer, Thank you for the response. Found a solution using module scripts. :+1:

1 Like

Hey colbert can you tell me, if I can do this?

One script in server:

_G mps = game:GetService("MarketplaceService")

In other script:

local mps = _G.mps

Can I do this?

This isn’t a good idea. If you set it as _G.mps, it’s possible that it hasn’t been set yet because of race conditions and the mps variable will be nil. Is there any reason you can’t just replace the _G.mps with game:GetService("MarketplaceService")?

Like _G.mps will be easier

You shouldn’t sacrifice ease of use for readability and chance of error. It’s not guaranteed that _G.mps will be ready when you load it, and waiting for it to exist is less performant than game:GetService("MarketplaceService"). Also, if you read it later, you might not know what it’s doing (while game:GetService("MarketplaceService") is very clear). Is it really worth saving 3 seconds of typing for all these problems?

3 Likes

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. :slight_smile:

Lol my topic helps a lot of people i see :joy: :relieved:

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.

1 Like

Everyone says “use modulescript” but what does it mean to “use modulescript instead of _G”.

1 Like