My game’s next update has hit the 32 bit memory limit of studio, so to continue work on it we had to temporarily move some stuff to a different place. If 64 bit studio is released before the update is ready we could just put it back, but I am looking for alternatives if that is not the case.
I’m looking for the best way to add back in a large amount of parts/models after the game server starts (meaning they are not stored anywhere on the place in studio.)
I’ve tried uploading a large chunk as a model and then loading it in after using InsertService:LoadAsset which does work, but causes the server to hang for a while when it is inserted. If I do this right at run time the models already seem to be loaded after my character loads in.
Using LoadAsset at run time on the server is my current plan if 64 bit does not arrive in time, but I am wondering if it could cause issues? Is there a chance the model would fail to load? It seems to cause about 5-10 seconds of hang time when ran with my character in the game so I’m worried it might cause ill-effects or mess with something if I do it right when the server starts - though I have not yet seen any effects.
Any information about the issues this could cause, or better ways to achieve the same thing would be helpful.
Unlikely for this to happen, as it is a pretty large project from what I understand.
If it does, LoadAsset will error, so you can wrap this in a pcall to determine if it was successful or if you need to retry.
Sounds like the server doesn’t care about performance and dumps all resources into downloading the asset and loading it into memory. You could fix this by splitting up the model into smaller components, which should prevent the freeze-up – the server will be able to complete other tasks between inserting each model.
Splitting a large chunk up into smaller models will probably be tedious, so another option is to simplify the chunks you’re uploading. Based on the size of the chunk, it sounds like you’re storing a lot of duplicates. Instead of storing all 5000 trees in a single chunk, store the 2 or 3 prefabs you’re using and then represent each tree with a CFrame. You don’t even need to use InsertService at this point – you can just store the prefabs in ReplicatedStorage.
I considered doing something like this too, but isn’t this what instancing does? Or is instancing not in studio? If not what would be the best way to store the CFrames in terms of least memory - text in a script, CFrame values, or something else?
Instancing only applies to rendering (in this case, graphics memory) – not main memory. As for storing them, the effects will probably be negligible – store it in whatever is the easiest way for you.
For my game, I create attachments under Terrain (because they have to be parented to a BasePart), since Studio has tools to allow me to create/manipulate them with ease. The attachments are named based on the prefab that they should spawn, are tagged with “Asset”, and a script in ServerScript loops through every object tagged Asset and spawns prefabs at them.
You could also make that a little easier by creating your own custom chunk system that shows transparent clones of the prefabs when you’re nearby, allowing you to get a better idea of how your world is laid out than if you were looking at green dots everywhere.