-
i want to make a stage system that changes by the altititude or height of the player (like how high up he is)
-
I dont know where to start
-
i have tried going on youtube for tutorials and dev forum but i cant seem to find any
What you can do is get a baseline coordinate, so say you have a part that marks the bottom of whatever amount of stages.
You’d grab the position of it and then you can just subtract the position of the baseline and the player, grab the Y value of that and then you have the player’s current altitude.
Example:
while true do
local CurrentAltitude = (PlayerCharacter.HumanoidRootPart.Position - Baseline.Position).Y
setStage(CurrentAltitude) -- Do whatever with the altitude
task.wait(1)
end
And just a general tip, try to steer clear of youtube tutorials; as these just get you to type over whatever the tutorial is about without fully understanding what the code does.
I will generally say that u should put this in a local script,like that it will not intefere.
1 Like
Well that seems unnecessary, it’d just makes it easier to exploit.
Basic arithmetic isn’t taxing on the server; I’d just put this in a server side script.
Remember kids, never trust the client. - Probably Someone I guess
1 Like
Wait client is eaiser to exploit???
I think it is a rumor.i dont belive that client is easier to exploit
If that is the case,module scripts is the next one
1 Like
Its not a rumor, it is a fact, exploits rely on the memory, which is in the client’s computer. Localscript uses the client’s computer to store variables, connections, etc. Which make the localscript, susceptible to memory manipulation
It depends on whether you require the module on the server, or on the client. Generally, its better to use server for sanity checks and important computational usage. The client is generally used for rendering stuff such as NPCs, or GUIs
1 Like
Yeah no, client scrips cant be seen by the client; hence why they’re called “client” scripts.
People can just reverse engineer them and see if they can fire remote events they shouldn’t be with arguments they shouldn’t be fired with.
I might post a topic about how to prevent client scrips from exploiting
The main philosophy is “Never trust the client”
Any data recieved from the client can be altered by the client and should be treated as such.
2 Likes
@IStoleWafflesId2 Not sure if this is the best advice, but you should try to make an attachment or a simple part at the bottom of your map, then you can simply do HumanoidRootPart.Position.Y - Part.Position.Y which in theory should return a positive number (negative if player is below) of the relative height between the player and the start point. To get more advanced you would probably want to use ray casts, but I don’t think that’s necessary for a simple obby game. Good starting point to learn advanced scripting though. Good luck. If you have any questions feel free to ask.
@Dutch_VII A tip from me would be to wrap that in .Heartbeat. It makes it easier for both the client and server while keeps everything safe from running too fast. For client UI like a meter bar showing your current height can be implemented with this. On the server, you can simply check people’s positions on the heartbeat and implement custom logic based on the height.
@ogether123 This is the #help-and-feedback part of the forum. It’s not meant for discussion. If you would like to know more about why the client should never be trusted, search it up on the forum or read any resource online. This doesn’t apply to just Roblox development. It’s a general question about any server software processing data. It’s like if I told you that there is a gift at your door, you open it and realize you got trolled. That is what the client is. You should never trust it. Exploiters can input any data, it’s the server’s responsibility to assure it is correct. Even with Roblox’s anti-cheat solution to prevent exploiting, you can still do it on other platforms. It wasn’t patched for every type of exploit, that is why you still see hackers. Even if there was an anti-cheat so good, there would still be at least a single hacker to find a hole. You can’t prevent it, you can only defend yourself in the best way by making sure the client can’t do anything weird.
I just went around to play with the byte code of both solutions suggested by me and Dutch. There are caveats by calling .Y individually. It depends on how you further program it. In the given scenario, my case is worse as we are doing an extra 4th call to get a value. Ideally, calling .Position on both and then calling .Y once to wrap it will only have 3 calls. I am not sure how subtracting actually works, but it shows a single call for that.
In other cases where you can save the second object’s initial position, both methods perform the same with only 2 calls. Screenshots of all variants I tried will be below.
In short it would be best practice to use (Object1.Position - Object2.Position).Y
A even better practice would be to store Object2’s Position in a variable. In our case simply local SurfacePartPosition = workspace.Part.Position. This reduces the get calls to only 2.
I understand no one here would care, but I hope my reply makes someone interested in learning more about optimization in general. Also, I am not an expert, so don’t take this as real advice before fact checking it yourself. If you think I am wrong please let me know.
You can make a variable that determines where ground level is in studs:
local groundLevel = 5 -- The amount in studs
We’ll also make a variable for now that will be used as the result for the altitude the player’s character is in.
local groundLevel = 5
local altitude
And another variable to grab the player’s HumanoidRootPart (assuming that this script is inside game.StarterPlayer.StarterCharacterScripts before testing.)
local groundLevel = 5
local altitude
local humanoidRootPart = script.Parent:FindFirstChild("HumanoidRootPart")
Then, we’ll use RunService. RunService can be used to execute code every frame either by the Physics simulation, or the time it takes for your computer to render. (This requires a LocalScript) The event we’re going to use is RunService.PostSimulation, which runs everytime a Physics step was completed. We are using this event since the player’s character only changes during those times.
local runService = game:GetService("RunService") -- Retrieve the service first.
local groundLevel = 5
local altitude
local humanoidRootPart = script.Parent:FindFirstChild("HumanoidRootPart")
runService.PostSimulation:Connect(function() -- Connect the event with a function.
end)
Inside that function, we’ll add an if statement checking whether or not the HumanoidRootPart does exist, since it can be deleted.
local runService = game:GetService("RunService")
local groundLevel = 5
local altitude
local humanoidRootPart = script.Parent:FindFirstChild("HumanoidRootPart")
runService.PostSimulation:Connect(function()
if not humanoidRootPart then return end -- Stop the script and return nothing when the condition is true.
end)
Afterwards, we’ll do some calculations.
The math is simple. We have to subtract the Y-axis of the HumanoidRootPart by the groundLevel variable we set earlier. So let’s do that, and set the altitude variable to the result.
local runService = game:GetService("RunService")
local groundLevel = 5
local altitude
local humanoidRootPart = script.Parent:FindFirstChild("HumanoidRootPart")
runService.PostSimulation:Connect(function()
if not humanoidRootPart then return end
altitude = humanoidRootPart.Position.Y - groundLevel
end)
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.