No. It literally doesn’t need to be explained as to why it’s not possible. The server doesn’t have access to your client in specific. The server is only allowed to give the client information, because the server doesn’t own the client.
But it sure would help my game, if there was some solution or work-around for this.
I’ve been planning ways to as secretly as possible pass the info back to the Server, that this Part has been re-animated…
But,
Hoping for an easy out,
Lazy Guy
Or: Any way for me to delete a Part for client, which is unstoppable…
This is for a Fog Of War: Any way to do FOW, which is just as easy as a simple delete?
This is not possible. The client is the enemy, and has control over anything; sure, you can try detecting it, but the exploiter has access to every single line of your code, so it will be futile.
Design your game to not be reliant on the client, instead.
Depends on what exactly you mean. Here’s how I think it works in most RTS games:
Undiscovered terrain is not shown, and “blackness” is shown instead. Units on undiscovered terrain are not shown.
Discovered terrain that is not currently seen is shown as a darkened version. Units on unseen terrain are not shown either.
Discovered and seen terrain shows the actual terrain and the units in that location.
If you replicate the terrain and units all the time to every client, then it is impossible for you to prevent cheaters from seeing unseen units or undiscovered terrain. The solution is to selectively transmit this information to the specific clients that need it.
So:
You only send terrain data to each client when that client discovers it.
You only begin sending unit data to each client when that client sees it. Once they stop seeing it, you stop sending the data.
Unfortunately that means you can’t create unit and terrain models on the server, e.g. by putting stuff in Workspace. If you do that, it’ll be automatically replicated to every client.
And, I’m trying to avoid all of that. Remember; I’m lazy…
My Test124c41 is Open Source, I believe…
Alternate question:
What IS all of the info which CAN be read from a client, by the Server without a Remote?
I am thinking that I can constantly change the .name of every tile on the Server, and send that info along with the Uncover Remote, but I’m still working that out in my head…
n the end, I don’t HAVE to stop the exploiter; just catch him: I won’t let him know that he is caught; just degrade his power so that he and his minions always lose, and hopefully never figure out why.
Almost nothing, and that’s by design and the purpose of FilteringEnabled. It’s designed to throw out most changes the client could want to make unless they came through supported channels like remotes.
Based on things that I’ve seen on other exploiting threads, exploits have reached the point where they can hook into just about every object and redirect incoming requests and API calls from Roblox supported Lua(u) scripts. The exploiter could compromise these and hijack them with the hijacking being completely invisible to your scripts.
You’re better off not trusting anything from the client outside of simple things like “player has moved over here, please provide map info for this area”.
For the second part, you can’t forcefully delete stuff on the client, but you can refuse to send any more data after the client should no longer be seeing it. They’d be left with stale information, which that information wouldn’t be any different than if a human player saw it. The person playing would see the enemy unit and only be able to guess or predict what happened to the enemy unit after line of sight was lost. A cheat or person using a cheat would be stuck in the same position.
Whilst FilteringEnabled prevents almost everything from replicating from the client to the server, there are some exceptions.
Some properties on the local Humanoid
Sound playback, when SoundService.RespectFilteringEnabled is set to false
ClickDetector input events
AnimationTrack playback
Physics simulated on BasePart s which the client has network ownership of
Every other change is not going to be replicated. There are some changes going on with Humanoids too right now where at least one property is being changed to no longer replicate, so the number of replicated items is going down.
I delete a Part for only one Player, but this can be exploited, by; Client skipping the Delete; or even just re-referencing the deleted Part.
They wouldn’t be able to replicate that, they can only manipulate parts they have NetworkOwnership over (ex. unanchored parts), they can’t delete it though, only move it around at most.
Since this doesn’t replicate to the server, you’ll need to detect this on the client side.
Thanks Dani,
I hope you are right, because this method is just sooo easy for FOW…
But the thing is, I am pretty sure that an exploiter can modify a local script. The exploit would be:
That he can SEE the entire map, if all he has to do is comment-out: obj.Parent = nil, which is done right at the beginning to erase the map Localy…
game.Players.LocalPlayer:WaitForChild(“ClearCache”).OnClientEvent:connect(function(Tab) – Tab is a table of every tile on the map, and it’s contents.
local obj = nil
for i = 1, #Tab do
table.insert(CamList,Tab[i].Name)
table.insert(CFrameList, Tab[i].CFrame)
table.insert(RotList,Tab[i].RotVelocity)
obj = Tab[i]
obj.Parent = nil -- this line
end
gave me, I may be able to piggy-back some info into one of those Objects which are readable by the Server to sanity-check whether he is seeing what he shouldn’t. Like maybe a sound-effect, from a Tile, which should not be running for him.