To avoid the XY problem, what I want to accomplish is to be able to give a set of variables a value, but the variavles only actually get assigned that value (which is global) when one “master” variable is true. For example:
I know that script does not make logical sense, but you get the idea. My solution to this is to have tbe variables use the same name, but under a local variable (local A: number), set the local variable, and then use _G.A = A if Master is true. I wanted to do this efficiently using a table of all the globals, and a corresponding table of all of the locals.
local A,B,C = 1,2,3;
localvars = {A, B, C}
globalvars = {_G.A, _G.B, _G.C}
for i=1, #localvars do
globalvars[i] = localvars[i]
end
What exactly is your use case? This system seems very unconventional. My guess is that in whatever context you’re implementing this system, there’s a better solution that doesn’t involve finding workarounds to traditional programming means. You’ve found a solution before you’ve figured out the problem and are now trying to reverse engineer a process. Could you clarify why you need this system?
When a user is picking their new settings, make a copy of the settings table. This table can be modified freely without impacting the actual settings of the user. When the player clicks “Save”, this new table replaces the original settings table. This will allow for the settings to be applied only once the user saves his/her settings.
How would I impliment this when each variable is global? I’m assuming I would need to replace a global version of settings with a copy of the local one, but would there be an easy way to keep each setting (variable) under _G.?
Yeah, you’d need to replace a global version of the settings with a copy of the local one. Though, I’m still confused on why you wouldn’t want this to be the case. What’s the issue with replacing the table with the local one? It’s a very Lua-friendly approach to the problem you’re having. Also, why are you using _G instead of a ModuleScript? Generally speaking, _G is bad practice because there is no state handling, and multiple scripts may use it conflictingly.
Theres a sectiom of the settings used by administrators. This is implimemted in a modulescript that is analyed by the server calling certain events when a settings is toggled that can be viewed by all players.