I’ve ran tests, and this “Data_Insertion” object is successfully added to the player in about ~3 seconds every time the server starts. I’ve narrowed down the issue to this object not replicating TO THE CLIENT until about ~30 seconds after the server starts.
Here’s what the player looks like on the server:
Here’s what the player looks like on the client:
In summary, objects created on the server aren’t replicating to the client quickly on server startup, which is increasing my game’s loading times anywhere from 20-30 seconds.
How many instances do you have in services that replicate to the client? I’d pay special attention to ReplicatedStorage as well as any instance that accepts a ContentId though it’s worth overviewing your entire static environment.
For instances in services that replicate to the client, nothing too egregious I don’t think.
To test your theory I pasted everything from the game to a different place. The only difference is that in this new place, the scripts are completely broken and basically don’t work at all.
I put the following code in a script in the workspace of both places:
game.Players.PlayerAdded:Connect(function(plr)
local E = Instance.new("BoolValue", plr)
E.Name = "TESTREPLICATE"
end)
In the new place, this new instance replicated to the client almost immediately. In the old place, it took a long time.
There also doesn’t seem to be a significant difference in replication time between our test place(which is just a few baseplates and some assets pasted around) and our huge map, despite the big differences in the static environments.
Just to clarify: you created a new baseplate without your map’s assets and copied the resources over and the replication issue still persists? You mentioned that in one case a new instance replicated to the client immediately but in another there didn’t seem to be a difference in replication time.
To be clear, what it looks like may not be what it actually represents. If there’s a discrepancy in replication time between a baseplate and a full map, the map itself may be incredibly large and full of assets that do also need to be replicated in the initial snapshot. If there’s no change between a fresh environment and the place where there’s an issue, you will need to look through your services for the volume of assets. It’s important and can’t be brushed off as “nothing too egregious”.
Make sure to also make use of the MicroProfiler on the server-side.
Sorry for the lack of clarification, I’m terrible at explaining things.
In the “different place” that I pasted everything into, I pasted everything from the test place, not the full map. This includes all of the assets and the scripts. The only difference between the test place and “different place” is that the scripts are basically all broken and nonfunctional in the “different place.” In the “different place,” the replication issue does not persist, and it’s not just a baseplate.
In short, it should be your map. If you’re experiencing replication issues only when the map exists and not the assets, then that’s where your problem lies. You will have to look into strategies that can help reduce the expenses of the map. The MicroProfiler will help point these problems out.
The most immediate expenses you will encounter on high-cost maps is lighting and that cost increases based on which technology you’re using. If you have any physics-based systems, collisions should also be a large concern. Quick solutions for both respectively are managing CastShadows and CanCollide/CanTouch properties; full solutions require a deeper dive.
To clarify more(sorry I really am terrible at explaining things), both the map and the test place pictured in this above reply experience a similar delay in replication. This struck me as weird because the test place map is very simplistic.
The only place that experiences no delay in replication is the “different place.”
I think it would be best if you gather your thoughts and take your time to clearly explain the different environments/places you have up, how populated they are with assets and what the replication state of each of them is. I’m getting lost and don’t quite understand your existing situation right now.
Alright, here’s a better description of what I’ve found.
I’ve tested the replication issue in 3 different places:
1. Test Server 1 - the place where the game is actually worked on. This place contains all of the game’s assets and scripts, but no map.
2. Map - the live server. Has the game’s assets, scripts, and a really big map.
3. Test Server 2 - an exact clone of Test Server 1. The only difference been Test Server 2 and Test Server 1 is all of the scripts in Test Server 2 are broken and nonfunctional.
The replication issue is only present in Test Server 1 and Map. Replication in Test Server 2 starts very quickly.
I’ve already changed the default DataStoreService’s “DataStoreTimeout” from 5 seconds to 30 seconds, and I’ve changed “DataStoreRetryTime” from 0.5 seconds to 30 seconds.
Also, I’m using DataStore2.
I had a similar issue with a datastore that was not replicating quickly on server start. I solved this by making the datastore a global variable (script in ServerScriptService) and then using the datastore2 API to ensure that the datastore was connected before anything tried to get data from it. This was accomplished using the following code: – datastore API
local DataStore2 = require(game:GetService(“ServerStorage”).DatastoreAPI)
– set global datastore
local datastore = DataStore2(“DataStoreName”, player:WaitForChild(“DataStoreName”))
– Wait until datastore is ready to use
repeat
wait()
until datastore:GetCurrentPlayerId() ~= nil
