Sprint not working after death

Help and Feedback Scripting Support
1 
local SpeedDifference = 6

local function sprint(active)
	if Exhausted then return end
	print('Not exhausted', active)
	if active then
		print('add speed')
		Humanoid.WalkSpeed = Humanoid.WalkSpeed + SpeedDifference
	else
		Humanoid.WalkSpeed = Humanoid.WalkSpeed - SpeedDifference
	end
	
	Sprinting = active
end

UserInputService.InputBegan:Connect(function(input)
    if input.KeyCode ~= Enum.KeyCode.LeftShift and input.KeyCode ~= Enum.KeyCode.ButtonL2 then return end

	SprintHeld = true
	sprint(SprintHeld)
end)

UserInputService.InputEnded:Connect(function(input)
    if input.KeyCode ~= Enum.KeyCode.LeftShift and input.KeyCode ~= Enum.KeyCode.ButtonL2 then return end

	SprintHeld = false
	sprint(SprintHeld)
end)

The prints print, and when the player is holding down shift it does print ‘add speed’ but it’s not actually adding anything to the Humanoids speed. Only thing I could think of is this is in a module script. I get the humanoid like so

local Player = Players.LocalPlayer
local Character = Player.Character or Player.CharacterAdded:Wait()
local Humanoid = Character:WaitForChild('Humanoid')

EDIT Just done testing. For some reason the module isn’t being re-required after death, so I’m guessing it’s still running an old version?

2

I can’t speak for the issue regarding no speed being added to the Humanoid since little information is actually provided (nothing on the potential of outside interference, implementation details, so on), but there is something I can address.

This logic is actually incorrect. A module required once will run any code in non-function blocks and every subsequent require returns the same module; it does not run again.

If you have the Humanoid defined at the top of the script like an upvalue, it will permanently reference the old Humanoid. That is why in these cases, you need to come prepared with an updater function or way to catch new Humanoids. Update function is easier since you can add a function to the return contents of the module and keep the upvalue style the same.

local Player = Players.LocalPlayer
local Character = Player.Character or Player.CharacterAdded:Wait()
local Humanoid = Character:WaitForChild('Humanoid')

function module.updatePlayerVariables()
    Player = Players.LocalPlayer
    Character = Player.Character or Player.CharacterAdded:Wait()
    Humanoid = Character:WaitForChild('Humanoid')
end

This will work for you. You’ll obviously have to make modifications to make it fit your code, though. Continue to require on respawn if it’s appropriate but make sure you have a function that can handle spawning and updating.

3

Ye after some testing found it wasn’t being re-required after death. However, the script that does require it does respawn after death

local Sprint  {}
print('Sprint required') -- only prints once, never again

return Sprint

print('new script') -- actually prints twice (prints when player dies, and then again when they respawn)
require(Modules.Sprint)

So not sure why it isn’t being re-required

4

That depends on the location of those two modules. Clearly the module seems to be in a non-resetting container while the script seems to be in a resetting container, but again, lack of information. Where are they located?

5

The script that requires the Sprint is inside a tool (which gets reset on death I believe??) and the sprint module sits inside repstorage

6

So just as I said, yeah. The contents of ReplicatedStorage don’t reset when a player respawns, so the module will only require once and not again. The tool, however, does reset, because it’s lost when you respawn. It isn’t permanent.

The easy way out of this bind is to tailor your ModuleScript to handle respawns through update functions, which you call on respawn after requiring the module. Those will hold the responsibility of updating your upvalues which then your code should be good to go again.

Any module that sits in a non-resetting container should have public (included in return) or internal functions that handle character respawns. For example, the PlayerModule is in StarterPlayerScripts yet it’s able to adequately handle camera and character movement through each spawn.