Are you using the Create/Save place APIs? If not, stop this immediately and get ready to make large code changes. This is what reserved servers were made for. CreatePlaceAsync to create new servers is a largely antiquated method.
Roblox is capable of issuing server instances at virtually no cost. Reserved servers mimic internal server creation behaviour however restrict joining to require an access code and the TeleportService method TeleportToPrivateServer. This is not the case with CreatePlaceAsync.
CreatePlaceAsync requires the creation of a new asset on the website, which means that there is an extra asset added to the database. If you aren’t making use of the Create/Save place APIs, you should not be using CreatePlaceAsync for server creation.
Anyway, back to reserved servers: recall that this creates one server taken out of automatic matchmaking, meaning you need to manually send players to this server. Naturally, this also means that it is bound to restrictions: it cannot overflow and create a new server (an error will return that the server is full), it abides by the player maximum count, so on so forth.
I might have misunderstood you, but the current problem still is that I need somehow to block extra sub server creation, because once the “CreatePlaceAsync() server” is full roblox creates a new one.
Ah, I see, thanks for clarifying. In that case, you can ignore the bulk of my post (but it’s good to have around for knowledge if a reference is ever needed).
Consider CreatePlaceAsync and how it creates an entirely new place. Due to this, that means that the created place follows standard Roblox protocols for servers. Each server is given a maximum player count and server creation falls into the automatic matchmaking pipeline. That is:
Respect the developer choice of server filling (automatically handled, reserve slots or fill to the fullest extent)
If a server no longer has any slots to reserve, too big a party is sent or in any way joining players overflow the server maximum, a new server is created and they are sent to that server
With this in mind, you aren’t exactly able to block server creation nor interfere with automatic matchmaking. That means you need to rely on the workaround of destroying servers: the question is how.
MessagingService would definitely help in determining how many servers of a specific place exist. You can send out a message to collect servers, which then each server sends back a PlaceId and the JobId. There are several problems you need to resolve, however.
In which place on what server do you collect this data on?
How do you determine which server is the dedicated one for a place? Keep the one with the most players and kick players off all other servers?
When is it appropriate to send out these messages without overusing or relying strongly on MessagingService where potential error can occur?
I don’t have a solution to any of those questions, by the way. Everything in this scenario involves workarounds, there’s no direct solution.
I see now, I thought that there was a property or something to turn off the automatic server creation.
I have used MessagingService before and I think it won’t be too hard to work around.