Highly recommend all developers to be using Quenty’s Soft Shutdown while Auto-Reconnect is being worked on. I use it in my games and have seen nearly zero loss in CCU when I push updates.
I’m not 100% sure if this would fall under the same umbrella, but some improvements to the Version History page would be nice to have - a month or two ago I decided to make local backups of a bunch of ancient games of mine (circa 2010-2013) when overwriting older projects with newer ones was the norm, and each one took a very long time on account of having to go back pages and pages over and over to find the last version of each particular place. A button on each version to immediately open it in Studio directly from the archive servers would be nice, or at least the name of the place at the time (if such data exists)
Do you know if this would have also resolved this bug: TeleportService.TeleportAsync doesn't work after a shutdown has been performed - #4 by 0xFE0F
You can almost do this today. When functions are called as part of BindToClose they have 30 seconds to complete before the server shuts down. You could use that time to display a message to users that they will be migrating to a new server for an update soon. It’s not perfect - 30 seconds won’t be enough in all cases and you need to be careful that you don’t do something important right at the end of the 30 seconds that could get interrupted (e.g. updating a datastore). But, it’s something you could try doing right now
That’s a bit out of scope for the server update process. Are you able to file a separate feature request for this?
(Sorry for the spam, will consolidate replies now )
@asimo3089 glad we can clear up the confusion! Thanks for the feedback. Giving more information about the current running servers as well as in-progress migrations is something we’ve been thinking about. Might make for a good hack week project
@SixEightJakey Great resource! Another good one is EverCyan’s SoftShutdown2. I noticed Quenty’s does an extra reserved server teleport to keep players together. That’s not required when using Migrate - you can just instantly teleport back to the same place and we’ll keep everyone together. Another note: even after we ship auto-reconnect you might still want to use a SoftShutdown script in order to customize the teleport behavior (i.e. pass some extra teleport data)
@Alex645ca There’s a feature request for that over here!
@plaincamron666 That bug is independent, but should be fixed with today’s new Engine release. Let’s follow up in that post
To confirm, we will still retain the ability to shut down specific servers? It’s important to be able to cherrypick and kill servers in a bad state (either that way through rare bugs or command misfires).
Correct. This is all about Place/Experience-wide server shutdowns. We’re not changing anything about shutting down specific servers
EDIT: Also, if you think any of the “servers in a bad state” are caused by issues on our end and not in your own scripts, please make sure to file a bug report!
This all sounds pretty good. Glad to see migrate to latest update is finally working the way its supposed to!
Just a suggestion I’d like to add… in the case of one of these update shutdowns it would be really cool to have a way to store data from the shut down server and send it over to the new server. This could allow us to restart gameplay wherever the players left off before the update occurred. A feature like this would reduce player anger and disappointment, for instance if they are interrupted in the middle of a winning match or just about to finish a difficult boss fight.
I’m thinking something along the lines of how we can send data with the player when we teleport them to a different place in our experience (but server side).
Oh, interesting! Haven’t heard this request before. With Prewarming + Migrate it might be possible for us to tell the server what the replacement GameId is (maybe in the BindToClose callbacks?) and then you could use datastores to transfer some data around. If you’re able to, could you file a Feature Request for this?
An alternative would be to pass it as part of teleport data (which you can do today) but it might not be as reliable since it’s coming through the player instead of the server. Also, there might be information you don’t want to expose to your clients
It would be nice if we had an actual way to shutdown servers and reserve public servers. I don’t want to disrupt people in the middle of a match and I’d rather transfer them to a new server after. The problem is the old server often stays up longer as it gets bombarded by new join requests and I also don’t want to transfer players to a reserved server because they can only be private, which leads to the server dying out quickly.
My ideal method would be to flag the server for an update, transfer all the players to a fresh reserved updated server, and shutdown the old one/disable it from being considered in join requests from both the website and teleportservice.
I think the only issue with using datastores is if Roblox gets load times down, theres a chance the data wont be saved from the previous server before players land in the new one.
Will we be able to pass teleport data for this though? Is that exposed to scripts? Because it sounds like Roblox is in control of moving players to the updated servers. Teleport data could work for anything simulated on the client + single player games where it doesn’t matter if the client is in control.
I’ll try to remember to file a feature request!
The only feedback I have is that it should be documented and show the difference between shutting down and migrating, because they both seem the same to me.
Where is the best place to file one?
Will there be a way to make old servers stale?
As in existing players in old servers do not get kicked,
but there is no way for more players to join said servers?
It would help reduce frustration with players doing an activity - say currently in a match or a boss fight - getting interrupted, but the issue I see is integration with other features like the Follow/Join system, as in how it would work if you tried to join a friend in a “stale” server.
If not this, then perhaps a “schedule” system for the new Restart servers feature that actively displays a countdown until the servers get migrated, of which we can customise and schedule for a time we see fit?
-- this is what packages are for iirc, you should look into using those for your scripts
Upload that module as a model. Use a script in all 20 places that inserts this model on run time. This way the only thing you need to update is the model which effectively also automatically updates all your 20 places.
The worst case scenario here is having to update the injector script whenever necessary, but usually this will never be required once it has been property set up.
Good news that someone is looking actively at these problems.
In our game we use a custom soft shutdown system. We don’t want to kick players while they are playing, but we want to do it immediately after. Right now we open private servers and send players there when they finish a game. The problem is that the old servers stay up until all of the players have finished their game (max 5-10 mins). New players can still join these, but are insta teleported which results in worse UX.
What we need is a method to stop considering old versions for matchmaking but without the shutdown feature. This would allow us to send players to new public servers instead of private ones. It would also stop the old servers from being populated while we are soft-shutting them down.
Can we have something like this @SuperPat77?
EDIT: I just saw @KepIar asked the exact same thing.
Great stuff, really speeds updating processes up
I don’t think shut down all servers should be retired — It’s still useful in case you’d actually want to shut all the servers.
Unless I may be wrong but does privating a game kick all players?