Can exploiters override local camera scripts?

Help and Feedback Scripting Support
#16

exploiter can see the whole map and find the exit

Don’t let them see the entire map. You can do this by having the server only show parts the player can actually see.

2 Likes
#17

You can’t stop exploiters from moving their camera. The only way to combat this is to not give the clients all the information. You can do this with StreamingEnabled or your own replication system.

#18

Ignore the camera, couldn’t they just TP to the exit? (even if they couldn’t see, they could use dex to get the ending part and TP to it)

#19

Exploiters running local script with exploit.
By the way, they reach out of reach.

for example:
ExploitGui.Parent = game.CoreGui – they can acces :frowning:

#20

How can I go about making that? I think you mean what I mean’t before of adding some sort of fog around the player on the server without using the fog method built into the game, Something surrounding the HRP. Can you explain to me how i can accomplish that?

#21

I have TP countermeasures in place, they can’t TP without the game kicking them.

#22

Have all the parts in workspace but their CFrame is 0.
The server sends remotedata to clients based on player position and what they should see. The data tells them to locally place certain parts accordingly. Parts outside of their visible range still have the default position so they contain no information. It’s very similiar to the fog of war mechanic.

1 Like
#23

Isn’t this taxing for the client, regarding Wi-Fi connection? I do have already a great deal of package handling in my game. It could cause lag for those with less bandwidth. I need a more solid solution regarding this. I was thinking of something more like a render distance, where i could divide my world into chunks that i can load in depending on the players position. But i find that thats completely impossible ;-;

EDIT: I actually found a thread where someone attempted to achieve something similar, but not for the same reason

This is probably as close I’m going to get finding a solution for this thank you.

#24

Cameras are controlled locally and the exploiters console is firing off local scripts, this is why they can’t access server scripts & scripts in areas where only servers can access. So yes, they should be able to modify the values in a camera script, unless the values are always fired from the server into the client

(from what I believe of course)

#25

Alright but make sure that it’s server-sided, otherwise, they can bypass it using metatables (they can also get around server-sided anti-TPs too, using tweening but at least you’re preventing some of them)

#26

to prevent anti-tp things you should make indelible function to your local script
i mean:

local sc = script:Clone()
local fixing = false
script.DescendantRemoving:Connect(function(d)
	if d == script or d:IsDescendantOf(script) and not fixing then
		fixing = true -- to prevent fix spam
		
		sc.Parent = script.Parent
		sc.Disabled = false
		
		pcall(function()
			script:Destroy()
			script.Disabled = true
		end)
	end
end)
#27

That’s where CoreGui traps come in. If an exploiter is so stupid as to use game.CoreGui instead of using GetService, that’s a free detection for us as game developers, as you can setup CoreGui traps knowingly to prevent skid based exploiting.

1 Like
#28

yes your right but they can place gui to CoreGui

#29

If they use game.CoreGui to reference it, then you can rename something like TextService using game:GetService(“TextService”).Name = “CoreGui” and set up a check for any objects attempting to parent to game.CoreGui.

It’s funny how many skids you can catch with it.

#30

To my knowledge, most popular exploit is Synapse X and it automatically uses GetService, so game.CoreGui will become game:GetService("CoreGui"). Though that’s still a pretty cool way to catch them.

#31

One step-ahead everything was already, server-sided using coroutine and its almost impossible to bypass efficiently without ‘real server breach’

#32

Yes, but my main thing isn’t about getting skids, though its the vast majority of exploiters. Its not bullet proof as they could just get all services in the game, and figure out which is which with trial and error.

#33

Your anti-TP has one little flaw they are capable of editing local scripts as we just did go through. Its better to have something like this. It could have flaws to such as high ping making this very sensitive though pretty good, it also is very sensitive too player falling, so will have to find a sweet spot for your game and i find 25 to be good enough for my game as the players don’t have a large drop.

Server-Script:

#34

Exploiters have a lot of tools to mess your game up - but they especially thrive in local scripts, they can see their content, they can fool them entirely, they can also disable and delete them.

Taking this into consideration, plus the only option to modify the player’s camera is by a local script, I have to
unfortunately say that, there is no good way to prevent tampering with your camera script.

1 Like
#35

Yeah thank you for your insight too, I’ve come to the conclusion that i should restrict whats being loaded in as in models just like the chunk loader i showed in my reply, currently working on it but it seems as it is working so far.