No, it’s not “best” to use it and it’s not near to it.
I already gave you a perfect code down below
If the game has loot on the ground, the client can tell the server that it wants to get loot X or loot Y. The server just needs to check if it is close to loot X or Y and if necessary other checks and then deliver the loot.
Not everything needs to be done with collisions.
It is not much different from obtaining items through codes in the UI. You will use the information from the client with the server validation.
That’s not a “gain”, that’s pre-gain more specific “collecting”, “collecting” and “collected” are different
Yes, sorry for the word, I’m using Google Translate. But the intention is similar. XD
Anyway, I’m going to leave this topic to myself until the author wants some more information. It doesn’t seem fair for him to read 60 messages with a simple question.
Pardon my low-end PC, but here’s a demonstration of the server-side Humanoid.Jump method (the one you provided) and the RemoteEvent method. The debounce for both is set to the same value (0.05
). Jumps1 is the one you provided, and Jumps2 is using RemoteEvents. I think the results speak for themselves.
I honestly wouldn’t call missing half of the jumps the player actually does and adding half the player doesn’t do “perfect”. The Roblox Developer Forum is not a place to exercise your ego. If all you’re gonna do is keep boasting about how your method is supposedly better for the next 50 replies then I’ll ask you to please shut up. Let the OP decide which one is better. Stop this madness.
Obviously 0.05 is a low debounce lol, it’s going to detect mid-air jumps
I think the OP has stressed enough that they want the “jump under roofs to get jumps faster” to be part of their system. Debounce higher than 0.05 probably wouldn’t cut it then, I feel like.
@7r1zt Replies have calmed down, here’s the solutions we came up with:
-
@ChiDj123’s work
- Detects purely on the server
- Debounce adjustable within
task.delay
- What @NascarDriverBurak101, @Candy_Project and @EmmieShayz suggested, implemented by me
- Needs a RemoteEvent named “Jump” within ReplicatedStorage
- Debounce adjustable using DEBOUNCE_TIME
[server script]
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local jumpRemote = ReplicatedStorage.Jump
local DEBOUNCE_TIME = 0.2
local debounces = {}
local function countJump(player: Player)
print("Jumping [2]!")
end
local function jumpRequest(player: Player)
if debounces[player] then return end
debounces[player] = true
countJump(player)
task.wait(DEBOUNCE_TIME)
debounces[player] = false
end
jumpRemote.OnServerEvent:Connect(jumpRequest)
[client script]
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local jumpRemote = ReplicatedStorage.Jump
local player = Players.LocalPlayer
local function characterAdded(character: Model)
local jumpingConnection = nil
task.spawn(function()
local humanoid = character:WaitForChild("Humanoid") :: Humanoid
jumpingConnection = humanoid.Jumping:Connect(function(active: boolean)
if not active then return end
jumpRemote:FireServer()
end)
end)
local conn; conn = character.AncestryChanged:Connect(function(child, parent)
if child ~= character or parent ~= nil then return end
conn:Disconnect()
if jumpingConnection then
jumpingConnection:Disconnect()
end
end)
end
if player.Character then
characterAdded(player.Character)
end
player.CharacterAdded:Connect(characterAdded)
Hope this helps your problem!
Do you even realize how big of a difference it is between 0.05
and 0.15 - 0.2
?
0.1 - 0.15
might even work great for him
I do not know why we are still arguing over this, all that is needed is a debounce. It’s already been made clear that handling everything on the server isn’t going to be the best solution to this.
Let’s wait for the OP to come back, they’re the judge after all. They’re going to decide what works best for them.
this simple question turned into an argument of 60 replies
You made the solution, leave it and see where it goes. If it needs improvements, you try to improve.
hello. sorry to bump this topic again, I know its been quite awhile… unfortunately, none of the methods worked perfectly for my needs. however I temporarily used @ChiDj123 method for testing.
but eventually I had to change it due to new parts of my map with low roofs. (and too low of a debounce would count multiple jumps for one.)
the new method that I recently started using using is very reliable and is actually much easier than expected.
humanoid.StateChanged:Connect(function(old, new)
if new == Enum.HumanoidStateType.Freefall then
plr.leaderstats.Jumps.Value += 1
end
end)
however, I now have a new issue… since the script is activated whenever the character enters the “FreeFall” state, this is obviously also gonna give the player +1 jump whenever they fall off of a part as shown below.
to fix this, my first thought was to check the characters velocity to detect if they are in the process of jumping upwards, or if they are just falling downwards, however the script never runs at the exact same time, so it’s extremely unreliable to detect the velocity.
this problem, of the script never running at the same time and being steps off, also applies to any other method that I can think of so I’m stuck on this for right now
If anybody has any ideas I would appreciate it.
and I appreciate those to helped me, I thank everybody involved in this topic, and I didnt mean for it to turn into an argument. LOL
OP, if you’re going to take that route, then why not do it in a logical order.
- player presses jump input via UIS or CAS or whatever your preference.
- check for freefall
- debounce until state of humanoid is changed
- Profit and repeat…
Either way, everything about the humanoid state is physics based which is handled by the client and then replicated to the server. That is absolute. Any approach you take from this will have it’s flaws but a few band-aids and cute code fix stickers should produce somewhat of a result that I believe you’re looking for.
as the title states, I’m trying to do this all on the server, which eliminates the possibility of using UIS, or CAS.
additionally, even if I were to use remoteEvents, the client could spam the space bar and as long as they are falling in the air, they get +1 jump every time.
Every reply above mine quite literally explains all your possibilities, I suggested a debounce, there’s nothing wrong with using a remote function with a cooldown.
I understand your approach but again with how lua handles physics, it’s all client sided, so regardless of how you want to do it. You can’t exactly just ignore the set fundamentals. That’s not saying that there’s not cheap hacks or workarounds but it’s quite literally impossible to do anything regarding the humanoid on the server side.
If it did work like that it would computationally expensive to say the least.
So it’s either you use a remote event or you try some cheap hack like storing cooldowns for each player on the server-side,
Also back to your original idea on freefall states, it’s no different then using the jump functions provided above. That’s why I said if you’re taking that route then use UIS or CAS, and just because you scripted that on the serverside doesn’t mean it’s not susceptible to exploits. Remember the client Replicates everything to the server, meaning they can do whatever it is they want and bypass your server script you just made.
Also if you’re paranoid about using remote functions/events, Suphi Kaner on YT has a great module and explanation on how to avoid memory leaks with custom remote functions.
I have been struggling with similar problem, and found this:
And it really works…
Your best solution is to have queue for your jumps.
Image this, player jumps, client fires server that he jumped.
Server put’s the jump in a queue, it could be even timestamp, but I don’t think it’s needed.
local queue = {}
jump.OnServerEvent:Connect(function(player)
table.insert(queue[player], true)
end)
--[[
Now where I sent you the script for server jump detection,
just additionally check if player has a jump in queue before accepting the jump.
It's easy as that, and for the record no one will care enough to exploit this,
don't even think someone would prefer to spam the event and then keep falling,
it's slower to farm that way
]]
Animations are physics based, Physics is handled by the client and replicated to server and then to other clients, the fundamentals don’t change, no matter what. Only work-arounds.