I’ve got 5 custom rigs that the player is suppose to automatically change into depending on their race stat but getting it working has been the most frustrating thing I’ve ever done.
The rigs are all animated and work fine when named “StarterCharacter” and parented to StarterPlayer but for some reason, cloning them from ReplicatedStorage and setting Player.Character to the rigs Model just results in a dozen more issues.
For example, none of the animations work now at all, the rig is doing a constant T-Pose and the Camera refuses to follow the rig except when done manually through the Workspace. Even changing the CameraSubject to the rigs Humanoid isn’t working from a script.
I’ve tried everything I can think of, even spent an hour looking for threads where somebody had a similar issue but found none.
Hopefully these represent what I’m talking about better.
–Cloning the Model into workspace and setting the Player.Character to the Model
The best way to do this is to parent the model to StarterPlayer, like when you do you manually insert the model into StarterPlayer. You should set up your script to where when the player clicks that GUI button the model they choose gets put into StarterPlayer, and you should also use Player:LoadCharacter. Also for the animations, what I do is that I have an empty script named Animate in StarterCharacter and parent my own Animation script to the character when the player chooses their character. This is because by default the player will spawn in with the default Roblox script and those won’t work if you’re using custom rigs.
Heres a snippet of code from my game in which I do the exact same thing, it might show you better how you could do it.
Thanks a lot it worked
I was pretty close originally but I guess in my attempt to self fix it I ended up making it worse.
EDIT: Though there is a slight issue, since StarterPlayer is shared between everyone, people who shouldn’t be a certain character are spawning as the character in there.
You’re going to have to set up a remote event to where the client can selects which rig they want to be as and have the server make that player that specific rig.
This is a bad hack and should not be used, or at least not relied upon. StarterCharacter does not exist for the purpose of switching characters out, it is meant to set a default rig for all spawning characters. The proper way is to use Player.Character but support for custom characters on Roblox is God awful (worth making a Feature Request).
I have an early-stage testing place I started working on with DeliverCreations with over 40 rigs, all using modified R15 animations until custom ones can be implemented. This was initially all meant to be private however I left it public once and it got leaked so I can show you progress up to then.
And yes it does use Player.Character, but using that method I’m pretty sure is the only one for multiple rigs and it is very obnoxious lol.
Can you give me a hint as to how you were able to achieve this? You don’t have to share the file if you don’t want to but I can probably figure it out if you give me a rough explanation.
I have a value set in the player and when they respawn they spawn as the given rig with Player.Character =. You disable all the local scripts and then undisable them after like a second or two, I have the time depending on the part count.
Ive solved this problem but its almost like robloxs player system doesnt support setting the players character yourself.
In mine you simply have your character set to nil when you die and then when you respawn it sets your character to the model and then enables all the scripts.
But the problem is when i do this you can now see your characters name/health etc and its almost like your seeing yourself from another players perspective.
Another thing is the damaged/healthbar default roblox gui no longer works for whatever reason even if i disable/enable the default scripts.
so i guess ill have to make all these things myself since they apparently just stop working if you set a new .character instead of respawning or whatever.
This is the code I use that is fully functional in my game in multiplayer. I built it based off of code I found elsewhere and it took forever to find, but I dont remember where the source is.
The player presses a button on a spawn menu choosing the class they want to spawn as and passes the class they’re spawning as to the server in a remote event.
spawnDinoRE.OnServerEvent:Connect(function(player, newCharacterModel)
-- Spawn the given ReplicatedStorage model for the player
local newPlayerCharacter = newCharacterModel:Clone()
-- Save their old character before assigning the new one
local oldPlayerCharacter = player.Character
-- Give the new player model a unique name that the LocalScript knows to wait for
newPlayerCharacter.Name = player.Name .. newPlayerCharacter.Name
-- Assign the player character to their new model
player.Character = newPlayerCharacter
-- Place the player's character in workspace to complete assignment
-- This must occur AFTER player.Character has been set
newPlayerCharacter.Parent = game.Workspace
-- Destroy the player's previous character
oldPlayerCharacter:Destroy()
print("Player character has been set: " .. player.Character.Name)
end)
In the local script the player waits for the server to finish spawning by having the server give the new model a special name and the local script waits for the workspace to have a child by that name. Making it wait by using a remote function instead would probably work too but this code is extremely finnicky and works fine as is so I haven’t tried that. If the client doesn’t wait for the server to finish spawning before enabling their scripts, it’s possible that their scripts are enabled before they’ve loaded in their new character model which can cause errors.
The order that things are done in matters greatly, ie the player.Character has to be set BEFORE assigning the model to the workspace. This also has to be done in a server script or it won’t replicate to other players.
Giving the player a new model/destroying their old character model also counts as a death, so GUI that is set to reset on death will be reset.
