I am getting a lot of complaints from my players all of them mobile players saying they are not able to jump anymore. I didn’t touch my game for 1 month now and, I am pretty sure this isn’t my fault… Or something got updated I am not informed of?
I did a small research and looks like the value “Jump” In the humanoid stay enabled which mean the jump button stay white like it’s getting pressed I will leave the code I am using to make players jump with delay below.
NOT: I used this code in the game for 4 years without issue but somehow getting issues now…
Important: It only happen in mobile somehow.
`-- [[ JUMP DEBOUNCE ]]
Humanoid:SetStateEnabled(Enum.HumanoidStateType.Jumping, false)
Player.CharacterAdded:Connect(function(Character)
ConnectToCharacter(Character)
Humanoid = Character:WaitForChild("Humanoid")
Humanoid:SetStateEnabled(Enum.HumanoidStateType.Jumping, false)
end)
local JumpAntiCheat = false
local JumpDB = false
game:GetService("UserInputService").JumpRequest:Connect(function()
if not JumpDB then
JumpDB = true
if ((Humanoid.SeatPart and not Humanoid.SeatPart:IsDescendantOf(workspace.CarChassis_Workspace)) or not Humanoid.SeatPart) and (Humanoid:GetState() == Enum.HumanoidStateType.Running or Humanoid:GetState() == Enum.HumanoidStateType.RunningNoPhysics or Humanoid:GetState() == Enum.HumanoidStateType.Seated) then
Humanoid:ChangeState(Enum.HumanoidStateType.Jumping)
end
wait(0.75)
JumpDB = false
end
end)
if UserInputService.TouchEnabled then
local JumpButton = Player:WaitForChild("PlayerGui"):WaitForChild("TouchGui"):WaitForChild("TouchControlFrame"):WaitForChild("JumpButton")
JumpButton.Visible = true
JumpButton:GetPropertyChangedSignal("Visible"):Connect(function()
if not JumpButton.Visible then
JumpButton.Visible = true
end
end)
end
`
Expected behavior
When pressing the jump button it should just set the jump value to true then false so the humanoid can jump just like it was before.
Hello! The jump button is not being created by PlayerScripts because you’ve disabled jumping. Accessing PlayerScript created UI by going down the instance tree is not a supported workflow.
local JumpButton = Player:WaitForChild("PlayerGui"):WaitForChild("TouchGui"):WaitForChild("TouchControlFrame"):WaitForChild("JumpButton")
If you’d like to manage your own jump logic, you can disable our jumping with SetState as you’ve done and create a copy of the Jump Button which your own script manages instead of relying on PlayerScripts to create the Jump Button.
These updates to jump button are necessary for bug fixes for other developer flows. We can temporarily disable the update on some games to give you time to fix, or if you’re unwilling to, you can permanently disable it by forking the PlayerScripts and changing FFlagUserUpdateTouchJump to false.
local FFlagUserUpdateTouchJump = false --FlagUtil.getUserFlag("UserUpdateTouchJump3")
Setting the Jump Power to 0 should have the same effect as calling SetState to disable jumping. If you want to achieve a similar effect, you can call SetStateEnabled(jumping, false) in the UserInputService.JumpRequest callback and then enable it again after the debounce wait. The behavior is slightly different, however, because the button will not be visible while the debounce is waiting and you will need to account for your jump mechanics differently. SetStateEnabled and detecting changes to humanoid state are supported APIs, but again if you access the jump button directly, it is likely that your game may break again in the future.
Is there potentially a solution to this that doesn’t require the button to be invisible during the debounce? At least personally, I tend to keep holding the jump button down to ensure I can double-jump as soon as possible in games which support it, and I can only assume hiding the button would potentially break that behaviour? It would be nice to know the intended flow here so I can design my own double-jump systems around it.
At least personally, I’ve been relying on this UI always being the same. Essentially, I want to be able to fit my own UI around the default controls and be able to style the controls UI, too. Given this information, the current alternatives of needing to either fork the module (and sacrifice updates) to prevent breaking changes or needing to re-write the whole PlayerModule, aren’t exactly ideal. Are there potentially other, more supported, solutions to these use-cases coming in the future?
Unfortunately, there’s currently no great way to support a debounce on the default PlayerScript jump. I think at the moment I would suggest making a copy of the UI to manage yourself. We’re aware that interfacing with the PlayerScripts is not ideal at the moment and are currently in the process of updating that workflow. I will specifically note jump debounces as one feature we can support in this process.