I have a very detailed lobby with probably 2000+ parts and a morph GUI with over 200 characters. Many of my players complain that it takes them a really long time to load into the world, and sometimes they can’t load at all. I’ve tried recreating a lot of the lobby with less parts and utilizing unions/meshes, but the complaints still came… it’s a nice build and I’d hate to just scrap it for a smaller one. I know that there are ways to load the character after certain items are loaded but I don’t really know how to use this to my advantage as I’m sort of new to lua. Any suggestions much appreciated.
8 Likes
You can enable Workspace.StreamingEnabled to enable network streaming for faster join times and less of a strain on processing power. The game will load as the player plays.
There are several other factors that may be causing performance and loading issues. You learn more about how to detect and work around these factors through the optimisation category of the Roblox Developer Hub.
17 Likes
I’d load the characters on demand rather than when a player joins.
2 Likes
@Dandystan
StreamingEnabled, at times, can be fairly faulty or unpredictable. Even as far as unusable. In other cases, it may not work well for your use cases.
Some of these threads are a little old, but I believe they’re still fairly relevant.
https://devforum.roblox.com/t/is-collectionservice-gettagged-guaranteed-at-start-of-runtime/204891/3
I can almost guarantee that your build is not the issue here in regards to loading time. ~2000 parts is nothing for a lobby, especially if you’re using regular parts (wherein the only thing that needs to load is the texture). There may be another underlying issue that you’re not seeing. Try looking around your game a little more and seeing how you can optimise it better.
3 Likes
Quick question, probably the answer will be no, but have you used any free models in your game at all?
Some free models contain viruses which replicate themselves thousands of times, and each copy does the same thing too, creating a very large amount of objects to replicate to the client.
So, do you have any free models? If so, check to see if they have any weird scripts with obfuscated names, or any called Vaccine as these are quite common.
But, judging by the fact that you built a lobby from scratch, you probably don’t really have a need for free models 
2 Likes
I dont have many parts but I have a lot of textures on them because they are cubes. (https://www.roblox.com/games/2824244788/) I thought this was the issue, so I converted them to meshes and added only one texture rather than 5.
This is not the issue though because it still takes forever to load.
Also, I thought making a loading GUI would at least make the load time tolerable, but the GUI loads in after the skybox and sort of makes it useless.
An overabundance of textures can cause slow loading times, so can other factors. When you say that load times are slow, I’ll need an explicit definition of that. Is the game slow, or does your loading Gui take forever, or?
That aside, to address a Loading Gui, you should only have it for as long as it’s reasonably necessary. I would avoid using RequestQueueSize for a Loading Gui primarily because it’s a dynamic count that isn’t representative of how many assets the game has to download, rather how many assets are on the download queue (queue != downloaded). Long load times or a loading Gui that stays on for long with no indication of progress is bad UX design.
1 Like
It takes a very long time for the player character to load into the world. GUIs also will not load during this time, but the skybox does, so all you see is the skybox and coreGUIs (no lobby). I tried to put a loading screen over it, but the loading screen loads with the character, so it doesn’t show up. I think it takes so long that people think it’s not loading and opt to quit.
Once the lobby loads, things seem to run smoothly.
For the loading screen, are you using Replicated First other than player gui?
Player GUI will replicate with the player, but replicated first will be, well… replicated first. This makes it ideal for loading guis.
You put a localscript into replicated first which calls StarterGui:ReplaceDefaultLoadingScreen(). If you want more info on this, have a look here https://developer.roblox.com/articles/Custom-Loading-Screens. This might just allow you to have a better loading screen.
2 Likes
Whether the Gui exists in StarterGui or ReplicatedFirst won’t solve the fundamental issue, which is what I’m trying to pick at.
ReplicatedFirst only changes what’s replicated to the client first (client assets only) after they connect, while StarterGui contents are replicated only after the character is added. Changing the order in which the Gui is replicated in doesn’t address base issues, such as:
- Acknowledging when the use of a loading screen is appropriate
- Understanding the caveats of a loading screen
- UX design, where the loading screen only acts as a small buffer
- Why the game is supposedly taking long to replicate
It wouldn’t really make the loading screen better. Perhaps in the area of timing, it would, but overall nothing much would change.
1 Like
I guess that is correct. I was just trying to give a way for the loading screen to come on and give a better user experience. But now I think about it, it shouldn’t make much of a difference so I guess you’re right.
1 Like
The loading screen works great after using ReplicatedFirst and I feel silly for that mistake. Still leaves me wondering why it takes so long, but this is a good fix for now.
After using F9 in the game, the memory is pretty high in Instances: 160MB. I loaded in other games as a test and it was 7MB in Bubble Gum Simulator and 8MB in Jailbreak.
When I first load in the game the Instances memory starts at 7MB but slowly increases up to 160MB then I spawn in.
How many decals / textures / meshes do you have? I’m betting that’s the problem. Another thing to consider is if you need all of these assets to be loaded in.
Why don’t you have a system of time-based loading? What I mean by this is that the assets for your game are placed in server storage. Then, when they are needed, you can clone them into the workspace. This means that you can control when and how they replicate and load.
This would work similar to how map loading works. The maps are too large to load and replicate at server start so they are cloned at the start of a round.
Could you use a system like this?
1 Like
This doesn’t make any sense as other users joining at a later time will have to deal with the ‘long loading time’
@op, this sounds more like a building support question.
1 Like
I don’t understand. How will an instanced based loading system make some users experience longer loading times?
What I mean in my idea is that, say you have a how to play area. You could keep that in server storage until a player actually enters the how to play area. There is no point loading it at server startup. Granted, it wouldn’t make much of a difference, but it could make some.
2 Likes
try using the contentProvider service. this has a preloadAsync and can load the whole game using a for loop with just using game:GetChildren() you can improve the wait time using wait(t) in the loop
Preloading everything is equivalent to preloading nothing. Preloading simply prioritises the loading of certain content; it does not increase loading speed.
3 Likes
I mean. you’re not wrong there. according to his problem of certain content not loading (or loading in slowly) does indicate that the time between the loading screen and actually getting set into the game is short (probably due to items being in ReplicatedFirst) making a loading screen to gain some time or keeping the ReplicatedFirst clear should probably fix the issue? loading isn’t related to roblox at this point. its more of a Graphics card thing. no matter how big the game is (or how many instances there are) i got no problems with loading a place. the reason i prefer the preloadAsync is that it keeps yielding until the given parts (and its children) are loaded. so creating a custom loading screen might help