Can we clone modules and load data into them after we cloned them? I clone a module for each player in my game and want to update certain toggles in the module script because of where they left off. Are we able to do this? in studio it works but in game it doesnt load the data into the module.
Before i do this, I load a datasfore, and all the values are there, but don’t load into the module script.
Clones are true clones of the original Object, meaning they contain their own copy of the data. Modifying the original will not reflect to its copies.
Now, I’m a little curious as to why you’re putting toggables inside a ModuleScript in which you clone. Why not a UserData module which you could then require and call it’s API from the cloned module …?
Guess I should better phrase my question. What are you trying to accomplish here? It’s a little unclear, but I’m understanding the situation as each copy is for each player, and you want to change those toggles within the copied module. As long as you require the module and expose the togglables, absolutely! … But let’s both get on the right page first before we continue.
As I understood it, he wants to create a copy of the modulescript (acting as a template) for each player, and then later write to each player’s copy with relevant information. Which he should be able to do without issue as far as I know.
OP, if you could provide some psuedo explaining what you’re trying to achieve, that’d help us help you.
I suggest using something like classes in a module scripts instead.
Example code:
local Example = {}
Example.__index = Example
function Example.new()
local self = setmetatable({}, Example)
self.exampleText = "Example!"
return self
end
function Example:GetExampleText()
return self.exampleText
end
return Example
Or if you don’t understand metatable stuff, and you don’t want to learn it either / hate using self everywhere, you can use my “simple class” style:
local MyClass = {}
function MyClass.new()
local this = {}
local mCounter = 0
function this:DoSomeThing()
mCounter = mCounter + 1
return mCounter
end
return this
end
return MyClass
As a bonus you get true encapsulation to dissuade you from manually fudging the object’s internal state. Downside is that it can make debugging harder, since there’s no single state table to inspect in the debugger. You also might think that it’s slower, but upvalues are so fast in Lua that it’s actually quite performant as long as you don’t have too many functions in the class.
In reply to the OP, yes, you can do this. As I am learning from the other posts here, that there are better ways to do this, but as of now my game uses the method described in the OP for information on items in my inventory, and also for information on a players pets, a pseudo ‘class’ setup (I even have the copied modules named class ). So it should work. Dumb question… but do you think FE might have an effect on this? Is your Filtering Enabled turned on?
Whether you’re using one module that creates multiple tables (“objects”), or multiple modules that each create one table is simply a formality of how you’re tracking what data is attached to what player.
If you’re using one module then you’re going to be using some script / other module somewhere to track which table is associated with with which user, vs if you use multiple modules then you’re using the Roblox hierarchy to track which table is associated with which user.
IMO it’s kind of silly to use multiple modules, because you probably have to have a script that’s copying the module for each player… in which case why don’t you just have that script that’s doing the copying track what table goes with what player in the first place and skip creating the extra module copies?