I am wanting send a set of miscellaneous of things to a client, that’s meant for that specific client. I would like to send a GUI, including everything inside the GUI, to a specific client (i.e. debug/cheat menu). As well, some other data that could be only seen by the client. I have seen games use this technique based on console logging. I am just unsure if they’re just using the ReplicatedStorage as their host, or if it’s being transferred over RemoteEvents or ModuleScripts. I am just wanting to hide certain things from the server that isn’t necessary and that exploiters can’t access / steal those objects from another client’s Player instance. If this isn’t possible, that’s completely fine. I just want to lower the risk of exploiters accessing certain things. As well, as I know with the new anti-cheat, the exploit rate has lowered but isn’t 0.
This is an X-Y problem, even if you were able to send the interface over an event, you would still need to secure the actions, etc… within the interface itself.
To answer your question directly, you can send instances from the server to the client, but in order to do so the instance itself needs to be readable/accessible from the client. This means it cannot be in ServerStorage, it needs to be in an area in which it would be replicated.
It doesn’t matter if people have access to your admin panel on the client, as long as the actions it performs are secure. You could put it in every players player gui (ie; just add it to your startergui), and then on the client- make it so it’s only visible to specific people, such as your admins.
On the server, when you fire the events on the panel, you ensure that the event fired is coming from an authorized user.
Sure, exploiters will be able to view your admin panel alongside mess around with it, but they won’t be able to perform any actions.
You could do some sort of dropper-method, where you clone it from ServerStorage, and put it within the player (if I recall correctly you can directly access a player’s PlayerGui from the server, even if it’s bad practice), and then you could have a client listener for that interface (or in your case send the interface over an event)
But I still don’t recommend doing anything I just mentioned, it’s just simply put- not worth the effort.
Fair enough, I figured it may be bad practice but it may be something I’ve seen in games, just going through Replicated Storage as per-normal. Thank you.
If the server can see it, so can exploiters. However, exploiters can not execute on the server side no matter what (unless you have some remote that causes a vulnerability or whatnot), sure the exploiters might be able to know what the debug menu looks like, but they won’t be able to use it.
If the debug menu requires server-sided access of some kind, then you can just [verify if they have the debug menu on the server and or check if they’re allowed to have it].
I think you’re viewing it in a different perspective as I am. My goal is to send something to the client, afterwards only the client can see and use it. Such as if the client created an object, but only the client can see it as it isn’t replicated.
Theoretical example:
When a player joins my game, and is said verified user. I would like to send data to that client where other clients can’t intercept or view the objects I am giving to that users. Such as not adding the GUI directly to their PlayerGUI, but maybe sending an event to the player of the object, or the data on how it’s built. Afterwards sending data about the scripts on how it’s suppose to run. Therefore only the client can see and use it. Events will, of course, have checks to ensure the player that is attempting to Invoke or Fire the server’s event. is validated.
Another example is games such as FiveM or maybe Modern Warfare that will give user access or “stream” these assets for the player to download. That way, they have “unique” data for that said users that would be only available to them. FiveM is a good example since Lua files are streamed to the client and only usable by the client and can’t be access by other clients.
Note; there will be checks to ensure the events fired are checked, presuming I don’t make a mistake in my code.
Yeah such functionality sadly isn’t possible without using remotes to send the player a newly-replicated object (among the various issues that come with that). If it’s not a debug menu or something then I don’t see the issue with storing it in a replicated area.
I’m not confident it would even be possible to stream assets privately as an engine feature as I imagine anyone could still intercept it, server-client boundary communication is a nightmare!
Again though if we’re talking about exploiters being an issue, exploiters have access to everything that a client script has access to and even more. Beyond securing remotes, trying to improve security on the existence of a debug menu is pointless…
Hypothetically though, you could have the debug menu stored in an external ModuleScript stored as a model and find some way to call it in only when you need it.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.