If I were to create a local variable in a module, like "local boolean = false" in a module, would all players share that variable when using the module? Like for example if Player 1 were to change boolean to be true, would Player 2 also see the local boolean as set to true? Or would Player 2's boolean still be false while Player 1 has it set to true?
#Quick question about how Local Variables created in Modules work.
crisp sierra
vital mantle
If I were to create a local variable in a module, like "local boolean = false" i...
Nope. If you require the module on the client, it'll only be that for the client that required the module.
Servers are kind of the same in that regard. Each server would have a unique instance of each required module.
crisp sierra
Ah ok thank you
crisp sierra
Nope. If you require the module on the client, it'll only be that for the client...
also, do you know if players running modules can override another player who was running the module beforehand?
I've been trying to test my code and for some reason, one player using a module works but the player who uses it afterwards doesn't work entirely correctly
what's supposed to happen is it creates particle effects on the person who ran the module and initiate an animation along with setting walk speed to 0 and turning off the camera turning
but the second player just reactivates the particles on the first person who used it and it doesn't unlock the second player from being stuck in place
vital mantle
also, do you know if players running modules can override another player who was...
Modules create their own instance when required.
A single server will have its own module.
Each player will have their own modules.
They cannot affect each other, unless they use things outside of the module
crisp sierra
like cloning a set of particle effects?
vital mantle
but the second player just reactivates the particles on the first person who use...
This has more to do with how your module works rather than overwriting modules.
crisp sierra
Oh
vital mantle
If you share the code then I can tell you
vital mantle
I'll see if it fits in a message
That's far too big.
If this is running on the server, the server will use the same module.
crisp sierra
yeah I'll try chunking it into pieces
module.Start = function(Player: Player)
if game.ReplicatedStorage.PlayerData:FindFirstChild(Player.Name).UniqueVals.UniqueBool.Value == false and isTransforming == false then
game.ReplicatedStorage.PlayerData:FindFirstChild(Player.Name).UniqueVals.UniqueBool.Value = true
module.Transform(Player)
end
-- if game.ReplicatedStorage.PlayerData:FindFirstChild(Player.Name).UniqueVals.UniqueBool.Value == false and humanoid.Health >= (humanoid.MaxHealth/2) and isTransforming == false then
--module.CreateBaseAura(Player)
--module.BaseStart(Player)
-- end
end
module.End = function(Player: Player)
if game.ReplicatedStorage.PlayerData:FindFirstChild(Player.Name).UniqueVals.UniqueBool.Value == false and isTransforming == false then
module.BaseEnd(Player)
end
end
Are you doing this on the server? Do you use require in a server script?
vital mantle
Okay, so like I said, the server will have the same instance of the module.
So the server is using this same module any time you require it
crisp sierra
so should I not be using require?
vital mantle
No you should be. It's fine. But you have to do things differently.
crisp sierra
Would it break if the script using require was a module script?
it activates using a module attached to a thing that fires whenever the specific button is pressed
vital mantle
All module scripts must return one value. require runs the module and stores whatever was returned. Any future calls to require will just give the thing that was returned when it was first run.
crisp sierra
Ok
sharp shuttleBOT
** You are now Level 6! **
crisp sierra
module.Charge.Begin = function(Player: Player)
local character = game.ReplicatedStorage.PlayerData:WaitForChild(Player.Name):WaitForChild("Character").Value
if script.Charges:FindFirstChild(character) then
local ChargeHandler = require(script.Charges:FindFirstChild(character))
ChargeHandler.Start(Player)
end
end
module.Charge.End = function(Player: Player)
local character = game.ReplicatedStorage.PlayerData:WaitForChild(Player.Name):WaitForChild("Character").Value
if script.Charges:FindFirstChild(character) then
local ChargeHandler = require(script.Charges:FindFirstChild(character))
ChargeHandler.End(Player)
end
end
So when this is run a second time, because I used require, it would run using the first player who used it and not the person who used it afterward?
vital mantle
```
module.Charge.Begin = function(Player: Player)
local character = game.Replic...
Are you requiring the module you're in?
crisp sierra
Yes
as in the module this is all happening in? Because it does get required by the script that calls it when an input happens
so the module this is in gets required and then these modules it's calling are also required
vital mantle
so the module this is in gets required and then these modules it's calling are a...
It's going to return the same value. So you're not making new modules. Just getting the initial one again.
vital mantle
So should I remove the require part?
You need to rethink what you're doing here.
What part of this needs to be unique per player
crisp sierra
charge handler
because it's the module with the actual code for the animation and effects and stuff
vital mantle
because it's the module with the actual code for the animation and effects and s...
Is this module script cloned to the player's character? Are you retreiving it from the same place every time?
crisp sierra
it's not cloned, at least I don't think it is, and it gets retrieved from the same spot each time
but it differs from other inputs that start attacks or animations because those have handlers that get called and then direct to the right character attack module
vital mantle
but it differs from other inputs that start attacks or animations because those ...
Is it meant to be unique per character? or per player? Like does it only matter when the player is spawned in?
crisp sierra
It’s supposed to activate separately for each individual
Like one player transforming shouldn’t affect how another transforms
So unique in however that way is
vital mantle
Like one player transforming shouldn’t affect how another transforms
Why don't you put the module in StarterCharacter and then require it from there?
by that I mean the module will be copied over to the character when they spawn, so you can just require the module from the player's Character
crisp sierra
Should I be putting all modules that activate player specific things in starter character?
crisp sierra
by that I mean the module will be copied over to the character when they spawn, ...
Wouldn’t that make exploits easier?
vital mantle
Wouldn’t that make exploits easier?
If you made your system without thinking about exploits it can
crisp sierra
I forgot who told me but someone else said that exploiters can only change stuff in the character
crisp sierra
If you made your system without thinking about exploits it can
Ah
Ok
I’ll try and move it over to playerscripts
It won’t cause too much lag though right?
vital mantle
Ah
My suggestion is just do this differently. Use tables to separate variables into a per-player basis, and have a module function that just does what it needs to for the given player
crisp sierra
Because the control module is the parent of all the separate fighter modules that are all different for each of my playable characters
crisp sierra
My suggestion is just do this differently. Use tables to separate variables into...
So put values in a table and call the value from the table based on the player it belongs to so it won’t mix things up?
That makes sense
vital mantle
So put values in a table and call the value from the table based on the player i...
local value = {}
value[player] = 0