Allow developers to start, terminate, and restart individual Player instances in Local Servers

Feature Requests Studio Features
#1

It is currently very difficult for Roblox developers to test if features work properly when a player leaves and then rejoins the experience.

In Roblox Studio, local servers (AKA studio servers) are very useful to test how your code will work in a multiplayer setting. However, the control panel for this feature is very limited.

image

Here is an example of a problem that would not be caught using the current studio server setup, where local players are unable to rejoin after their window has been closed:

Many scripts create tables with Player.UserId as the index to serve as a completion condition, like so:

loadedInventory[player.UserId] = true

The script’s author can often forget to remove these entries when a player leaves the experience (and they should just use player instances for the indexes). When the same player rejoins the server, things could break if some important code doesn’t get run because it was reliant on the Player.UserId entry being nil:

if not loadedInventory[player.UserId] then
    loadInventoryRemote:FireClient(player, ...)
end

Sidenote: This is not how you should load player inventories.

The only way for the developer to notice that this system breaks for players rejoining the game would be to observe it breaking in live multiplayer servers.

It’s also very difficult to test how features perform when someone joins much later than a previous player. Consider this sequence of events:

  1. Player1 and Player2 join
  2. Player1 and Player2 build a base together
  3. Player3 joins after a few minutes
  4. Player3 doesn’t see any of the things Player1 and Player2 built

This could happen because the developer didn’t think to replicate new building blocks to clients who join the game after they were placed.

Because the option to connect a player to the local server midway through wasn’t there to begin with, the developer will not observe the issue until it starts happening in live servers, at which point it is more difficult to debug and already impacting players.

Currently, the only way to test both the "late join" and "rejoin" conditions is to use two devices to test in a live Roblox server instance under a published test experience.

It is imperative that developers be able to test how their code handles these conditions, and the “test experience” way adds a lot of headache that could be avoided.

A solution to both of these problems could look like this:

Studio toolbar in edit mode, before starting a local server:
image

Studio toolbar in the window of a running local server:
image

9 Likes
#2

Just to say that this is worse, iirc Roblox never discards table enteries who are indexed by an instance that is now destroyed, they are permanently trapped in memory.

Also, as for the overall feature, is there any reason why you would need a ‘checklist’ for which player instances to use for a test. IE: is there any reason why it’s preferable to have player 1 and 3 initialised at first rather than player 1 and 2, and add player 3 at a later point? Which by the way is already possible since iirc hitting ‘start’ while a server is currently running adds a new player into the next available player slot.

1 Like
#3

Huh, didn’t know this. Clear old entries either way then, but I don’t think using an instance vs a user id is better or worse.

I did not know this either. I’ll be using it, but this isn’t an obvious feature and should be displayed better.

Actually, no. I think I just tried to keep it in line with the image that comes right after. Good catch, but the important part is that you can make players join and leave at will.

4 Likes