I’m currently making a pretty simple admin script, I don’t want my events to be shown to everyone with studio access, etc… I feel as if its just sort of “immature”
I’ve parented my events to nil in order to hid them, but I don’t know how I should go about getting these events from the server. Any ideas?
Generally people with custom clients can see objects parented to nil.
Your best bet is to create the Remotes on the server, obtain on the client and then parent to nil… and most importantly: sanity checks on the server for each event.
I don’t really care when it comes to the exploiters if they see my events, thats not the problem. I just don’t want to make a folder in replicatedstorage to achieve this. I created the remote on the server, do you recommend I parent it to nil on the client?
If your only concern is people with place-editing privileges viewing your remote events… then sure just set parent to nil on the server after the client has received the instance, this would make it un-viewable on both the client and server explorers.
I personally don’t see a reason for this, especially if you’re making the events at run-time.
It shouldn’t matter if clients see your admin remotes or not, who cares?
Don’t bother. Use your time on something that matters.
Using the following code
local ClientSender = nil
for i,v in pairs(game.ReplicatedStorage:GetDescendants()) do
if v.Name == "ClientSender" then
v.Parent = nil
ClientSender = v
for i,v in pairs(args) do
ClientSender will always be nil, which is understandable. But how should I go about fixing this?
@Kampfkarren I really don’t see a need for people who are making there own games to see my folder in replicated storage, it may confuse them, etc…
If it’s in a folder, then name the folder something that makes it obvious that it’s a third party library. That way there’s no confusion.
While this would work, you still have the fear of someone deleting it, etc… I just feel that it’d be best to hide the events for this particular case.
If I can’t figure out how to properly call the event afterwards from the client then I will just resort to keeping a folder.
This is a really strange concern to have. You seem to have shifted from wanting to craft a certain ‘image’ for your ‘admin script’ in the explorer window, to wanting to protect users from their own mistakes. Which one is your true concern, and why?
Any user of a product is at risk of self-sabotage by deleting component parts. They’re no more likely to do what you’re worried about than they are to delete the whole thing.
That’s hardly the case, I don’t see how its a problem to want to secure the fact that users cant tinker and end up messing with a key component. However at the same time it is also keeping a nicer look, I’d rather install something that is secure, and doesn’t flood my storage space?
You wouldn’t be securing anything - users can modify any and all of it, most obviously your source code itself.
See my post above regarding this being a strange concern. Users may always break your product. Making it harder to see what it does (by hiding things) might even increase the chance that they mess with it. This is not something you need to worry about!
The best approach in this respect is to keep things readable and organised. Deleting things and using workarounds to fetch them back is not good for readability and not good for organisation.
You will not run into any memory issues with a few RemoteEvents/Functions. If you’re actually referring to screen space in the explorer, this is what the expand/collapse buttons are for.
You could do something along these lines
local foldername = ""
foldername = tostring(math.random()))
--insert part where you change your folder's name to foldername and then place it in ReplicatedStorage
if child:IsA("Folder") and child.Name == foldername then
--reinsert remote folder
You could then have a RemoteFunction hidden in a random part in workspace or anywhere you like really that the client scripts can invoke which will then return the foldername or the folder object itself
HttpService is one of the services that are hidden in studio, you can parent the events there.
I do not recommended to:
- obfuscate, hide code.
- close it’s source.
- make plugins that act without your behalf
I wouldn’t use any administrator tool that happen to do any of those.
…? This sounds extremely useless as a practice to “hide events”. Why are you doing it in the first place? You have virtually no reason to.
Not only might it make it harder for you to be able to maintain your code if you’re hiding your events away in services, it’s also incredibly suspicious if anyone does indeed decide to use your admin script.
Also considering your concern is just about people literally seeing your events in the studio viewer, what’s the issue with just creating the events at run-time? Then you don’t need to worry about anyone seeing your events in studio.