This is a common post topic, but I don’t see any solutions to this situation that made sense to me.
For example if you want fog for your player, you need to only replicate it to the individual player.
The presumtion is that to prevent cheating this must be done on a server script, which replicates the fog to all players, thereby making each player’s fog union visible to each other.
What should I do to only make the fog visible for the individual player?
--Server Script
local fogUnion = game.ReplicatedStorage.fog
local function fog(plr,character)
local plrFog = fogUnion:Clone()
plrFog.Parent = character
game["Run Service"].Heartbeat:Connect(function()
plrFog.Position = character.HumanoidRootPart.Position
end)
end
game.Players.PlayerAdded:Connect(function(plr)
plr.CharacterAdded:Connect(function(character)
fog(plr,character)
end)
end)
You would need to use remote events and FireClient, running the fog function from a local script (or just running the function in starter character scripts). It wouldn’t prevent cheating by creating fog on the server since an exploiter could still destroy the fog part locally for their client, and the server would have no way of directly detecting this.
Yes but it could prove to be very difficult, since any anticheat for this case would probably still rely on relaying information from the client to the server, which can be tampered with by exploiters
Im not aware of any methods to do that, but even if it did exist, the fog being created by the server must be stored somehwere in the memory of the client’s machine for it to exist on the client, and so is vulnerable to exploits.
I just thought of an idea to make the fog on the server, and then let the clients have a localscript that disables the fog of other players. That way they can’t mess with their own fog(?). Idk if this would be exploitable or not.
The only thing I could think of for an anti-cheat to throw off most inexperienced exploiters would include firing regular remote events e.g every 30 seconds from each client to the server, containing information about the client’s state of the game, like a bool indicating if the fog still exists on the client etc.
And on the server you would be making sure that the game is receiving this event every 30 seconds from each client, and confirming that the information sent by the clients is as it should be, and if not you could kick them from the game.
But im not sure if this is worth the resources, which is why almost no games bother with an anti-cheat against this type of exploit, and you could instead use some system like a votekick system against cheaters.
so the exploiter cannot remove the remoteevent or stop it from firing?
I’m assuming you’d need to run it every frame though, since they could make a macro that enabled/disables it when needed.
thats what this part is for, but even then they could just inject their own local script to send false data using the remote to the server every 30 seconds
I recommend to make the fog client side. When moving the fog on the server, not only will it lag on high ping. but it can also be exploited both with executors and lag switches.
Also your hiding approach on the client will produce more useless work for the clients
I think you should just trust the client a bit and render the fog on the client. All vfx should be on the client, anyway.
If exploiters want to remove the fog so they can see and have a advantage…well, there’s really nothing you can do. Other solutions would cause more lag.
Real fog of war isn’t done by rendering fog on the client, that’s only for a visual effect. In games with real fog the server stops transmitting information to a client that it wants hidden from them. This is usually stuff like player locations outside of what the server determines their field of view radius.
Roblox automatically processes and relays all player position data automatically. Notice how you don’t have to code for basic client side movement to be seen to all players, it’s already built in to the engine.
Doing an effect like this in Roblox would be a bit trickier because of this. It’s hard to imagine a way to do this that is client sided and also not easily exploitable.