[Live] Changes to ReserveServer

Updates Announcements
#1

Hey Developers,

Very soon we are going to be making a subtle change to the way ReserveServer works. We do not expect many of you to be affected by this change, however a few of you might be.

What is the change?

At the moment when you call ReserveServer it returns a single result, the access code which is used in TeleportToPrivateServer. With this change we will be returning a second result, the PrivateServerId of the reserved server, this ID matches the existing VIPServerId property on the DataModel.

VIPServerId and VIPServerOwnerId will also be deprecated in favor of PrivateServerId and PrivateServerOwnerId.

Why are we making it?

The purpose of this change is to allow developers to store information related to a specific reserved server in a secure way and provide a way to access that data from both the reserved server itself and the server which made the reservation.

What should you do?

While these changes are unlikely to affect many of you, there are a few cases where they might. If you are calling ReserveServer inside of a call to another method then be aware that PrivateServerId will also be passed through this call along with the access code. The following is an example of such a case where this could cause errors.

table.insert(accessCodes, teleportService:ReserveServer(placeId))

Since table.insert can also accept three values it will now throw an error since it expects the second value to be an integer rather than a string.

When will this happen?

We will be enabling this change on Monday the 3rd of September.

64 Likes
Is it possible to get the access code of a reserved server from the reserved server itself?
August Recap: Last Month in the Developer Community
Teleporting Players to Reserved Server Safely With Match Data
Add ability to pass initial data to server when using ReserveServer
#2

Good to know, I was going to be writing code soon that uses this API. Thanks for the heads up! :slight_smile:

5 Likes
#3

This is actually a bad example because unless the function call is the last thing in the list, it automatically gets truncated to one element.

function foo()
return "foo", "bar";
end
print(foo()) --> foo bar
print(foo(), "baz") --> foo baz

But this is probably good news for you guys!

7 Likes
#4

Very glad to see this change, I’ve been looking for a way of checking for a private server ID for quite some time.

1 Like
#5

So with this in mind, is it safe to assume that we may use “PrivateServer” for both reserved and VIP/private servers? As well, on that note, will the behavior of each remain unchanged (VIPServerOwnerId is blank for reserved but not for a reserved server so we can determine what is a public/reserved/private server) with the new properties in place?

#6

Thank you for spotting this mistake, I have updated the explanation in order to clarify potential concerns.

#7

VIPServerId and VIPServerOwnerId will continue to work as expected for backwards compatability. The behavior of PrivateServerId and PrivateServerOwnerId will be identical to that of VIPServerId and VIPServerOwnerId.

3 Likes
#8

Say I make a server teleport people to a reserved server automatically but I don’t want that new reserved server to think its not a reserved server and thus attempt to teleport those people again.

Using this new change, would this then be the correct way to get handle detecting if the server is a reserved server or not?

local TS = game:GetService("TeleportService")

local accessCode = false
local serverId = false

if not game:GetService("RunService"):IsStudio() then
	local DSS = game:GetService("DataStoreService")
	local DS = DSS:GetGlobalDataStore()
	local success, message = pcall(function()
		DS:UpdateAsync("ReservedCode", function(savedTable)
			if type(savedTable) ~= "table" then
				accessCode, serverId = TS:ReserveServer(game.PlaceId)
				return {accessCode, serverId}
			else
				accessCode = savedTable[1]
				serverId = savedTable[2]
				return savedTable
			end
		end)
	end)
	if game.PrivateServerId == serverId then
		print("This is the reserved server.")
	else
		print("This is not the reserved server.")
	end
end
#9

This might be a temporary way for matchmaking until Universe-Scripts come out.

1 Like
#10

Was just looking into ReserveServer and for what I had in mind this change will make it much easier to accomplish, thanks!

2 Likes
#11

This might not seem like a lot for many, but September 3rd is going to be Christmas for me.

6 Likes
#12

Couldn’t be more happy about this change, I hope to see more games add competitive systems because of this.

#13

I don’t think I follow all the hype about how this will allow for better competitive systems. There doesn’t seem to me at least to be any significant changes that would allow for something better than we already had.

#14

No more relying on the client or matching up with players who already joined with a list, you can immediately get data via external website for the purpose of the server

#15

Now a reserved server can be aware of its own access code (as we can connect game.PrivateServerId to the access code). Previous methods to do this involved trusting the client and were hence unreliable.

These access codes can be stored and the reserved server can report on its status (for example - number of players). Other servers can get this information and direct players into the server.

1 Like
#16

This change is now live.

8 Likes
#17