Had a problem with destroying the character and Player:Move warnings firing every frame. It’s worth noting that; This warning does not stack and will flood the client console Has no method of tracing effectively, due to the warning being thrown by the player object.
Did a little bit of digging the error stems from the ControlModule; specifically the OnRenderStepped function. If you change the line;
local Character = Players.LocalPlayer.Character
if Character ~= nil then
if Character:FindFirstChildOfClass("Humanoid") then
self.moveFunction(Players.LocalPlayer, moveVector, false)
end
end
The character controller won’t spam the console with the; “Player:Move called but player currently has no humanoid” warning.
Would changing this part of the Default StarterPlayerScripts break anything?
Is there any way to force the Player:Move warning to also pass a reference of the calling scripts’ name? That would be incredibly useful in deciphering if this is a DefaultScript issue or not, as it’s now taken me around 3 hours to pin this down; A good portion of that was trying to proof against my own code because I’ve got no information to go off. I’ve now got my own version of the PlayerModule using this code, meaning that for any updates to the PlayerModule in the future, I’ll have to;
Manually figure out if the PlayerModule has updated, because it can just change with no warning.
Compare that code against this to see if the issue has been sorted/is still present.
To cap this bug; I’d like to couple it with a Feature Suggestion. We’ve already got the capability to see that Packages have updated and need to be updated to the latest version; is it possible to have the same behaviour for DefaultScripts?
Even though this has workarounds I think this should still be fixed. This started to happen to me previous month and before that the parts of my game which outputs this warning were working without any warnings.
Having the same exact issue, why is this functionality default? I’ll have to implement a new workaround, which will include setting parent to nil, and then calling destroy next time they spawn or when they leave. Pretty weird oversight.
this has been tanking fps between map changes in my game as players are cleared out, and I could never trace it.
Looking at the control module, the self.moveFunction already checks if self.humanoid exists on render stepped, so you shouldn’t have to add another character check to the control module. Within this script, self.humanoid is set to nil only if the “CharacterRemoving” event is fired for the player. Apparently using a Player.Character:Destroy() does NOT fire CharacterRemoving event (intended?), so the control module never sets self.humanoid = nil and you get this flood of warnings until the players character is respawned. Either the control module needs to be updated to handle this scenario, or characterRemoving should fire when a character is destroyed.
Players.LocalPlayer.CharacterRemoving:Connect(function(char) self:OnCharacterRemoving(char) end)
function ControlModule:OnCharacterRemoving(char)
self.humanoid = nil
self:UpdateTouchGuiVisibility()
end
I updated my end round script to loop through players and set player.Character=nil to ‘clear’ the players from the map, which successfully triggers CharacterRemoving and no longer triggers the issue with the control module, but I’m unsure if that has any other side effects yet.
Edit: I now realize this is what was determined in an earlier reply, but i’ll leave this up as it might have some different context.
Ill try setting charater.Parent to nil then, I use a ragdoll system where I parent all of the characters stuff into a dummy model and I’ve been seeing this message in output ever since, hopeful to see it removed
This problem is very annoying since it prevents you from destroying the character without having your console flooded.
It is possible to work around this problem without forking the PlayerModule by overwriting the moveFunction attribute of the ControlModule class as follows (there are checks before overwriting in case Roblox updates their controls module):
do
local player = game:GetService("Players").LocalPlayer
local player_module = player:WaitForChild("PlayerScripts"):FindFirstChild("PlayerModule")
if player_module then
player_module = require(player_module)
if player_module.GetControls then
local controls = player_module:GetControls()
local move_function = controls and controls.moveFunction
if move_function then
controls.moveFunction = function(...)
if player.Character and player.Character:FindFirstChildOfClass("Humanoid") then
move_function(...)
end
end
end
end
end
end
More info on this, recently I updated our game with disabling the default ControlModule in menu and this warning started to pop up in one more event. When it gets disabled I get one of these warnings but player is not even moving.
You can also see this issue somewhere else actively in our game, when someone is infected by a headcrab it prints this error around 343 times.
With both of the instances player doesn’t have a character.
Why not just tempoarily parent the characters, and then move them back to workspace when the map is added.
Or even better, add a place out of view that characters go to, and set their network owner to nil. Then, once the map spawns, move the characters, and return ownership.
This warning doesn’t seem to be a bug, but rather intended behavior.
No I haven’t tried it but it should be nil already when player first joins right? I have the auto load character disabled.
The issue is this warning comes out in cases which are normally fine to use. In my opinion warnings should be for cases which actually warns the developer that something is wrong with the code.
Also I kept the same mechanic for a year but it started when I sent my first reply. So this was not happening before that.
:Remove() as a function just sets them to nil. I doubt this is the best way, but you could remove the Character with :Remove(), and then iterate through its children and :Destroy() everything but the Humanoid, which should stop the errors. Note that doing this may respawn the player if you have CharacterAutoLoads set to true, so I suggest making it so the Humanoid has RequiresNeck set to false before destroying everything in the Character. There will still be leaked memory, but at the very least, a bit less.