So the point here is simple. We know that by the rules of FilteringEnabled, nothing on the client is to be replicated to the server.
The goal here is to do the complete opposite: I want the engine not to replicate the server’s workspace to the clients. How would I do such a thing?
The Context
I am creating a game where players have to expand their view area. To achieve that, it’s crucial that the client only has the very required information of what’s inside their view range. I made a small diagram explaining the goal of this:
Each client only sees what’s inside their range. However, if the server replicates the whole workspace to all clients, even if the parts have transparency 1, an exploiter could still see beyond their area and unfairly get an advantage.
If there’s a way to disable Workspace replication in both sides, I could implement my own replication system that only sent the clients what parts entered their range.
Just an idea, you could store the game world in the ServerStorage, then when you want to update what the player sees, send them a clone of the objects and store it in a place where that player can see it (I think if you put it into their PlayerGui, then both the server and that player will be able to see it, however other players will not - don’t quote me on that because I can’t remember the exact details). Then each player could build what they can see locally.
Try attempting StreamingEnabled, maybe it will hide a few things from the client as things tend to not be rendered. But then again, I don’t know how big your game is.
I was about to suggest something similar to what @ITBV said, but I do want to caution you that this is going to be likely to be very, very slow. You may be better off writing this all client-side and then writing a security script that punishes players that cheat the system, and that can communicate with the server for validation.
You could, for loading purposes, increase the area of which parts are within range of the player (not viewing area), to load them before the player is actually able to see them.
It would be a good idea, wouldn’t I also want the server to still calculate physics on those parts (e.g. projectiles launched by turrets to validate that they have indeed hit other players), which then would force me to make my own custom position tracker and collision detector - which isn’t an ideal thing. Plus, as far as I know, the server can no longer acess the client’s PlayerGui.
As stated already, while StreamingEnabled does indeed limit the player’s view, the server cannot control the distance of it on a per-client basis, so it’s not an option really.
The issue here is that given that the Workspace replicates normally, even with fully transparent parts, an exploiter can still delete all client-side checks and keep telling the server that everything is being operated normally. There isn’t really a server sanity check unless in very edge-case circumstances (e.g. if the player is trying to build something way beyond their area)
You’re right to be concerned about client-side exploits. But having the server go through a large list of parts / models / etc. for every player multiple times per second and then having it find a way to replicate that to every client is going to be very costly. Perhaps you could do a blend - have the server have a series of large squares of the map stored, and you can just check what square(s) the player is in. You can then send them just those large areas of stuff, and the client can then do the checks. If you do that, you’re limiting the power of an exploiter while still managing to keep workload distributed across clients.
As for where you can actually put the parts, since they won’t be in workspace… I’m not sure. Perhaps PlayerGui will work. It’s definitely not PlayerGui’s intended purpose, but I don’t know where else it could go.
The problem, though, is that even if you do this, exploiters are going to be able to just clone whatever you do eventually send them into the workspace and then they’ll be able to eventually build a large map of the entire world by just walking around the entire thing.
Ultimately, exploiters are likely to find a trick. I’d contend that it is better to build your game for the rest of your players and then just try to implement anti-exploiter techniques if necessary.
Also, you may want to consider just using the fog settings in Lighting, although this again is an exploitable technique.
You can have all the map in Workspace, you just have to make a LocalScript that makes everything invisible, (Transparency = 1), except things what’s in view range, make the player every time he moves certain studs, update the Transparency of what is in the View Range to 0 and what was before to 1, so as not to update the entire map, what you do changes in the Client will not be seen in the Server and in other clients.
If the view range for all players is in the workspace for all players on their client, a hacker can just find where the view ranges are and make them visible.
I already gave a solution but he seems to want to do it a harder / less effective way.
Reposting to try and get my suggestion across as it’s the simplest and most effective method.
Player A makes their own view range on their client.
Player A detects when someone or something enters their view range.
They fire to the server and validate it. The server checks if the person or thing is actually in the view range radius or not. If it is then it’ll do what it needs to do.
This is more effective than cloning a whole map to the client for each client like people have suggested.
