I tried disabling literally every script that pretty much makes the game, a game, and it still resulted in what I replied with above.
It seems the MicroProfiler is indeed labeling :LoadCharacter() as an issue, but I have no clue how I would fix it if disabling literally all my scripts resulted in close to nothing.
Here is the documentation on the command. It’s worth a read, shows a few cases you may have problems with it. Also shows it can be resource-intensive …
Possibly chooses your moments to use it to avoid stalling. Also you could try to defer the task …
task.defer(function()
player:LoadCharacter()
end)
This can help to cut down bottle necking. Basically lowering the task priority.
It seems deferring the task bumps up the total delay by a few extra milliseconds. I appreciate the assistance, but I already took a look at this article. I usually do to verify if anything I’m doing may be incorrect.
Hmm, I was thinking it may be this from that link …
After calling LoadCharacter for an individual player, it is not recommended to call it again for the same player until after that player’s Player.CharacterAppearanceLoaded event has fired.
CharacterAppearanceLoaded does not fire if CharacterAutoLoads is false I thought? And even if it was because of HumanoidDescriptions, those are only being used for body colors honestly. That alone shouldn’t be causing that huge of a spike.
I appreciate the help again, though.
I think you have enough to make a bug report. If you don’t have access to the group, feel free to DM me and I’ll post on your behalf, either that or you can message the @Bug-Support group and it will be approved by a review team.
Do you happen to know how long bug support requests last?
Also, would you like me to format my bug report like an actual bug report so you can just copy the contents and make it actual post?
Thanks in advance.
Also, I’d like to note that between the two experiences, my spawn script was never changed much at all. All I really did was add a few extra spaces in-between functions and condition checks.
I closely compared the two code bases, but to no avail. Also, I feel like me disabling literally all my games code should be saying something about the issue.
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%
worth a shot to disclose but here:
game.Players.PlayerAdded:Connect(function(player)
player.CharacterAdded:Connect(function(character)
--This for loop here is needed as character added fires multiple times when activating morph changes, needs to stay here to prevent mass cloning
if table.find(RespawnTable, player.Name) then
for i, v in pairs(RespawnTable) do
if v==player.Name then
table.remove(RespawnTable, i)
break
end
end
return
end
table.insert(RespawnTable, player.Name)
this is a loop I did in one of my morph systems as it would clone upwards to 6 times on .CharacterAdded without the loop
as others suggest its likely characteradded but… unless a minimal reproduction file is given, we can’t truly figure out for sure.
if doing loadcharacter on clean file does not net the same effect then its something about the game file
Depends.
If you’re referring to applications to the bug reports group for permission to post, it could be from a week to a month.
If you mean the request to post a bug report via the bug support group: Roughly a few days for a response, give or take a week.
This is definitely weird, and if everything aligns with everything you are saying, this is most likely a bug.
I unforunately cannot reproduce this bug on my end, even when simulating a place with a lot of parts, meshes, textures, etc.
Task scheduler rates are running fine, and physics simulation does not halt.
--!strict
local RunService = game:GetService("RunService")
local Players = game:GetService("Players")
local DELTA_TIME_WARNING_THRESHOLD: number = 5 / 60
RunService.Heartbeat:Connect(function(deltaTime: number): ()
if deltaTime >= DELTA_TIME_WARNING_THRESHOLD then
warn(`Server took {deltaTime} seconds to complete physics simulation`)
end
end)
local function benchmark<A...>(func: (A...) -> (), ...: A...): ()
local timeNow: number = os.clock()
func(...)
print(`Operation took {os.clock() - timeNow} seconds`)
end
Players.PlayerAdded:Connect(function(player: Player): ()
player.Chatted:Connect(function(message: string): ()
if message == "r" then
benchmark(player.LoadCharacter, player)
end
end)
end)
However, interestingly enough, there is a hidden command-line function called LoadCharacterBlocking (which cannot be ran in-game) that does the same thing as LoadCharacter but will halt the game, including rendering. It seems to be consistent with the behavior you are having with all the task rates dropping to 0.
I’m going to drop a repro file on this thread very soon so you all can possibly test it. Unfortunately, due to privacy reasons, barely any of my games code or assets will be included. However, it doesn’t appear that the scripts are the cause anyway (seeing as disabling them all does virtually nothing).
I will likely also use said minimal place file for my actual report. I appreciate all the input everyone here has given 
So I performed extra testing while putting together a local repro file, and it appears that one of my Screen GUI elements seems to be heavily impacting LoadCharacter. That stunts the server CPU usage, and also seems to be heavily impacting Client performance at the same time.
According to Roblox’s documentation, LoadCharacter resets any UI that doesn’t have the toggle ResetOnSpawn enabled.
So basically, if my UI has a lot and most of which are set to be ResetOnSpawn, it causes the LoadCharacter function to basically choke server resources. And yes, I also tried disabling scripts on said UI, and it made zero difference.
It seems whatever UI elements I happen to be using in the Start Screen that get reset (the menu you see when you first join the game), LoadCharacter does not like. As well as your client, which explains that massive FPS dip I experienced in the initial showcase video I left on my original reply.
Any theories on what this could be?
Well i was testing by disabling the ResetOnSpawn option and adding a Script that clones the necessary GUIs to the PlayerGuis [The script only does this once, when the player joins the server]
The server does not lag-spikes when the player dies and respawns, but only when the player is first joining the server
This is precisely behaviour I also observed. While this does significantly cut down on the issue, my UI requires ResetOnSpawn to function correctly.
It seems that something I added in this recent PTB caused a 1k ms spike which is absurd.
There definitely has to be some sort of issue engine sided.
It would be great to get that repro file for testing.
All the server does is clone UIs that has ResetOnSpawn enabled, it shouldn’t even be causing the entire server to freeze for 2-3 seconds at a time (that is, of course, assuming your client code are local or non-expensive).
Honestly, I did more research on this and it might have to do with one of the Roblox updates as before I was having the annoying “unexpected client behavior” error so I uninstalled Roblox and reinstalled it, while also deleting its cache. Ever since I reinstalled Roblox I have started to have issues with my Roblox client freezing. And so games are accusing me of tab glitching “in one of the plates of fate games” and so I believe that it might have to do with the Roblox client freezing by GPU/CPU. Microprofiles really can specify and show results and I so did look more into it. I have been dealing with this glitch in MANY games and it’s not a studio-only issue. So this might just be an occasional Roblox update.
Have you attempted to comment out code snippets in your CharacterAdded calls to see if the issue can be solved? It may be worth a shot if you haven’t done so already, and if the problem still persists afterwards then it may be better just to file a bug report.
You should also ensure all properties in workspace match between your test game and live game if you haven’t already.
Yes, but that is precisely the problem. LoadCharacter has to create a clone of the pre-existing content within StarterGui, building it for each Player in the server, each time they spawn in.
I also don’t think providing a repro file will be necessary anymore, as I dumbed down the problem to just a singular UI, which I obviously cannot provide given the fact it’s private content and I’d like it to not be shared.
When I tried creating a local repro file based off the main game with majority of the games content stripped and a map built from just free models to simulate a full map, it appears ~1200ms delay dropped to only ~3 upon removing the aforementioned ScreenGui. I dug a little deeper and started removing and play testing specific parts the game.
Deleting everything in ReplicatedStorage was about a ~400ms decrease. As to why it decreases, I have no clue but there certainly was no code running at all except the spawn script I used, and it seems that removing the one ScreenGui from my place file resolves the lag entirely, so it seems entirely related to some sort of layout I have.
Interestingly enough, someone on another posted stated that UpdateUIListLayouts was causing a rather big chunk of performance decrease, and I noticed they also experienced this Facial Animation taking up a bit of performance as well, which I do recall when looking through my own MicroProfiler.
I’m going to try reworking the UI to see if I can resolve the issue on my own time, but until I can figure out what exactly fixes the lag, I cannot mark this as solved.