This is great! One really useful addition to “migrate to latest update” would be “auto-migrate old servers”. Perhaps something like:
Whenever the creator hits auto-migrate, old servers are not considered for matchmaking anymore, as stated here, and those old servers have an event fired to them. When the old server receives that event, they can do a variety of things such as:
Start a countdown to give players in the old server a couple of minutes to finish up what they’re doing before it automatically migrates them.
Automatically migrate everyone in old servers to newer servers with the new update instantly, effectively removing all trace of old servers.
If these options are not sufficient for how your experiences are updated please share your feedback with us so that we can ensure all use cases are accounted for.
Something I think would be extremely useful is having multi-place scripts.
For example lets say I have a dungeon fighter game and to reduce lag every dungeon is split into a separate place within the experience. Lets say I have 20 dungeons.
Now lets say my game has various swords and I store the damage values in a ModuleScript. If I want to change a swords damage I have to edit the Module Script in ALL 20 places and if I forget just one of those places then that sword will deal less damage in that dungeon. Also fixing a bug will be super annoying when I have to patch it in every single place.
If there was a way to update the same script globally across all places that’d be SUPER useful. A good way it could work is if two scripts can be tagged with a tag name. All scripts that share the same tag name will be updated together. Please consider this and thank you guys for all the updates nothing but approval from me.
Fantastic. You don’t know how much confusion we’ve had when updating Jailbreak. It took us a few updates to learn that places within the experience don’t shutdown with the main place.
Auto-Reconnect is gonna be a game changer and I love that you’re saving data involving who was in the server.
If I had any feedback, seeing a graph displaying old and new server counts would give me confidence the button was clicked and possibly inform my decision on when to push the button. For example, I could push the button immediately after an update drops, or push it when ~50% of servers are already new.
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)
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
(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)
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.
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.
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?
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.
)