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.
As I mentioned numerous times before, no scripts have been enabled in recent testing, so it’s not script related. I’ve updated the original reply to reflect this.
I found the exact source or at least sources of the problem, and it appears to just be this one individual frame element with it’s descendants.
I’ve decided to completely remove said element from the game, and recreate it while keeping a close eye on performance. Thanks everyone for the thoughts, but this does indeed resolve the initial problem.
(I’d like to note, all scripts in this UI element are disabled, and this UI went basically unused, and switched off, being made non-visible)
That shouldn’t affect the server though? Unless it’s rendered automatically on StarterGui.
Guis rendered on clients usually only affect gpu and cpu.
My Main Menu ui (that I enable when player joins and not have it automatically on) barely does anything to performance.
Could be the scripts, some ui elements can be very expensive, like updating UiGradients.
I have absolutely no clue how it resolved it, but the server no longer spikes anymore, so it must have been just this one descendant. Nothing else seems to be causing it. Like I said, it’s very possible there is an underlying issue with the engine, and Instance.new or :Clone() going on here, which are both off topic to this thread.
The issue is resolved so I’m satisfied 
As I’ve said many times before again, it is not scripts.
Speaking off which.
How do you handle loading character? Usually this is the only accepted method since it makes sure the character is destroyed and every connection assigned to it and children are too disconnected. (as long as theres no references.)
local Player1 : Player = game:GetService("Players").Player1
Player1.Character:Destroy()
Player1.Character = nil
Player1:LoadCharacter()
I use the Workspace property that automatically destroys previous reference to the Player/Character when they are destroyed. In this case, Character would not be memory leaking. I took this into account, and was very careful even from the start with how I wrote my code, which is why I was so confused with all of this.
I appreciate the support though.
Here is the announcement thread for the whole thing if you’re interested:
Have you read this?
Please see the announcement I attached to my other reply. I apologize for posting it a little late after sending, but that property already deals with that issue automatically, as those other workarounds were made before this property was introduced.
But in short, this is what is important:
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.