How do i keep these variables local?

Okay so, i made a wallrun script and it works fine with one player, but with another player it does not.
There are a few important variables, if one player wallruns then the other cant since these important variables are changed when player1 wallran, so i found one fix; keeping it local sided, now i do not want to keep it local sided (for exploits can easily access wallrunning and can even access the script) so how would i keep the variables local to the player even though in a server script?

For those who don’t get it:

  • Player1 wallruns
  • Important variables get changed
  • Player2 tries to wallrun but failed since Player1 changed the important variables

Thanks!

3 Likes

Mayb add a bool val to the plr which declares if they r wallrunning?

3 Likes

Hmm, but one of the values are an instance (body velocity)
I dont think there is a value for an instance (i have thought of that before and did not use it because of that reason)

No i meant in the script where u wall run, first check if any plrs boolval r tru, if so return the func. Otherwise, change current plrs wallrun bool val 2 tru and after the end of it, set it to false.

Create the bool val by using Players.PlayerAdded

1 Like

But in my understanding, that would make other players inability to wallrun when someone is wallrunning?

Well isnt tht wt u wanted? ignore

Not really, i wanted the players to all be able to wallrun with no problems, but i also want them to be able to wallrun at the same time (since sometimes people’s wallrun takes ages)

Edit: does object value save instances? If so, that could be a solution.

just do

local isWallRunning = {}

-- player starts wall running
isWallRunning[player] = true

-- check if player is wall running
if isWallRunning[player] then

end
2 Likes

Pretty sure it holds a reference to instance.

3 Likes

Not if you were to give each player his/her own BoolValue instance (parented to the player object itself) which represents whether or not that particular player’s character is currently wallrunning. Then when a wallrun is performed by any given player, this created BoolValue instance can be checked for the specific player and the script can act accordingly (don’t perform the wallrun or perform the wallrun as intended).

You can also opt to use an array (which stores player objects in an array which are currently wallrunning) as this post suggests however you’ll need to manage the array by inserting player objects into it when a player begins wallrunning and removing player objects from it when a player stops wallrunning (or leaves the game), with this solution only the script itself will be able to determine if a player is wallrunning or not whereas with instance values parented to the player any script will be able to ascertain whether or not a player is currently wallrunning.

Pretty much i make an array myself everytime a player wants to wallrun and store everything there? Although, if i made an array already but its inside when the player pressed ‘E’ (so the remote event fires and i already have an array in it so for example:

remote.OnServerEvent:Connect(function(plr)
         local arrayTest = {true, false, "E"}

         wallrun(arrayTest)
end)

Would ‘arrayTest’ be local to each player/would that work (and also will it still be local when i give the array to the function, im pretty sure it is but just making sure)

Yes, since each time the server is fired it is being done so by a single client and a new variable named “arrayTest” is declared and assigned a table value containing information regarding whether or not that particular client is currently wallrunning.

1 Like

yeah but don’t, array takes longer to index.

Also yes, for most people just putting a boolvalue in the player is easier.

1 Like

You recommended that he should use an array (I was just reaffirming that it would be possible to do it that way).

1 Like

nope, maybe reread my post. I definitely put dictionary.

1 Like

I was referring to arrays/dictionaries all in the same (they are both just different table structures), as such each would still need to be indexed which wouldn’t necessarily make one more advantageous than the other.

1 Like

To add to this storing a BoolValue instance inside the player object would likely be the best solution as it would allow for other scripts to easily check whether or not a player is currently wallrunning without necessitating the use of RemoteInstances/BindableInstances to facilitate the exchange of data/information between scripts of varying class types.

1 Like

Yeah I don’t think you know what you’re talking about.

An array

-- array  == list of keys
local array = {a,b,c}

If you want to find an element in an array, you would do table.find() which performs a binary search. A binary search goes through each element one by one until it finds the right one. The bigger the array the longer it’ll take to find.


A dictionary (which I used in my post)

-- dictionary == list of of key/values
local dictionary = {a = true, b = true, c = true)

If you want to find something in a dictionary you do dictionary[key] which runs a hash function. I won’t explain exactly how a hash function works (you can find good videos on it). The point is, no matter the size of the dictionary it will be indexed in a (n almost) set number of steps, contrary to an array which takes longer the bigger it gets.


You shouldn’t assume they are the same when talking because they are not an they behave differently. Especially when you replied to me saying “you can also use arrays”. If you want to talk about either arrays or dictionaries you say “table”.

If you want you can make the argument “well using an array will have a negligible difference because the array will be very small (however many players there are)”.

While yes it’s probably negligible to worry about indexing on a table that will have max 20 elements, the point is still true and I personally always use dictionaries when I want to index values to be consistent.

1 Like

In this scenario the difference between an array/dictionary would be negligible hence I was referring to them both collectively as the same (as tables).

Here’s a little benchmark test which shows how little the difference is even on data structures which contain many thousands of entries (in the scenario in this thread the datastructure would likely contain less than 100 items).

Also in future please don’t reply to my post 6 hours after the fact expecting me to remember everything you had previously replied with in the thread.

1 Like