Explorer Services Cleanup [Beta]

Hey Developers,

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.

Insert Service Video Demo

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.

Thank you.


This topic was automatically opened after 10 minutes.

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.


Now I can insert services better :slight_smile: also we don’t need to insert the service to get the service :confused:


1 Like

This is really cool can’t wait to see it :grin:

It would also be cool if it can auto-insert into a script so we don’t have to type out all the services :thinking:


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. :confused:


All I understood was this:

The rest is just words, I don’t get it. Insert Service has been a thing for years.


(and to @emilaltg )

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.


Does this mean the teams service will be easier to access?

1 Like

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.


Thank you, I remember going to Google to find out how to get Teams a while back. I’m glad changes are being made.

I used to run game:GetService('Teams') to view it

1 Like

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.

Will you ever fix runservice having a space in its name? There’s also a lot of services that literally do nothing. An example of this is VisibilityService | Roblox Creator Documentation

1 Like

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.

1 Like

I didn’t know that was wrong! If it gets deprecated I’ll stop doing it.


Removing localization service from visibility is problematic. We store localization data underneath this service.

Great update otherwise!

1 Like

Hey all, we unfortunately need to disable this for a bit due to a crash we discovered. Thanks to those who joined for helping us catch this!


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 :slight_smile:).

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)

Just flipped this back on.

Not that it’s relevant to this because this doesn’t change GetService usage at all, but yes you should be using GetService for all services.