Okay so let me break down my issue:
I am making a tool that lets you execute different attacks based on wether you‘re in the air or not.
The tool’s script…
- Gets the player‘s input
- Disables the player‘s control, if the input is valid (Nullifying JumpPower and WalkSpeed)
- Checks wether the Humanoid.FloorMaterial property is equal to air or not, then executes the respective attack (task.spawn(function))
This system worked great for a while, until I realized, that the player can very easily trick the script by jumping just before the control is disabled. This causes the if statement for Mid-Air detection to return the Humanoid.FloorMaterial while the player is technically still on the ground, allowing the player to use ground attacks briefly in the air. Adding task.wait(0.1) between the control disabling and the if statement did fix the issue, but made the gameplay feel slow and mildly unresponsive. (0.1 seconds can make a lot of difference)
Everything I just described happens on the client!!! (I know it‘s very easy to exploit but I‘m too lazy to add countermeasures)
Is there a more robust way of detecting if the Player is in Mid-Air, or about to jump up?
Is there any reason you’re not using the StateChanged humanoid event instead? In your case, I can imagine it being used like so:
humanoid.StateChanged:Connect(function(old, new)
if new == Enum.HumanoidStateType.Freefall then
restrictGroundAttacks()
elseif new == Enum.HumanoidStateType.Landed then
allowGroundAttacks()
end
Theoretically, the script above should be more robust since it would then rely on the player’s inputs instead of factors not directly affected by players.
That said, I am a little confused about what is a “valid” input. I just assumed that meant some kind of attack that launches the player upwards. My second guess is that if the input was pressing the space bar, you’d change “Enum.HumanoidStateType.Freefall” in my code to “`Enum.HumanoidStateType.Jumping’”. If my suggestion doesn’t work, maybe clarify what “valid” means?
If the tool script is on the client, there shouldn’t be an issue with this latency you’re describing. It must be a different problem. Could you send the script?
Nevermind I realized that the remote events I use to tell the server to disable the player’s control created a small delay, basically the player’s control got disabled too late due to latency. Probably should have mentioned that. Fixed it by just doing it on the client.
Thanks for trying to help though, everyone!