Are you sure you can’t make it a union? Try again, if it does work. You should export it as a 3D model and then import it back to studio. It will become a mesh and hopefully from my knowledge, reduce a LOT of lag.
Hi. How would I be able to tell the physics? I have CanCollide off on the parts. Does that still involve physics? (Sorry, I don’t exactly have the best knowledge with the things listed in your reply.)
Making it a union freezes the studio, and then I get an error popup message, basically saying the task was not completable in a sense.
hey, turning CanCollide off doesn’t completely eliminate the part from Roblox’s physics calculations. The part’s Anchored property and other properties also factor into the physics engine’s calculations. If your parts are both unanchored and have CanCollide set to false, they are still part of the physics simulation because they could potentially be moved by scripts or by colliding with other unanchored parts. If performance is a concern, consider setting your parts to be anchored if they don’t need to move.
- Don’t use run service for that
- Use while loop, it’s more controllable, soo set wait value to idk. 1/12 or 1/20, and then we optimized this a bit, then we can optimize our building via building tricks, like deleting unnesecery textures or don’t visible parts, after that, we optimizing meshes.
- Make Can Collide False parts unions, and then set collision to hull, this will optimize calculations a little
- Don’t use many textures, don’t make normal scripts inside, use optimized code for move.
- You can use physics, but i don’t reccomending that
- Try to make meshes low poly
- Try to delete inside parts that aren’t visible
So, let’s say I have a vehicle controlled by the server (say, an automatic train/people mover). If I insert this script and make Model be the vehicle, it will make the vehicle only render at 30fps but it’ll still be moving physically as it would otherwise?
Also, you have “Goal.Magnitude” without defining what Goal is. What should it be?
Roblox offers a BulkMoveTo function that might help. It’s optimized for moving a large amount of base parts at once.
Clarity is key here, a good mantra for obtaining a viable solution is information, there simply cannot be too much of it! Your post asks about moving a 1000+ parts yet your script executes inside a model. Is the model erroneously considered a part and there are a 1000 of them or does the model itself contain a 1000 parts? Is this script concurrently executing 1000 times in a 1000 individual parts (if so, then say no more).
There shouldn’t be any noticable lag moving a 1000 parts around, especially if they are basic parts with minimal vertices and collision logic.
BulkMoveTo seems like the answer here