admins =--this is the table, called admins
{
"MillerrIAm";
"NemesisY2J";
"Sonicxman";
"Dewwy5280";
}
--now you can refer to that
plr.LocalPlayer.Chatted:Connect(function(plr,msg)
if table.find(admins, plr.Name) then--if the person who's messaging has his --name in the table then, do this..**I took this as an example from @zQ86
if msg == msg1 then
Event:FireServer("Ring the bell!")
end
end
end)
--this is all an example, of how you can use tables in the simplest way I mean,
it’s alright you can always change it, but i’m not telling you to, you have to decide what , if marked, will help people who are searching for help on tables, this example or just another link. I mean a link on’t help without an example right? Anyways its up to you
Any Programmer who knows what they are doing wouldn’t recommend using _G and Shared because they compromise performance, I’ve never seen anyone recommend using Global Tables before.
You should use Modules they are better than _G and Shared
CC @RuizuKun_Dev, This is adding onto what you were saying in your post.
I wouldn’t recommend _G because ModuleScrips serve as a much, much, much better alternative. _G may seem good to use initially when you have a small code base but when you start using it extensively everywhere you will find yourself getting confused as to what is and isn’t stored in it. This makes reading and updating your code a lot harder. Be very careful when using _G and only use it when you really need to.
_G has so many limitations compared to using ModuleScrips: You can’t store stuff for both client and server to access. You won’t be able to take full advantage of OOP with _G because of how much more confusing it will be. Why would you store all your global stuff in one table?
Why modules are a better alternative:
ModuleScripts have so many more advantages than _G because of how organisation friendly and versatile they are. Modules allow you to split your code, in your case tables, into smaller chucks making reading, updating and maintaining your code a lot easier. Compared to _G modules are a lot more visually friendly as well.
If you want the client and the server to both access the same table, like a configuration module, then this can be done easily by placing a module within ReplicateStorage. Whereas with _G this is non existent because the client and server both have separate _G tables.
Another advantage with using modules is that you can OOP a lot easier than you would be able to with using _G. With the use of modules you can have a separate module for each object(I think this is the right terminology) you create making it visually easier to update. You can also make it so the client and server can both access the module as explained above.
Have fun!