why do you have 150k crops loaded in at once? it makes no sense for the server to handle all those parts while the player is not even looking at them. also, i know that this is not related to the server but have you checked if you’ve enabled content streaming?
you could maybe use a chunk-loading system or a system that procedurally generates nearby terrain like minecraft
however, you can also check and monitor the script performance via the ScriptProfiler tab in the console. it could help you figure out which scripts are causing the most memory usage :3
Also, render crops client-sided, and on the server it’s just a table of their position or a grey singular part that you’ll use for sanity checks and such.
If this is in studio, don’t worry about the replication solver. Else, make sure you don’t have a run service being called inside of another runservice in a module or something. That can be very bad.
I believe it should, although i have never tried myself, i have used a Quadtree before, and since an octree is a 3D version of a quadtree, it should help in various aspects in your game
Hi! Just begun work for today so sorry for the slow response
I do have streaming enabled, and I have thought about a chunk system instead, but I’m not sure how that would help memory wise.
Usually only 50k crops are loaded and interacted with on the client, the rest still exist ingame for the server though.
I’ll go look into script performance in a sec, and reply with my findings!
If the server has a table of crops, and they are only rendered on the client, wouldn’t that be bad to transfer data between the two?
There are lots of players in each field, so I would have to constantly update and send large tables to the client, doesn’t seem like a good solution to me, or maybe I’m wrong!!
I doubt the crops are the problem though, they do take up a lot of instance and collision memory, but that’s about it to my knowledge.
It is high, but its the best solution I could come up with…
I’m sending the players tool position to the server every renderstep (just reduced it to a max of 45 times a second for better performance), then the server checks if any crops are in the tools hitbox, and then collects them. I can’t just use what the server thinks the position is because it lags behind loads and doesn’t collect all crops that were in the hitbox… if that makes sense
Is there something better I could do? It is just one remote handling each collection.
with tool position do you mean the mouse’s hit? (the 3d position in the world) if so, you should just do this calculation on the client everytime UserInputService.InputChanged fires, since any exploiter is and will be able to falsify this position
Uhhh, the tools position is replicated automatically to the server by Roblox, no? Can you not use that instead?
By sending the tools position to the server, the remote will get there just as fast as roblox can replicate that tools position to the server. So there’s basically no point, there’d be no desync in that. Basically think of Roblox replication as firing remote events to the server.
Also, if you NEED to send the position on the remote, (i.e, the tool doesn’t exist physically, it’s a clientsided GUI) do it every 1/10th of a second, or maybe even slower. 1/40th is fast!
Do you really have to send the entire table? Send the crops that need to be changed.
Either way, the table should stop existing when the function ends. I hope.
There’s a very useful video on Octrees, which are basically just chunks. Octrees used by big RTS games with hundreds or thousands of AI units, which are certainly intensive to run. Minecraft somewhat uses octrees with chunks.
hia so i have made some progress
using luauheap i found 1 major cause of the leak (around 500mb of 3gb) and removed it
but… now im left with nothing.
luau heap doesnt report much, and memory still grows around 1mb a second
what else can i do from here?
i wont be able to work saturday - monday due to school, but i will try to reply and answer questions!
UnreliableRemoteEvents might be able to help, since you don’t absolutely need every single crop picked up to go through…
might not help with the memory leak but is a suggestion