Server | Client delay leads to 5-7 useless Remote Calls

even for the coin animation, or just the check?

for check only, coin animation should be separate VFX module that you call when you spawn coin, this way you can separate your code and make it more cleaner

If you wanted to be efficient you could set up the coins with a big hit box. When they upgrade their magnet then you can increase the hitbox radius on the x and z axis.

Personally I would prefer to use this method since otherwise your doing a math calculation for every single coin in the game on each heartbeat (or 1/10 of a second if you switch to that). This means the more coins you add the more performance intensive the game becomes and you will likely be very limited on the amount of coins that you can add.

Let me know if you want more detail on how you could get this to work.

nice idea! ^^
But at the end im still not sure if its gonna still work.
Coins are client rendered, so its gonna be the same issue like the magnitude probably

math is less costly, creating new part and updating it is costly, math also can be reduced by using spatial hashing or grids, or maybe even quadtrees which are great for those kind of stuff

You will have a different magnitude due to the time it takes for a Clients character to replicate to the server. To handle anyone hacking I would record on the server the position of the last coin they collected along with the time they collected it using os.time.
Then when they collect another coin you can get the magnitude difference and the current os.time. Using this you can detect whether the player has travelled massive distances and promptly ban them.

There wouldn’t be any way around this unless they just go for the coins close to them except it wouldn’t give them an advantage since they could have done that anyways with the magnet.

Ok strange idea, but you can use grid 100% server and send remote to client to collect coins, with of course correction factor, you can use grids to optimize distance checks from like 200 to maybe 10 or 15 at the same time

Yes initially creating the part would be more costly. The part only has to be created once and it’s set up until the player touches it without any additional performance being used. This means it won’t affect any new parts being created whereas checking every parts magnitude every 1/10th of a second would. For every new part added in the looping option the loop gets more performance intensive resulting in a limitation of the amount of coins and unnecessary strain on the client.

Wouldnt i need to create the touch events on server then?
And wouldnt it be performance costly?

Like lets say each player is able to spawn around 30-35 coins, and we had 7 players in a server which is going to be about ~ 228 events for the server to handle, isnt that too much?

Sorry but you overcomplicate stuff, you don’t need to check 1/10th of a second every coin/part in the map, he can create spatial hash and perform only few magnitude checks, also having giant part over each coin is costly because it have to be replicated, it does nothing with instance.new, OP want to reduce network stress, by adding more replication you increase it

quick question with the grid method, what is really that different to it when just using magnitude? The player might be able to collect the coins from further distance in late game probably, thats why im using magnitude

With grid you can check only few tiles around you, overall it’s more complex idea but you divide your game into grid and check each index grid tile near player only

okay yeah thats stuff im slowly not able to make cause im bad at math :sweat_smile: But its mostly because im still young and not able to do everything. So when i understood you right, you mean smth like a chess board here, lets say like im able to split the coins into grids like A1, B7 etc. Wouldnt i need to always change the grids size dependent to the current player’s magnet’s collect magnitude when the player equips a new magnet?