I was thinking of making a tycoon kit strictly for learning purposes, and was searching for the most performance-efficient method of handling the dropper physics. Many threads have suggested spawning dropper parts on the client, and that is definitely the route I would like to take. However, I am having trouble brainstorming a way to create a sanity check on the server to verify that the client is spawning the right amount of drops per increment of time.
If anyone could pitch any ideas my way, that’d be great! I’m not asking for code, just ideas on how one would approach this problem. Thank you!
You wouldn’t need sanity checks for dropping as that should be done on server.
You’ll have some sort of loop on the server where you check if any drops should be spawned and if so, you tell all clients to spawn a part from that dropper. So all the timing is handled on server and when it’s time you just notify clients to spawn a drop
I’ve noticed a lot of tycoon games lag due to a high amount of physics simulation due to the droppers being handled on the server, which is why I’d like to attempt spawning them on the client.
Perhaps you’re right, and I could create a timer on the server to notify clients on drop. However, most tycoons add to a player’s currency after a drop has touched a part at the end of the conveyor. Obviously, I wouldn’t want the touch event to pass from the client to the server because that’s just leaving room open for exploitation. I could have currency added as soon as the dropper drops, although that wouldn’t be ideal since tycoons are accustomed to adding currency at the end of the conveyor.
Would there be any solution as to how to correctly time the droppers and currency additions?
that’s where the sanity check would come in. I believe you know the velocity of the conveyor so you could calculate the distance from dropper to that end part and then using s = vt you could approximate the time it’d take for the drop to reach that point. t = s/v so timeToReach = distance / conveyorVelocity.
the accuracy will depend on how you calculate the distance. just using magnitude would give you the shortest path which wouldn’t be exactly accurate but could still work.
now to make sure that they don’t receive money twice from a single drop you should assign each drop some sort of unique ID and store it in some table on server. you’d also send that ID to the client so when it touches the end, client will notify server that the drop with that ID has reached the end. server would then just remove that ID from the table of spawned drops so even if the client tries to get the money again they wouldn’t be able to.
Make sure that you also tell all clients to destroy the drop after you give client the money so drops won’t stack up for other clients.
Spawn dropper parts on the server, pass them into a verification array under a key in a dictionary using the player object (so it nullifies itself if they leave), SetNetworkOwner on specific player.
Apply Touched listener on the server to the collection part (Touched will replicate regardless of NetworkOwner).
When Touched becomes active verify that the part should exist from inside of the active parts array for any specific player.
the player object will never become nil, even after they leave the game. so you need to make sure you’re cleaning it up yourself in PlayerRemoving event to avoid a memory leak.
P.S. approximating drop reach time for sanity checks would still be a good idea as they can fire the touched event as soon as they receive the network ownership of the drop.
Yeah you’re right, I just tested it. For some reason my brain assumed that this would all be cleared internally when that memory has no reason to be reserved anymore.
I think NetworkOwnership alongside a verification table is better than giving objects unique IDs (because they already have unique IDs as a Lua object that isn’t copy-type). This system could exist under two dictionaries: {[Player Object] = {[Part] = time estimate}, [Part2] = time estimate}} - where touched acts as the catalyst to cleanse the table of a part regardless, but money is determined by how accurate the time estimate is.
I also had to test it when I heard that first time because I couldn’t believe it haha
and sure network ownership way seems fine. this is pretty clean too
I just rarely ever use network ownership as it allows clients to move the part anywhere, place it in other players' stuff, and possibly even fling the player(?) if they use a lot of drops together.
majority of exploiters don’t know or won’t realize that but still, I like to play it safe.
Setting network ownership from the server is definitely a risk for clients to control the droppers. But anyways, like you said, majority of exploiter won’t realize that they’d be able to, and I don’t believe it would influence the game too significantly even if they did move it. Sure they could move it practically anywhere in the workspace and it would replicate, though, I could have some sort of check on the server to ensure it stays within their tycoon area, as well as create collision groups so that no players are physically affected by its movements!
Thank you for all your help @SummerEquinox@TopBagon , it was extremely helpful! Although setting dropper parts to spawn on the client seems much more adequate for performance, SetNetworkOwner seems to be much more convenient and less risky for major exploitation, so I think I will use that method
