Self-Displaying Variables in Hierarchy

[b]
Updates: You can now attach changed ‘listeners’ to your variables as so:

x = 5;
dastring = "hi";
changed_x = function(last,current)
     print("x was ",last," and now x is ",current);
end

changed_dastring = function()
     print(dastring);
end

last and current are just default parameters I pass in for convenience.

The code required to do all this in a script has now been condensed to one long line, for neatness.
The thing doing all the work behind the scenes is still retrieved from a module script , however. (from the giant line)

[/b]

[b]
Also, keep in mind :
You may want to declare variables that are changing about 500 times a frame
for extremely frequent calculations, i.e a pathfinding script. Since declaring it as local disregards it from the functionality
and thereby prevents lag. (Since updating a number value so frequently will cause it )

[/b]
Hey all, I’ve recently developed a little system to display variables that you declare in a script in a model under ReplicatedStorage. This can possibly allow for nice script-script communication, as I’ve already been using it for.

The test place is linked at the bottom. It is un-copylocked. There are a few bugs you may find (rare) but if you do, just declare the variable that is having issues as local and it’ll remove it from the visible hierarchy.

Updating any variables instantiated as object/bool/number/string values will update the according variable in the script, and all variables will lively update their value to the corresponding game object.

For instance, if you have a variable in your script,

x = 5;

It’d create a number value under ReplicatedStorage->Variables->Your Script Name , name it x,
and assign it’s value to be 5.

If you then set the value of the new instantiated object to 6, the variable in the script ‘x’ will be set to 6, and so on and so forth.

I’d love your guys’ feedback on this! I’ve spent a bit of time on it working out the major flaws, since I’m new to metatables and mainly did this project to learn more about them.

Test Place : wat - Roblox

Screenshot:

Sounds cool, maybe you should have the variable in the script so you could do stuff like this:

Script 1:

[code]blah = false

while blah do
print(“trololololo”)
end[/code]

Script 2:

wait(math.random(10, 20)) game.Workspace.troloscript.blah.Value = true

Makes more sense than

game.ReplicatedStorage.blah.Value = true

[quote] Sounds cool, maybe you should have the variable in the script so you could do stuff like this:

Script 1:

[code]blah = false

while blah do
print(“trololololo”)
end[/code]

Script 2:

wait(math.random(10, 20)) game.Workspace.troloscript.blah.Value = true

Makes more sense than

game.ReplicatedStorage.blah.Value = true

Unless I’m mistaken/ thinking of Another platform , local scripts cannot directly access members/scripts of other clients?

If this is so, it may be easier to just keep it in a place where all scripts can directly access

Local Scripts can communicate with one Server Script using RemoteFunctions. That Script can fire a other RemoteFunction and give it a table that can be loaded using getfenv().

local function Unload(Table)
for i,v in pairs(Table) do
getfenv()[i] = v
end
end

Unload(A Table object)

The overhead… :uhhh:

Also, here’s an image if you didn’t want to download the place file ^-^

[quote] Also, here’s an image if you didn’t want to download the place file ^-^

[spoiler]

[/spoiler] [/quote]

well you can’t download attachments.

Didn’t know you couldn’t download attachments, added the link to the uncopy-locked place at the bottom of the topic description

Re wrote some things and added some neat changed ‘listener’ syntax for your variables. You now no longer have to do silly things to detect when a variable or factor is changed in your script from an outside source!