Character spawn overriding

I’ve rewritten this after some more research.

I have a local script that repositions a character using the HumanoidRootPart.CFrame = (goalCFrame).
However, the R15 loads asynchronously, seemingly across multiple frames. It’s quite ugly, and possibly gamebreaking. Take a look at this!:

Only happens in real servers, not local playTest, such partially loaded character flashes. Yuck!

Any ideas? Or will I just have to hide this ugly thing in a spawn cage in a far off land? Could hackers game it? Should I even be concerned? If they don’t have a HumanoidRootPart, don’t do damage registrations, so if a hacker gets in a cage they can’t shoot at these loading horrors and damage their later, loaded states?

Have you waited for the Character to load using Player.Character or Player.CharacterAdded:Wait() before teleporting them?

My intent here is to reposition the character instantly. The fact that I have to wait for just the HumanoidRootPart is even to much, because clearly, there are parts appearing before that at the actual spawn. I was thinking if there isn’t a HRP I could locally set this loading character’s parent to nil to basically mask it, then throw it in when it has its HRP and has been locally repositioned where I want it to be. Still very shady though.

I don’t think you can reposition a character until their HumanoidRootPart has loaded, perhaps there is a way, but I’d expect it be convoluted. Is there any real reason why you don’t want to use traditional respawning?

from :
" the request is processed asynchronously instead of synchronously. This means other tasks will be able to continue while the character is being loaded, including the rendering of the game and any other tasks. Also, this function can be used in script, while…"

So basically this is intended behavior, which I dislike. I don’t want to have in game parts for spawns that I’d have to screen from raycasts, get in the way of other stuff. I want to punch in coordinates and stick the character there. Locally, because of what I’ve already made basically.

This isn’t behaviour you can override unfortunately. This is another product of the engine which engineers have a planned fix for, but have delayed due to putting resources elsewhere and encountering challenges during production that can’t be solved right now.

Refer to the following announcement thread. It outlines the current spawning behaviour which explains why this is happening and the future spawning behaviour which will fix this.

1 Like