Wasn’t sure if this was a client or studio request. Lots of times plugins will create objects like selection boxes to help the user properly view things. These objects are of no use to the studio user and all they do is clutter the explorer, so it should be possible to hide them.
EDIT: Another solution would be a version of the Workspace only accessible to plugins and higher.
To complement this feature I think that a checkbox on the explorer to show these hidden instances would be useful.
If this didn’t exist, malicious plugins would be able to insert scripts to let the plugin creator control the place (e.g. admin commands, ban lists, etc.)
Or the plugins actually use CoreGui as they should.
Parts don’t go into the CoreGui. A restricted workspace only accessible to plugins and higher would be a potential solution.
This could be used maliciously, so I can’t see ROBLOX wanting to implement it. People like you or I could easily scan the game for hidden objects, but less crafty users wouldn’t know how to.
God – Osyris, not everything is a freaking security hole. Yes, plugin creators could maliciously hide things in the game, but this hasn’t stopped plugin creators from doing this already. Just as you were complaining that code minimizing persisting through closing would cause a security hole, that hasn’t stopped people like Kohl/Scripth from requiring modules from the site, preventing any access to the code with malicious crap hidden in it. Plugin creators already can and do put malicious things in their plugins, and plugins won’t have good ratings like the one above if they’re malicious. On top of that, woo-hoo, I hide admin in places with a plugin!! That’s really going to make a huge difference!! If it’s a script that deletes the place, the user is going to realize very quickly that something is wrong, and will downvote the plugin when they figure out that it’s the issue. We have that rating system for a reason – if people want to install a plugin with 100% downvotes, then I seriously doubt the inability to hide objects from the explorer is going to help them either.
This is a security hole.
workspace.InFeCtIoN.HideFromExplorer = true
--muahahaha[quote] This is a security hole.
workspace.InFeCtIoN.HideFromExplorer = true
--muahahaha
[/quote]
while wait() do
local securityhole = Instance.new("Motor6D", game.Geometry)
securityhole.Name = "InFeCtIoN"
--muahahahahaha
end
that didn’t stop ROBLOX from using Geometry though did it?
so are you proposing that roblox invite skids to do malicious things?
if there is a security hole, skids will exploit it, and unless you can get a real tight lock on how HideFromExplorer behaves, you will have a very bad no good day.
A better solution is a secondary workspace hidden from explorer instead of a per-part basis.
And I agree with you on that, a non-archivable workspace for plugins to use that wasn’t displayed in the explorer would be a better solution. However, the ability to hide items from the regular explorer still isn’t that big of an issue. If I want to infect your game, I can just spam things into the geometry – if I want to have admin in your game, I can pull a scripth and mass-distribute a admin module required from the site that you can’t edit/see if I want admin. The simple ability to hide objects from the explorer won’t change anything. Even when MotorPs or whatever they were called were hidden from the explorer, all people were doing was hiding infect scripts in them, and the Geometry is a better place for those anyway.
so:
HideFromExplorer can be improved by having a plugin-specific workspace
it’s easy to bring games to their knees
the reason why I oppose HideFromExplorer so much is it has the potential to muck with studio copies of the game. If you were to save the game after it got infected and use that version, that’s stupid. Infecting studio copies (.rbxl/x) is absolutely verboten though, and HideFromExplorer is a good way to do that.
Did you guys just not read the first reply or what
[quote] To complement this feature I think that a checkbox on the explorer to show these hidden instances would be useful.
If this didn’t exist, malicious plugins would be able to insert scripts to let the plugin creator control the place (e.g. admin commands, ban lists, etc.) [/quote]
Arceus can you edit the title / post so that instead of .HideFromExplorer, it’s a non-archivable workspace for plugins?
I don’t like that it clutters the Instance API for a feature that is useful only for plugins, which in turn is useful only in studio. If it were me, I would request a couple methods under either the Plugin or its own service, which let you tag an instance as being hidden or visible.
However, I don’t think this is a necessary feature. There’s nothing wrong with putting bricks under the CoreGui (if you have it visible, you can even drag bricks into it). In fact, it would be preferable to do this while combining them with adornments, so that users don’t experience the interference that bricks cause just by being bricks.
Do bricks render on the screen while they’re in the CoreGui?
No. Adornments will, though.