Client doesn't see changes made to a variable on a server-side module script

I’m still trying to get used to using module scripts - I neglected them for a while but I’ve slowly started using them and am really starting to enjoy the benefits of them - reusing code segments, global cross-script variables, splitting my code into more manageable sections.

However, I’ve run into a bit of a snag. If I have a module script with a variable and that variable is changed by a server-side script, any attempts to grab the module’s variable from a localscript just passes on the original value, not the value that it was changed to by the server. This is what I’m running to test this:

I have this ModuleScript in ReplicatedStorage:

local module = {}
module.value = 1
return module

I run this script server side:

local test = require(game.ReplicatedStorage.Test)
test.value = 99

Then I run this in a LocalScript from the client:

local test = require(game.ReplicatedStorage.Test)

but it results in 1. Not 99. It doesn’t see the changes that the server made. Is there a way around this?


I just thought of something…

I suppose after I change the value on the server I could use a remote event and fire all clients to change the value in the module locally on all clients

but still open to suggestions if there’s a better way.

The client and server have their own copies of that module script. And therefore, will not be able to communicate through it.


Don’t get confused on how these module scripts work. Module scripts are designed to run code, not store variables across multiple scripts and/or devices as @Fm_Trick pointed out.

You would have to fire RemoteEvents over to the server to replicate your values.


In not sure if this would work, but have you tried re-requiring the module after you’ve applied a server change to it?

I don’t think it’s going to be practical, but I’m curious.

That won’t work as when you require it you get a copy of the module script so the original module script doesn’t change.

1 Like

You can fire remote events, as WatermelonArray mentioned, but you can also just use NumberValue objects, or whatever *Value object you need.

These are annoying if you have complex data structures, but if you have simple ones, they make coding very easy – you have a single object which you can watch for changes (Changed:Connect(...)) and you can poll it at any moment without network lag/possibility for failure, as its value is always cached on the client (obviously if you’re polling it as the server is asynchronously changing it, you may get the wrong value, but it’s hard to say the value you get is “wrong”).


I’m probably going to end up using a module for a bunch of global constants that should never change, and then use NumberValues, IntValues, etc for some systems in my game where the variables will change and multiple scripts need access to them from both client and server.

NumberValues drive me insane though with how they add a bunch of extra decimals. Like if I put 2.1, it changes to 2.1000000000000000888. I hate it so much that I end up using a string value and tonumber(StringValue.Value) in my code.


What do you mean by this? ModuleScripts aren’t only for running code. They can be used to hold static variables that you want to transfer across scripts, such as settings variables. ModuleScripts can run code and can be for reusing certain code, but you can also store variables in them and not use any functions.

@idontkno Use IntValues then. They don’t have float point errors. You can also use a math function (i.e. floor) to take out the decimals.

1 Like

that’s great if I want an int value. not so great if i need a decimal value.


Did a bit of experimenting with this and you are right about that one, My mistake. I just got mixed up with how variables can still reference the values of other varaibles. I have using other programming languages and system where they will not reference the variable but instead copy the value and assign it as a new one. This lead to me getting the idea that returning an array for example will not reference the value but simple copying it. Purely a mistake on my behalf.


That is a fundamental flaw with the way computers store decimal point numbers in general. 2.1000000000000000888 is the most accurate that you can get when trying to store a number using the data type that Lua uses. The Lua script has the exact same value stored before putting it in the NumberValue.

Lua uses something called a “double”, which is a 64 bit floating point number, the standard for storing decimal places. You can’t store 2.1 in a floating point number for the same reason you can’t reasonably store 1/3 in decimal form in written language.

In short, floating point numbers work like binary scientific notation where you have 2 to the power of an exponent multiplied by a fraction: 2.1 is approximately 1.110011001100110011001100110011001100110011001101 * 2^1

This allows computers to store incredibly large and incredibly small numbers, but the precision is limited by how many bits the fraction has, so not everything can be stored.

You can’t really do much about this other than rounding off numbers when displaying them, or checking for “close enough” values within a range, like: isZero = x < 1e-5 and x > -1e-5

Here is a tool you can use to check the binary representation of a number if you want to play with it yourself:

I wouldn’t recommend using strings as a substitute for numbers, because in the end you will keep coming back to the same problem of lack of precision when you convert back to a number. You also lose out on speed because of the conversion that you do.


Yeah I was already somewhat aware of why it does that. It just bothers me seeing these long drawn out decimal numbers in kind of an OCD way. Perhaps I should just try to ignore it the best I can and save myself from conversions in scripts.

Did roblox change how they displayed NumberValues on the front end to users at some point? Because I’m pretty sure I remember using NumberValues several years ago on roblox without being bothered by them adding a bunch of decimals.

I’m not sure. One part of me says yes, the other part says it was always like that. They might have had different rounding for the text display at some point. I couldn’t really tell you unless I had a time machine on me, or more realistically boringly, an old build.

1 Like