As previously mentioned before, there are no methods of stopping server-to-client replication. What I think you’re trying to achieve here is the limitation of rendering parts.
In fact, that is already handled by workspace.StreamingEnabled. Set it to true.
In the other hand, you could possibly set the parts generated in the client with the transparency of 1. Yet another hacky solution.
Oh, if the LocalScript is not working. It’s probably because you did not parent it appropriately or the method you’re using does not apply for all-case scenarios.
S’il vous plaît expliquer le problème que vous essayez d’accomplir et non vous êtes la solution au problème.
Comme moi-même et d’autres l’ont mentionné, il n’y a presque aucune raison de créer des parties réservées aux serveurs. J’aimerais donc savoir ce que vous essayez de faire en général.
What exactly is sought?
OP is looking for a method for preventing exploiters from crossing map boundary. We unfortunately cannot create hidden hitboxes for the client from the server without replicating the parts. As you can see, there are other methods for creating the map boundary or barrier.
What is the true solution?
Server hitboxes with actual parts. The server detects touch from the part deleted from client. It still exists on server, which means that if the player attempts removing a deadly part and cross it, the server will find a .Touched event of it and fire something.
Some other solutions pointed out an alternative for boundary. Which we can find in EH2018, where it works exactly the same as described above(sort of) and knocks the player back. You could teleport the player back into the map somewhere random when they attempt to go somewhere where the players are not supposed to be in/at.
Another solution could be checking if the player is reaching out of range. Using Player:DistanceFromCharacter(Vector3).
Replication
Clients cannot escape server replication or anything done at the server and they can certainly not manipulate the server, unless there are exposed remotes.
En fait, le serveur n’enverrais pas des “Parts” mais une liste ultra compressée expliquant où créer ces “Parts” (Le client verra une liste et se mettras à créer un clone du Terrain à partir de la liste, j’ai déjà créé le “LocalScript” qui clone le terrain à partir d’une liste)
Mais le serveur doit toujours avoir les “Parts” pour gérer la physique…
When you generate the parts on the server, put them in ServerStorage. This way, they won’t replicate to clients. And you can put the client generated parts in Workspace. The only problem with this is that physics won’t render with parts in ServerStorage if you needed that, but they will still exist in space if you just need to check their position or something.
