We have made some changes so that the Explorer is now more intelligent about when it displays a service, while still allowing any dev to manually opt into service visibility per place. Specifically, we ensured that the Insert Service menu works for all services that can be inserted into Explorer.
As was the case before this change, any service inserted into a place’s explorer will stay visible whenever that place is opened, by you or by any other collaborator (Model > Advanced > Service).
This should make for a more straightforward default service and service insertion experience in the Explorer!
To enable the beta in Studio, go to File > Beta Features > Enable Explorer Services Cleanup.
We’ve also chosen to remove two services from default visibility:
TestService
LocalizationService
Both of these services will remain in games in which these services already contain instances, and your Lua code will always work no matter what in both new and old places. These services are currently only used by a small number of developers who can easily re-insert these services via the newly improved insert service menu.
Known Issues:
You can’t currently remove a service from default visibility; this means that if you insert a service into a place from the insert service menu, that service will remain visible in that place (for you and any collaborators, even after restarting Studio) and can’t at the moment be removed. We’re planning to add a Remove Service functionality during this beta rollout process.
We hope that these changes make for a service insertion explorer navigation experience! If you have any questions or comments, please post them below; we’re eager to hear any feedback you have.
For anyone interested, the way service visibility works now is a bit quaint.
Essentially, any service that could be visible (think Workspace, but not HttpService) would be visible if the service existed at all. Services don’t always exist, but the moment you :GetService, they would be created. You can observe this without the beta by opening up a blank place and typing game:GetService(“VoiceChatService”) in your command bar, you’ll see it show up in the explorer because it’s created at that moment!
This is what the “Insert Service” menu was for, forcing these to be created. Originally, this was useful for “Teams”, which used to be unavailable in a place by default, but somewhere along the line, internal code called the C++ equivalent to GetService, which created the service instance, and now Teams is always visible.
This has been changed, and now services can opt into contextual visibilities, and now “being in the data model” is no longer the only qualification to being visible.
Sorry, I don’t understand anything this said. Is this meant to showcase the insert service command? If so, then that already exists. You even said it yourself.
I don’t understand this. I need a better explanation.
Insert Service has been a thing since the beginning, but hasn’t actually worked for a while. Until very recently, it showed you 20-30 services, with only one of them (VoiceChatService) actually functioning, every other one would either do nothing or throw an error. This was fixed as of I think a month ago.
The way it was setup also prohibited us from ever actually reliably making services not visible. That’s been fixed.
From a creator perspective:
That’s a completely fine takeaway–we roughly want to understand if there’s higher demand for these services to be visible than we expected, or if there’s anything else we’re missing.
Nothing about Teams has changed, it shows up in places by default because of the weird behavior I mentioned. It’s just an example of why Insert Service was added many a time ago. Nowadays it’s used enough that we didn’t feel justified disabling it by default.
Can there be a toggle that shows the specific services that I am using in my code in explorer? Or some sort of log that shows every game operation being done and then, having that game operation into categories so that it’s easier to pick apart what’s happening in a game. For instance, an operation could be as atomic as a part being moved or an event being fired. Would feel more intuitive than doing it manually.
There’s a lot of clutter for services that I don’t really care about. It would be nice if magic was applied and it dynamically showed a smaller "tree: to me as an ease of use feature.
That would break a lot of code. Unfortunately, some programmers still write code without using GetService when using RunService(*cough* @MrChickenRocket PLEASE MY EYES *cough*), so it probably won’t happen any time soon. There will likely always be a way to access RunService through the hideous Run Service.
Just because it doesn’t have a Luau-facing API does not mean that it does something under the hood. For example, I believe VoiceChatService did not have any special API until several months after release, but it was still the one that came with voice chat, which makes me think that it is the thing that handles voice chat under the hood on the C++ engine side.
Not that it’s wrong per se, just that for some people it looks wrong, with having spaces in the instance name and then using [""] syntax to find it because the widely-used . can’t be used in that scenario.
But I would still encourage most to use :GetService because that’s just the more commonly used and encouraged practice (I see a lot of people saying that it’s the “canonical” way to get a service, I have no clue what that means but I think that it looks nicer ).
If I had to guess, “canonical” means the intended way in this case.
As for my own opinion on this update, It’s a great improvement. (if it was enabled, thanks software crashes)
also we don’t need to insert the service to get the service 
