Respawning has been giving me issues. When I change the player’s character property to a different model, the old model that it previously was is instantly destroyed and there doesn’t seem to be a good way to deal with the issue without cloning the old model before it is destroyed and reparenting it, which isn’t optimal for performance in my case. Any thoughts?
Why don’t you just script your own respawning system.
First off you script your own custom reset function like this:
local resetBindable = Instance.new("BindableEvent")
resetBindable.Event:connect(function()
-- Implement custom reset logic here
end)
-- This will remove the current behavior for when the reset button
-- is pressed and just fire resetBindable instead.
game:GetService("StarterGui"):SetCore("ResetButtonCallback", resetBindable)
Then after you would script how deaths will be handled on a player like this:
firstly, you need to disable the dead state both on the server on the client like this
humanoid:SetStateEnabled(Enum.HumanoidStateType.Dead, false)
secondly, you would detect whenever the humanoid health changes:
humanoid.HealthChanged:Connect(function(health)
if health == 0 then
--custom respawn logic here
end
end
It essentially is a custom respawning system because CharacterAutoLoads is set to false so I handle the player spawning on my own, but the issue is strictly changing the character property of the player to something else - when done, the previous character is destroyed, which in my particular case is a problem. You can see what I mean by running a baseplate, going into the server and setting your player’s character property to nil.
oh I see what you mean but I dont understand what your original question is really asking could you go more in detail?
Awh yeah. Have this problem every time. Working with characters is a pain. I do it for live run time character swapping and it’s a gruesome experience.
Really, there isn’t any other way to do this. You can clamp the Humanoid’s health to 0.1 and render health below 1 as dead. Then, parent the character to ServerStorage and set the Character property of a Player to either nil or your new model.
Thing is that setting the Character property is treated as a respawn, so you might encounter some issues if you don’t cover for that case.
Luanoids are always an alternative to Humanoids. If you add some meaningful functionality to it, you should submit a pull request so everyone can benefit.
Luanoids circumvent the issue of changing the Player.Character property. It’ll be essentially changing a set of problems (fighting hard to change or built in behavior of Humanoids) to another (stock Luanoids don’t come with as many features as Humanoids yet).