I want to make it so that if a friendly detects someone on radar, it’ll link to other teammates regardless if they can see them or not.
I have two ideas, one of them is a bit finicky and the other may be unoptimized.
For one, every 5 or so seconds I can send a remote event from every client to the server showing radar contacts, and then the clients can read them, but I’m concerned this might be firing too many remote events with too much data each.
For two, I could have each client run radar simulations for other friendly clients along with their own. My issue with this is it may be unreliable and really laggy with high player counts
For this radar is there a range from too far where they wouldn’t be able to connect? Because if not, what you could theoretically do is create a script in the serverscript service and every time someone connects to a radar it’ll set a table to true that a player is active on the radar, and it can check the table of players and see if someone is on the radar. So basically, anytime someone connects to a radar it’ll check your theoretical table to see if someone is active on it. And if you need to pass any data you can do it in that same loop
If I understand correctly, you want a system that makes a player report to their teammates when something important happens on the radar.
The way I would go about this is:
On player detection, send a remote on the server with data on what got detected
Verify said data on the server and only keep the parts that are true (so only the claims the server verified)
From the remote player argument, fetch the player team and afterwards all players that belong in said team
Fire a remote back to all the clients that are part of the player team but not that player (so their teammates only), containing only the verified reports (the ones the server verified to be true)
With this configuration, assuming you minimize processing for step 2 and 3, the amount it takes for a teammate to receive a message is roughly time to broadcast from player + time to send to teammate if we assume a moderate ping of 50ms for both clients, it should take 100ms to send a message. Since this message is just informational and not an important part of the mechanics themselves you can tolerate this delay.
Extra points if you add security measures to the remotes such as limited amount of reports per call, rate limiting amount of calls per second, very careful validation of data passed from client to server, and everything an exploiter might try to take advantage of to mess with you.
Something an exploiter can theoretically do is mute their radio and never send any signals to their teammates. This is harmless and there’s no reason to tackle it, but if you insist on doing so you can have a separate server-sided script that monitors when players are expected to fire the server remote based on what they see on the radar, and if you notice a big discrepancy (like a player constantly not sending signals that are expected to be fired) flag it as suspicious.
Pretty much. Focus on sending signals / flags rather than complete data, minimal so the server can understand what is going on and reconstruct it if needed. The reason I think the remote solution is optimal here is because instead of constantly checking each player you only check the ones that actually have something to say / report at a given interval.
There are still many optimizations you can do over this, primarily relating to avoiding sending / replicating duplicate or redundant data. I would also add a minimum amount of time before a player / teammate can receive data about a specific point again, or a way to avoid spam sending signals that aren’t useful (due to the player receiving them already having that information).
Basically you should also ask, for each player receiving a report, what is it worth it to hear, given what they have previously heard?
Scoring the value of information and deciding whether to replicate it or not with a threshold could work too. A weighted sum or function that takes into consideration the above to score the data points.
I think you should do it player-specific. So if a player joins afterwards, and another player re-broadcasts that vehicle, the players that saw it before don’t see it but the new player does.
if server knows everything (well, the game can generate levels on client side and each client has its own level and still requires sending this local radar information which is useless for other players), then this logic can be simplified:
scan things on server, because server knows what every player sees
player sends a single “share my radar to friends” event
Why it’s better:
much less network load (not a single client sends his radar)
no need to validate data from clients
radaring things on potato clients can be costly, it’s better to delegate it to server
This is true, but doing it through remote events, in cases of large player counts, can help with the computational overheard. Specifically by moving some of the calculations on separate clients rather than calculating everything for everyone on the server.