You could use a value object like an int value. If you use a type of data not supported by value objects you could use a module script that both scripts require from
You can’t really get variables from other scripts unless it is a ModuleScript. Otherwise, you’d have to do something external like using an IntValue, as @SlinkyShelf0 suggested
I’d personally suggest using module scripts, it keeps it nice and clean and they can be called from anywhere. Values would take up space and I’m not sure but they could be changed, leading to damage in the script (on the client).
Modules would be very good for this, you can read information about them here and here.
If an exploiter was to change the value, and you were to call the value, it could possibly lead to errors as that value could be configured to other things, I can’t be 100% if this is possible, but module scripts is what I would use.
Ig but they want to store the data and use it later in other scripts. Bindable functions have to be connected to which takes more resources that needed
For important values, I would store them in, for example, a StringValue/ObjectValue/etc object. That seems to be their function. Depending on what the variable applies to (player, weapon, model), you could have the string parented appropriately.
Disclaimer: I am a new coder. My advice is dangerous.
I would avoid using value objects. That would require a new instance for every new value you need to save. You are better off using RemoteFunctions or RemoteEvents and send key-data pairs over those and provide each script it’s own table, but you risk the chance that the tables get out of sync if multiple scripts are part of this “data network”.
Personally, I would use ModuleScripts as this lets you not need to add additional instances. This method strays into using Single Script Architecture, so it might not be the best method for you right now. But allows for one script to have full control of all data in one table and easily accessible to all scripts just by requiring it.
To add onto the other suggestions, the recently released Attributes feature may be more performant, intuitive, and more easily integrated over value objects when working on a larger scale.
It can work well alongside modules when managing “custom properties” that would normally be confined to tables and etc., which makes it much more accessible and straight-forward to modify and utilize in general.