Splitting map into chunks to prevent geometry theft: potential solution or redundant idea?

Help and Feedback Scripting Support
#1

people have been complaining about map stealing, but it is impossible to stop for now

however, I wonder if someone could just make a system that translates some key (aka string of numbers or variables) into instructions, so then the system would only render a small chunk of the entire map (just the small area around the player on the client)

since technically, the rest of the map isn’t even loaded, so save instancing wouldn’t work as well in this case if you can only see a small portion of the whole map - they’d have to go to every part of the map which would make it a lot more tedious to steal the whole map, and it would be fine if they stole the script that translated the key to the map because they would still need the key to steal the entire map

idk not sure since i’m still kind of new to scripting but this is my theory about the issue

2 Likes
#2

I believe StreamingEnabled does this already.

edit:

on a side note though, I am pretty sure the client can disable streamingenabled… which puts my idea at a flaw

1 Like
#3

The client can of course take anything it has access to. If you only give the client bits of map, it would make map stealing much less time worthy - as you said. I think your theory is good, but you don’t need an entire encryption/decryption program with a key. What if you have the server send the client information (like as a string through a remote event or such) upon request? (Or whenever the server decides?)

This seems like a solution that should work, and may be a good idea!

#4

The client cannot disable StreamingEnabled.

Well, technically it can, but the server doesn’t ever see that change, and will continue to act as if it was never changed, so it’s like nothing even happened.

#5

It’s like that for the server too. StreamingEnabled is only an initialisation property to determine how the engine will render the world during an active game session and cannot be configured at run time. The boolean can still be set but it does nothing.

#6

I’ve found a solution. Does it work, and fit the criteria? Yes. Is it viable for practical application? Very probably not.

Put this in a server script in ServerScriptService

local event = game.ReplicatedStorage.sendInfo

game.Players.PlayerAdded:Connect(function(player)
	renderForPlayer(player)
end)

renderForPlayer = function(player) 
	player.CharacterAdded:Connect(function()
		character = player.Character
	end)
	repeat
		print("Checking for character")
		wait(1)
	until character
	print("Character found and added to list")
	while player and character do
		local hrp = character.HumanoidRootPart
		for i, part in ipairs(game.ServerStorage:GetChildren()) do
			if part:IsA("BasePart") then
				if (part.Position-hrp.Position).magnitude < 120 then
					event:FireClient(player, part.Position, part.Size, part.Anchored)
				end
			end
			print("part found")
		end
		print("waiting time")
		wait(3)
		event:FireClient(player, "destroy")
	end
end

Put this in a localscript under StarterPlayerScripts

local event = game.ReplicatedStorage.sendInfo

event.OnClientEvent:Connect(function(...)
	local tuples = {...}
	if tuples[1] == "destroy" then
		print("Refresh")
		for i, part in ipairs(game.Workspace:GetChildren()) do
			if part:IsA("BasePart") and part.Name ~= "Terrain" then
				part:Destroy()
			end
		end
		return
	end
	local newPart = Instance.new("Part")
	newPart.Position = tuples[1]
	newPart.Size = tuples[2]
	newPart.Anchored = tuples[3]
	--Add more properties here
	newPart.Parent = game.Workspace
end)

It technically works, but it’s very, very unpolished (and probably won’t be worth using in a final state). Instead of splitting the map into parts that are within a certain range of the player, you could change it to send part properties in “chunks” as OP said.

edit: forgot to give more instruction. Put everything in workspace into ServerStorage and create a remote event in ReplicatedStorage called “sendInfo”

#7

This is pointless as an exploiter can easily delete the LocalScript and copy the map anyway. Any client-side anti-cheat will always end up being pointless. I’d recommend you do everything you can server-side.

#8

The exploiter cannot “copy the map anyway”. It’s locked away in ServerStorage. The ideal solution OP acknowledges is that it is more difficult to copy the whole map, not to make it impossible.

#9

They can steal what they can see.

#10

This is correct, however once again I’m telling you OP’s goal was to “render a small chunk of the entire map … so save instancing wouldn’t work as well”