If you handle the view range locally then you won’t be able to punish exploiters for increasing their view range.
It’s still possible to get localscripts after they’ve been nilled.
If you have somewhat of an idea of where the player’s view is, and what they can see - if a user is repeatedly getting shots on players far beyond their view range (I’m not sure how big you map/view range is) then you could always punish them.
As others have said, I do feel as though for the best experience to follow @Zenuvius’s post (Here’s the post )
Security measures can always be put into place, but honestly I don’t feel as though there’s much point dribble feeding the client the information, rather than all at once.
1 Like
That’s what I’m saying
Also can’t an exploiter just speed around the map at lightning speed by moving their character and get all the map info? Or are you protecting against fast movement?
3 Likes
This cannot be more true:
On the topic of security, no matter what exploit you encounter, there’s always a way to patch it. Likewise, no matter what patch you write, there will always be a way to exploit it. This is the reality that you have to face security-wise. There’s no ultimate patch for anything.
1 Like
I doubt it is possible to change the behavior of replication, however, I would like to offer you some alternatives.
You could send data to the client using RemoteEvents. A local script would place the models accordingly, Since the player won’t move, you only need send data every time their view range updates, unless there is another player in view, in which case you would need to update that player’s cannon/turret.
To shoot, you would send the server a Vector 2 (since the game is 2.5 D). The server can detect hits using simple linear algebra.
For the sake of simplicity and performance when calculating hits, you could simplify a player’s hit box to a circle, while defenses such as walls, could be simplified to lines.
This solution is not ideal, just like Zenuvius pointed out. It may compromise performance, but it will certainly be hard, if not impossible, for exploiters to work around it.
1 Like
You could write your own replication module, store the map in ServerStorage and send data to each client through RemoteEvents, every part being linked with its serverside companion. You could even lower network traffic by sending relevant data that the client could maybe reconstruct rather than sending data for every single instance (ex: updating one part’s position in a model rather than sending every part when calling SetPrimaryPartCFrame). With that, I’d say you’ll have more than enough bandwidth to work with
4 Likes
Exactly, this reminds me of some kind video compression: In each frame, you only save the values of pixels that have changed, not the value of every single pixel.
This might make the client code more complex, but in my opinion, it is worth it.
2 Likes
I have a late suggestion; you could try setting all the characters’ Parent properties to nil. Exploiters could however run code that stores all the characters in a table before the client removes them from view.
To combat this, I’d further recommend keeping the characters parented to the Workspace, then setting each of their BaseParts’ parents to nil. When you need them back in view, simply parent that component back to the character rig.
This can get complicated, but you can leave the Workspace empty server-side so the contents don’t replicate, and send only the information the clients should have access to through RemoteEvents so they can reconstruct the map on their ends.
If you need characters, you could try putting an empty Model in StarterPlayer and then put in all the character stuff client-side once the empty character model spawns. I never tried that though, so if you do try, expect things to go weird.