LoadCharacter() hogging server resources

Having the same problem, i’ve worked in a fighting arena game with custom characters
and when people spawns in, the server cpu usage increases up to 100%

2 Likes

This is the third time this year that Roblox has caused my projects to come to a halt. When setting the character/load character, the game experiences severe lag/freezes.

Hours were spent narrowing down the issue until I tested the game, which is a quest game, without the character loading. The game was super smooth, as expected. After checking the script profiler, it seems most of the resources are taken up by core scripts.

It gets even worse if there are tools in the person’s backpack; the whole client/studio crashes and closes, causing the game’s development to freeze. The test/debug tool was nothing but a tool that loads one and plays animation.

(Project details blacked out due to the owner’s request for confidentiality)



2 Likes

Seems like we’re in the same boat with this issue as I detailed in my initial scripting support thread. Whatever it is, LoadCharacter does not seem to like something to do with either the Backpack, or the ScreenGui elements in StarterGui.

I noticed if you have massive UI layouts with multiple frames, this causes the game to absolutely lock up for about ~2.5-3.5 settings depending on other UI elements in the game as well as whats in ReplicatedStorage for some reason.


Edit 2:

I just now noticed that the CoreScripts that manage Facial Animation do seem to be eating up quite the bit of Client performance, which I also took note of when investigating my server freezing / client FPS drops. It also happens to be tied to a CharacterAdded event, which can most definitely cause performance problems on LoadCharacter just as others have mentioned, seeing as the fact LoadCharacter is designed to interact with said events.

Perhaps this is an engine issue afterall, that’s only recently coming to light. I believe this problem has been occuring as early as September 2023, which is when this issue first came up for me.

How does that ever affect it? Content in ReplicatedStorage are completely static unless you add a viewmodel of the character everytime they spawn which will of course will also use some performance.
This also goes for destroying any character references when they respawn.

Having this exact same issue currently, even with ~20 players

Well, I’m not doing any sort of view model storage in the ReplicatedStorage, so it couldn’t be that.

Just, for some reason, removing basically everything from ReplicatedStorage during my testing to figure out my own issue, resulted in about a ~400ms improvement. This is with zero scripts running btw, other than the locals found RunContext ones. A roblox staff member, I believe tnavarts mentioned to store them there, so I did.

Deleting the one ScreenGui for some reason resolved the spike entirely, but I kind of need it for my experience. So I do feel like the engine is still partly at fault.

This case seems like it could be a NetworkOwnership issue rather than an issue with the LoadCharacter function itself. When the player respawns after dying to the spike; they are no longer granted NetworkOwnership of the spinning blade, and as such, the part needs to jump to grant NetworkOwnership to the server / the other client instead. The predicted location of the spike on the server / each client is likely to be quite different, which could be creating these freezes and jumps. Are you sure this isn’t the issue in your case?

Guis under StarterGui have a tendancy to be heavily tied to the player character (for example, the ResetOnSpawn property exists; but more interestingly, StarterGui simply won’t copy any guis if CharacterAdded is never called). Just out of curiosity, do you know if copying the ScreenGui from a location other than StarterGui into PlayerGui via a script or otherwise resolves the spike for you?

I’m unsure exactly what you are referring to here, but if you mean Scripts with RunContext = Enum.RunContext.Client, then these scripts are probably running on the client unless you’ve manually disabled them. If so, is it possible that the instances under ReplicatedStorage aren’t ‘solving’ the performance issue but rather make it unnoticeable by removing some extra work that is being performed on character load? I’m just genuinely curious because I’ve been wondering how character loading fully works for a while myself. :sweat_smile:

1 Like

Funnily enough, all those RunContext Client scripts are not tied to Character stuff at all, and are primarily for Server → Client communication. And if there any that aren’t tied to remotes, they’re certainly not performance heavy. I checked them with Script Analysis and couldn’t see anything wrong.

Also, it appears loading the Place file with the ScreenGui in question causes Studio to take longer to load (not play testing, just entering the studio build).

The previous game has a much quicker load time which is weird, considering they are not too fastly different in terms of content in the game, and map is basically identical, if not less in the new one. (we just recently moved a lot of dev models out of the game in the new build)

It does seem that whatever that specific UI configuration is, it’s causing massive performance spikes that the server doesn’t enjoy.

1 Like

It’s a simple server side part, it’s anchored and is not part of the physics engine, I doubt that would be the reason because otherwise you expect me to :SetNetworkOwner() to every single part that spawns in the game?

For anyone facing the issue of your client/experience freezing when loading the character you may benefit from disabling microphone access and camera access on your experience if it’s not mandatory until ROBLOX gets it’s act together with this issue.

It’s gotten so god damn bad that loading animations during that time crashes the whole studio all together…

1 Like