WalkSpeed Roll Script Issues

I’ve gone through multiple iterations of a rolling script and have decided to work with walkspeed this time. In the local script, I create a target point slightly ahead of the player’s model, increase the player’s walkspeed slightly, and then direct the player to walk in that direction. I’ve come across some issues so far that I’ll describe here, any thoughts or suggestions would help since I’ve only recently gotten back into scripting and don’t fully know the ins and outs of the Roblox API yet.

Issue #1: The main issue I’ve come across is that when the player decides to input a movement direction in the middle of the roll, the MoveTo command is instantly overridden and the player is stuck in place. I would like for the roll to be completed without input from the player since it was originally the player’s choice to roll and the rewards or consequences that come with that should be followed through.

Issue #2: The second issue comes from using the roll on a slope. Since I’m using MoveTo, I’m simply giving the script a location that’s a few studs ahead of the player. However, if the player were to walk up a steep slope that’s very high, the script would want the player to climb up a specific number of studs, without taking the Y value into account, making the player move for a much longer period. I want to know if there’s a way to first detect a slope or large change in Y value ahead of the player and properly approach the roll so that the player doesn’t get stuck walking up a large slope.

Here’s the part of the code where I use the MoveTo command, I don’t think any of the other sections should matter that much, after this part I pretty much just set the walkspeed and jumppower back to their original numbers.

if hrp then
	local animator = humanoid:WaitForChild("Animator")
	local rollAnimTrack = animator:LoadAnimation(rollAnim)
	rollAnimTrack:Play()
	local targetPoint = hrp.CFrame * Vector3.new(0,0,-23)
					
	humanoid.JumpPower = 0 
	humanoid:MoveTo(targetPoint)
	task.wait(0.15) -- for timing with the roll anim
	humanoid.WalkSpeed = 45

I’ve already attempted different rolls with CFrame and VectorForce. CFrame felt very choppy at times, especially with the camera also teleporting slightly each time the player would move slightly forward in the RenderStepped, but if no solutions are found then ill probably go back to it. I also haven’t worked with directional movement with the roll just yet, currently it just sends you forward, so don’t worry about that. If there are any questions or any further information anyone needs, ill try and reply with it as quickly as I can.

If you wouldn’t mind providing a test place with a few of the issues present I’ll take a look into fixing it for you.

Sure thing, here’s the link to the experience. I also modified the script when moving it over so here’s the full script in case there’s any confusion or questions with it. Don’t mind all the task.wait stuff, I’m just timing the animation to my liking.

local UserInputService = game:GetService("UserInputService")
local player = game:GetService("Players").LocalPlayer
local ContentProvider = game:GetService("ContentProvider")
local debounce = false
local rollAnim = Instance.new("Animation")
rollAnim.AnimationId = "rbxassetid://13824081467"
-- My anim: 13824081467


ContentProvider:PreloadAsync({rollAnim})

function Roll(input, gameProcessedEvent)
	if gameProcessedEvent then
		return;
	end
	if UserInputService:GetFocusedTextBox() then
		return; --makes sure the player isn't chatting
	end
	if input.KeyCode == Enum.KeyCode.Q then
		print("Player has pressed Q")
	
		local character = player.Character
		local humanoid = character:WaitForChild("Humanoid")

		if humanoid:GetState() == Enum.HumanoidStateType.Freefall or humanoid:GetState() == Enum.HumanoidStateType.Jumping then
			return
		else
			if humanoid.Health > 0 and humanoid.WalkSpeed > 0 and humanoid.JumpPower > 0 and debounce == false then
				debounce = true
				print("Roll checks passed")
				local hrp = character:FindFirstChild("HumanoidRootPart")
				if hrp then
					local animator = humanoid:WaitForChild("Animator")
					local rollAnimTrack = animator:LoadAnimation(rollAnim)
					rollAnimTrack:Play()
					local targetPoint = hrp.CFrame * Vector3.new(0,0,-23)
					
					humanoid.JumpPower = 0 
					humanoid:MoveTo(targetPoint)
					task.wait(0.15) -- for timing with the roll anim
					humanoid.WalkSpeed = 45
					task.wait(0.37)
					humanoid.WalkSpeed = 16
				end
				task.wait(1)
				humanoid.WalkSpeed = 16
				humanoid.JumpPower = 50

				task.wait(0.4)
				debounce = false
			end
		end
	end
end	


UserInputService.InputBegan:Connect(Roll)

The place isn’t editable, but I see what you’re talking about now.

Are you okay with the MoveTo() ending when the roll ends? Why not just cancel the MoveTo() when the roll animation has stopped?

To prevent player movement from interrupting the MoveTo(), just disable their controls:

local Controls = require(game:GetService('Players').LocalPlayer.PlayerScripts:WaitForChild("PlayerModule")):GetControls()
Controls:Enable()
Controls:Disable()

Yeah the Controls Enable and Disable works, I was unaware that was something I could toggle through that module script. I also added the detection for if the player’s animation stops which works great. The only issue that comes with disabled controls is that when the animation stops and the player has continued to press down a directional input since the beginning of the roll, Roblox voids the input. This leads to an issue where the player needs to input a directional key after the roll has finished, which doesn’t feel smooth. Any thoughts on how to fix this? If not, all good, seems like something that would be troublesome to fix with the WalkSpeed roll anyway, might have to experiment with linear velocity or vector force a bit more to get a smoother and more responsive roll. (Also do you know which is better or used more often?)

With linear velocity you’ll have to put a downward force strong enough to smoothly constrain them to the floor. Otherwise, you’ll have players rolling off that ramp and flying through the sky, haha. As for the issue that arose after disabling their controls, just store the directional vector for their movement before / during the roll and apply it when the controls are given back. I’d enable controls and apply the movement a tad bit before the roll ends so it’s smooth and “fades in.”

If you want them to resume walking in the direction they were previously walking in before the controls were disabled, you can use humanoid:Move(DirectionalVector) after the roll ends and their controls are restored. You can grab the previous walking direction by storing Controls:GetMoveVector() when the roll initiates and before their controls are disabled, or you can do something fancy with the LookVectors of the HRP or Camera.

humanoid:Move(hrp.CFrame.LookVector) - Make them move in the direction their HRP is facing when the roll ends until interrupted by their own movement. (Similar to their previous position so long as nothing has reoriented the HRP, such as being smacked around or walking into an obstacle.)

humanoid:Move(Camera.CFrame.LookVector) - Make them move in the direction their camera is facing when the roll ends until interrupted by their own movement.

Or you can use a separate function that grabs the keys they’re holding and converts those to a directional vector to return and use with humanoid:Move() when the roll ends.

local UIS = game:GetService("UserInputService")
local VecZero = Vector3.new()
local MoveDirection =
	(UIS:IsKeyDown(Enum.KeyCode.W) and Vector3.new(0, 0, 1) or VecZero) +
	(UIS:IsKeyDown(Enum.KeyCode.A) and Vector3.new(1, 0, 0) or VecZero) +
	(UIS:IsKeyDown(Enum.KeyCode.S) and Vector3.new(0, 0, -1) or VecZero) +
	(UIS:IsKeyDown(Enum.KeyCode.D) and Vector3.new(-1, 0, 0) or VecZero)
end

My personal route would be to modify or rewrite the control module to suit my needs. This should do what you want it to do though.

These all look good, I appreciate the help. I’ll try out all of the solutions to see which best suits my needs, thank you.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.