In my game called plane crazy, i want to optimize the spawning in system, but i have no idea if this even is possible.
Is there a way to slowly parent a massive creation with over 5000 children which is already welded together without the server freezing?
You can try firing all clients instead, each client will have to deal to load it to them. Then after this you can parent it to the server. This might lower the lag.
Try unioning a lot of the parts. They seem like the same material
add coooldown based on model children counts. for example if model have 500 parts cooldown should be
0.05 - 0.1 seconds. or load them by groups by running spawn(fucntion()). or try spawn them so fast so server wouldnt lag so long.
The full model gets cloned to workspace, not the children inside of it because the parts inside of the model are welded to eachother.
Unions makes it way more laggy than it is.
Parent it in batches; such as parenting 100 parts at a time then waiting a second, use greedy meshing if possible to reduce the part count (i know some players might not want this, so maybe a setting the player can toggle?), or parent the minimum amount of things you can parent and have the clients create the rest of the instances, like the client creates welds, motors, etc based on tags or names or what the parts are parented to.
@fastkingyaya, runtime unions created on the server are slow and clunky, would not recommend
But would this be possible if there were welds inside of the model?
yes, however it would require some case by case parsing, such as having a part named weldoutside being welded to a part outside the model.
Welding on the client that spawned the model might be the better way to handle models and welds, simply because that would reduce the instance count that needs to be replicated and reduces memory usage on other clients and the server, since they don’t need to have the welds replicated to them. Just use whatever code you use on the server to weld the model on the client that spawned the ship, unanchor the parts on the server once the client has finished that so that the client can move it, and set the network ownership to that client.
I dont know what is the outside or what the inside is, people can create their own creations by placing blocks and all sorts of other items.
You could try “disabling” physics/collisions and change the transparency to 1 for all the parts that are spawned in then, you can iterate through all the parts and “enable” physics/collisions and change the transparency back to 0; this should decrease the amount resources used by a little bit.
Another solution would be to insert an anchored model then create the welds after it’s been spawned in, you could also create a new model and move/clone parts from the original model to the new model; you could yield a few times to prevent the server from freezing.
In my opinion, you should create a new model, clone each part from the original model; change its properties so physics/collisions are “disabled”, change its transparency so it’s 1, store each (cloned part)/weld into a table(e.g. Table[Weld] = {Parts}), then finally, you can iterate through the table and, if a part doesn’t exist, move it to the new model, then, you can create the weld and repeat until the model is complete. (Don’t unanchor the parts until the whole model has been loaded in).
In this case I would recommend you to do the following things:
Before loading:
During Loading:
After Loading:
and you may also try to make client do it, and send the results back to server, or just try to make all clients load them
I tried to solve this problem with high-part models in a game that I work on and I found it to be pretty much impossible to avoid the kind of lag associated with it because there is no way to “tell” a character loader or anything that clones to take its time.
My end solution was to essentially build the model slowly on the server. With Plane Crazy, you should be able to set up a data structure for your welds and their subsequent connections (Probably a linked list or something similar) that builds and welds a complex structure together over time while avoiding welding problems.
My solution to this was a bit more lazy: I just made a recursive welding system that started with a primary part and took all the welds that welded to that part and attached them. Then the loop would recursively check again for all the new parts added, and so on until no parts were unwelded. This solves the problem for myself but is not optimized enough to handle the kind of loads you probably need to.
I figured out a way to do this efficiently.
This worked out perfectly and all of the welds are unaffected.