Incident was resolved.
Incident was resolved.
3 Likes
You can use the performance window to see what your performance reads. Edit: the performance window will be helpful in finding lag spikes. Ultimately, look at all the running scripts in studio to see what scripts are killing the frame rate. More particularily, Anything with a high percentage should be looked at.
3 Likes
Depends. If the game has a lot of parts, then, yes, there can be longer loading times. Theoretically, large part counts can also crash servers (servers have limited memory, and sometimes your code can have memory leaks which cause major lag as well).
To stop memory leaks, clean up some connections or add stuff into the debris so it’s cleared from servers.
2 Likes
How do I clean the connections?
1 Like
:Disconnect() is the function you use.
3 Likes
The Trees is a big source of the join lag but its the part count if you delete all your tree keep one and union the top leaves to be one it will help a lot also dont put so many trees
Also i have a really good PC and i was getting about 20 to 30 FPS
2 Likes
From my experience, RunService connections that aren’t properly handled (no disconnects) cause a performance issues. Welding parts when you need a tool instead of welding the tool manually in studio (especially when you have a bunch of parts) will lag. Model:SetPrimaryPartCFrame() will cause performance drops when used excessively. Games with a bunch of moving parts or games that have too many parts will cause lag. The list goes on and on. There’s no such thing as a lag remover.
3 Likes
If you’d like to decrease lag from parts,
-
Make sure all parts are anchored (unless they need to be unanchored)
-
Make parts the player is unable to reach CanCollide false
-
Turn CastShadow off at parts that simply do not need it.
You can do the following to decrease lag from MeshParts & Unions
- CollisionFidelity Box (if possible)
Keep in mind CollisionFidelity Box will cause collisions to behave like a box, It’s best to use this setting on things that already have a more cube-like shape/hitbox to begin with.
Please do tell me if what I’m saying is wrong.
Have a nice day!
2 Likes
Disconnecting an event saves game resources and potential memory leaks.
You use :Disconnect()
on any event once you’re sure you won’t be forging many more connections associated with that event, like in UI for example , once you listen for the .MouseButton1Click event you know that it’s going to happen often , no need to disconnect that. But other events , which are not going to be used very often for example when a player touches a part he’s supposed to get currency, and if he has that amount already then we won’t continue listening for the .Touched Event for ever, rather we will Disconnect the function from it , to stop wasting game resources
As it also says on the Developer Hub :
Always call Disconnect() when a connection is no longer needed. Forgetting to do so can cause your game to use more resources than necessary. Note, however, that this may not always be necessary; when an object is destroyed, all connections to that object’s events are disconnected automatically.
1 Like
Lag might happen due to lots of small parts, so try reducing them.
1 Like
True, that’s a really good tip you gave there.
You have 85k parts and 4k moving parts… Even when I turned the “Hide Trees” feature off you still have 85k parts. This doesn’t even count the polygons that meshes, meshparts, and unions count as, and those are laggier than normal bricks. You could probably save 50 parts just from cutting the down the brickcount on a single hedge model.
1 Like