PreloadAsync isn’t meant to be used to load your entire game, it is only meant to prioritise the download of assets that you need visible as soon as possible. It also won’t solve the issue of loading, since it seems that the map itself is taking long to replicate over assets not downloading. The two are very distinct issues and it seems that OP is experiencing the former.
Long loading screens are bad for UX and won’t solve the issue. Players will wait all the same and/or leave the game. A lot of games’ audiences are young and lack patience - even then, no one would want to stare at a loading screen for an abysmal amount of time.
What?
No it doesn’t. It yields until an instance and its descendants have downloaded any AssetId tied to the instance. PreloadAsync is specifically for assets requiring download.
I think OP’s experiencing more of an issue with replication than preloading, as per the root issue. I tried joining their game and confirmed that I was stuck staring at a skybox for a while before anything actually loaded. In this circumstance, preloading would have no effect, because the server is still trying to replicate the game to my client.
Once I’ve loaded in, there’s no longer an issue to be observed. The game runs smoothly, even on 10 graphics and I can walk around. That means that there’s something else obstructing or delaying the replication queue by a large amount.
Well, if multiple different users have the same issue, it pretty much definitively rules out network issues.
Also, though, I noticed that you were the first player in the server. Could the server still be loading the map in, then going through the replication process. Maybe try with multiple players, one who is loaded in to see?
The player list doesn’t implicitly display all players. Players are still instances that need to be replicated.
Replication is localised, not globalised. Adding more players to a test wouldn’t change the results. They will still go through the same replication process that I do. The server has implicit access to the map and will always have it readily available. The server needs to replicate the map to the client so the client can render and display it. This is also why usage of WaitForChild is encouraged on the client for Workspace interaction but not necessarily for the server (unless you’re unsure if a modifiable instance will change at run time).
This is the server replicating the Workspace to the client, not the server loading in the map. The client can’t see the server’s copy of the map, but changes that the server makes to its copy of the map are replicated to the client.
I’m not quite sure what you mean by this. The Workspace is available to servers when I initiate servers in Studio mode. The server already has access to the geometry data. The Workspace is included in the DataModel snapshot that’s replicated to the client. There’s a reason why WaitForChild isn’t explicitly necessary on the server aside from objects that have potential to not exist.
Doesn’t work like that. Whether I start the server or not doesn’t have any bearing on this action. The reason I’m stuck in the sky is because the server is still trying to replicate the DataModel snapshot to my client, which said replication is taking longer than expected.
I just mean, when I open a testing server the server does take some time itself to load in the game.
When the game opens, not everything loads imidiately for the server. It still has to load them.
Also, in the rare cases that the client replicator loads before the server has finished loading in assets, I do end up in the sky for a bit before I load in.
What window are you using? The server has access to the map immediately, as do the scripts. There is a reason why using dot syntax to index DataModel children in a server script doesn’t throw an error and why it’s almost enforced that you do so via a LocalScript.
Would never happen. If the server doesn’t have anything to replicate, the client wouldn’t receive anything. Client-only services aren’t an exception either, because a snapshot still needs to be queued and replicated (as shown in the above).
My debug windows beg to differ heavily. They’re still receiving data, nothing is idle at this point. Plus there is still a game to be replicated, evident by what’s shown after you actually load in.
Ok, sorry I was wrong. I thought that some content could still be downloading server side and that could slow down replication.
But after a deeper look at some information about replication, it turns out that the server doesn’t actually download content at all, it just stores the asset ID and leaves the rest to the client.
Right. The server isn’t the one that displays the map - it already has access to the geometry data in a snapshot when the server loads in. The actual map that you see when you play a game is the client’s copy of the map that’s replicated from the DataModel snapshot that the server sends.
I wasn’t experiencing any lag, but it seems that I was receiving large amounts of data that weren’t being processed. You can see the massive difference between the incoming kilobytes and packets before replication and after. I’m not too sure ping is a relevant statistic.
Hey I saw this and I instantly stated a question that I profind very important to know.
When you upload textures, the textures usually end up in the Asset Manager:
I ended up asking myself:
Does this cause slower loading times?
If you re-use the texture multiple times, would that slow the loading time?
Textures that are far away, do those load?
I’d be happy for a reply, even though this is 3 years late
The asset manager is purely for Studio development so it has no bearing on the performance of your experience in a live session. As for reusing the texture, the texture itself only needs to be stored in memory once so you might instead see rises, possibly trivial, in graphics rendering if the texture is applied to multiple places.
I don’t have any information about rendering on far textures since I don’t typically pay attention to that part when developing. I’ve been doing more code work than physical appearances for a while so haven’t had the chance to observe that behaviour yet.
I see, thanks a lot for your reply
It helps me understand a little more about performance, hopefully others too even though this topic can be considered old
