TeleportService:GetPlaceInstances(int placeId)

Returns a list of server instances for the given place ID, sorted by age of the server. Perhaps it can even return a table of tables with information on both the server instance IDs and the user IDs of the players in each server.

In my game, it’s very important that only a single server instance of each place within my game is running. If a place server is full, I wouldn’t allow players to join the place.

Without reliable API like this, the only way to know if there is an active place for a server is by using data stores. I’m not comfortable with how prone to failure this is, even if it does only fail in edge cases. For example:

  1. Two players simultaneously join the same place while it is empty. When the first player joins, the new server updates the place data store key to indicate the job Id of the single server that is supposed to be running, but this doesn’t happen fast enough to be received by the other player before he also joins the game, starting a second server. With this API, I’d at least have a reliable way of checking to see if there are multiple server instances, and then I could shut down all but the newest one and teleport those players to the proper server.
  2. When a server shuts down, data store calls to clear the job Id of the place all fail, and a successful call cannot be made within the 30 seconds before the server completely shuts down. If this happens, I now don’t have a way of knowing if there is a server there or not. I could have servers update this datastore regularly with a timestamp, and if we haven’t heard from the server in the last x minutes, assume it shut down, but this is ugly.

For ensuring there’s only ever a single server, create a ReservedServer for the place and store its ID in the DataStore. Whenever someone wants to go to that place, send them to the ReservedServer after fetching its ID from the DataStore. If it’s full, the teleport will fail, and a new server is not created. ReservedServer IDs never expire, so you’ll never have to make any changes once you define the ID. You could just hardcode the ID into your scripts, but then if you ever want to update it you may have to update multiple places, whereas by storing in the DataStore you can just update the key once.

Is this feature still needed in knowing that?

1 Like

Does the server access code expire after the server closes? Can I send anyone to this server, even if they aren’t friends? Can I get the access code from the server it’s used on? Does this replace game.JobId, which is normally used for teleporting to specific place instances?

This may solve my specific use case for this, but I think there are other uses cases for API like this. For example, back in the global Player Points days, I made an interesting player point store place, because that was all the rage, but it was a game with some interesting twists, and the payout was based on the total points budget and the total number of players in the game, which was hard to get.

Friends aren’t related to ReservedServers, so you can teleport anyone to them.

1 Like

Where do you get this info from? I cannot find this info on the wiki (though I just tested it, and I can confirm this works).

Especially this:

If anyone is wondering, I tested and found that the reserved server access code does not replace game.JobId or game.VIPServerId. I don’t know why VIPServerId has a value for a non-vip server, but ok.

Seems like the access code can’t be accessed from its server through DataModel or anything. Which means I’ll need to have the sending place set up the data store key for the place, rather than let the reserved server set up its own key up.

Personal experience. I created a ReservedServer for this place in the beginning of October. Chat “0” when in the game to be teleported to a ReservedServer – the ID used is ds:GetAsync("Reserved1") which, again, was stored 2 months ago. The code has lasted for 2 months, so I don’t think they ever expire.

Though, after doing further research, I found this quote by a staff member:


Based on the wording and results I mentioned earlier, I interpret this as “we currently don’t do anything to invalidate ReservedServer IDs, but we don’t guarantee that a feature in the future won’t change that”. At the very least, this can be used as a workaround until a more dedicated solution is put into place.

Hopefully the error message for using an invalid code will be descriptive enough that it can be used to just make a new code and replace the old one, which wouldn’t be a problem. You’d just have to know that it has expired.