IIRC setting a place to be private also cancels private server subscriptions. Will Roblox be giving us any recourse to our subscriptions if we had to go down this path? (Or is this even still a thing? I don’t have the nerve to attempt to make our live games private to find out)
18 Likes
Thanks so much for this in specific. Any soft-shutdown method in games I worked on received backlash for pulling people out of their private servers.
4 Likes
We are forced to use the “Shutdown All Servers” option because we don’t technically update all our 12 places on our game when we update. We use InsertService to add our place files when the server first initialises, and update that one model instead.
Puslishing all 12 places in a game individually is time consuming and high friction, so using InsertService was a great way reduce that labour. However, “Restart Servers For Updates” doesn’t count these places as being behind the latest version, so we’re forced to use Shutdown All Servers and use a 3rd Party Soft Shutdown script.
Please, do not take away Shutdown all Servers until there is a system in-place to account for restarting all game instances, regardless of current version. This will dramatically worsen our own ability to perform Live-Ops on our games.
Link to Game: 🐲Dragon Adventures 🐉 Fantasy Pets ✨ - Roblox
17 Likes
soft shutdown service wont be needed anymore im guessing
2 Likes
Is there any chance to be able to modify some sort of callback relating to this (like MarketplaceService.ProcessReceipt? I can imagine that in many round based games, it would be ideal to let the round come to its conclusion and then teleport players.
Some callback function logic might ideally function like?:
game.UpdateReceived = function()
--// Assume this is code that executes/can yield before players are automatically teleported
local MatchService = require(SomeModule)
MatchService.CurrentRoundEnded:Wait() --// Yield until the round is over
print("Round over! Ready to teleport") --// Callback complete, players are teleported
end
12 Likes
This is great! Is there any plans to make it so servers can wait for a round to end before sending the players to the new server?
2 Likes
Can we get a way to stop this from happening in specific situations? I would like to create new servers and teleport players manually with a script if they are in reserved servers, instead of being thrown into a public server as mentioned in the post.
Overall great update though, no need for soft shutdown scripts anymore!
4 Likes
this is great, but it still seems like shutdown scripts might still be the way to go… based on the announcement, it seems like this lacks a ton of needed customization…
4 Likes
This is really useful, after restarting my servers, there was a significant drop in ccu and it took a bit of time to restablise. It would be cool if you could restart for update with optional options, lets say restart server and teleport players to the position or something along that where they left off. Maybe you could also send a optional broadcast message, and maybe with a timer, were it will announce that servers will restart for update “New cosmetics” or something along that and give players a timer to prepare for restart.
2 Likes
nooo! My experience uses InsertService:LoadAssetVersion and InsertService:LoadAsset to load it’s files across all places. Do we seriously have to private the entire experience for a small patch, or open every place in studio to publish them all which has it’s own risks such as accidentally publishing place-specific content.
9 Likes
This seems like a reckless and concerning change to critical behavior. The forced dependency on place version instead of just shutting down all servers means that games which rely on InsertService to load assets will have no way of indicating that they need to be restarted.
14 Likes
Thank you for this! I have always noticed that about a third of players leave the game when I update the game because they receive a vaguely-worded kick message that said “Player removed from DataModel”, and understandably think that this is some sort of glitch and don’t realize that it’s just the server updating. This is why I always update at the lowest hours and never the peak hours. This will help remove the confusion players have when the game shuts down for updates.
2 Likes
I’m seeing a few comments on planned updates, updates at the end of rounds, more customizability options via an API, and/or further advance notice (i.e. a countdown). This is great feedback to have.
The team is already considering a number of improvements to how this works and we absolutely want to give you greater controls, including the ability to update individual servers with more granular control over timing. While I can’t share anything concrete yet, these are all things that the team wants to keep working on.
16 Likes
Can you clarify how this will work with games that rely on insert service to publish updates? Developers should not be required to publish every place in a universe in order for this system to work…
8 Likes
“Wi-Fi cutouts”
It would be nice if Roblox fixed those
Most likely, they are not caused by the player’s wi-fi, but rather roblox glitching out and preventing anything from the server from reaching the client (yet the server still receives whatever the client is sending)
When it happens, the disconnect prompt takes A WHILE to show up (probably because the server still hears about the client). Bug reports have been made for this issue, but I don’t think it has been fixed yet
3 Likes
Hello! In my games I incorporate a “Soft Shutdown” through the use of “Shutdown All Servers”. The way it works is I teleport all players to a dedicated place fitted with some UI indicating “Updating please wait…”
Doing this gives me time to ensure everyone’s locked profile session is released and ready for them to reload when they get teleported back.
I really like this new feature, but It would be really nice to continue to maintain “Shutdown All Servers”.
Yes I know I can make it private and public, but this is added work for a functionality that we already have in place.
6 Likes
This is great to hear, and I am really excited to see what you guys end up doing! The way I see things could work is that once you have clicked “Restart servers for updates” you could give the players an option to already restart their game, and teleport to an updated server, by pressing a button. But lets say they are currently playing a round of a game. Then it would be nice to give them like 10-20 minutes before a forced shutdown occurs, just to give them time to finish that round they are playing. The shutdown time should be controlled by the developer though.
2 Likes
While this is a great feature, a ton of developers depend on custom logic for shutting down their servers, and also there might be multiple places that they want to shutdown completely, instead of making players rejoin.
Roblox, please stop trying to take our freedom away with updates like these. Same happened with Core Gui, developers have custom systems in place for their own experiences. Respect them instead of forcing a feature down their throat.
3 Likes
This kinda sucks for me.
My game is a perma death game where if you leave while in combat, you lose your gear/loot. We do this to prevent people from leaving before they die in a fight so they can keep their gear. Loot is also super valuable and my players become quite attached to it, and the process of getting it.
Our shutdown process for updates used to look something like:
- put a warning out to all servers to block “combat logging” from occurring
- give players a constant notification that servers will shutdown shortly
- shutdown all servers a few minutes after the warnings are confirmed to have gone out
We were able to apply patches quickly and precisely, and mitigate the period of time where players could abuse the “combat log” blocking. We were pretty much guaranteed that after pressing shutdown all everything would be refreshed.
I can’t get away with not notifying players of server restarts because of the value of loot, and if it’s going to take “up to 6 minutes” then all I’m doing is broadcasting a very long period of time for players to abuse a safety mechanic we need for updating.
As a developer I wish I had more agency in how my severs shutdown and how players are migrated to new servers. This gives us less control than shutdown all, and gives us no control over updating it in way that lets us maintain gameplay smoothness for players.
If I’m making a wish list for a solution that suits my needs:
- I’d like to be able to mark a server as unjoinable from a service in game
- I’d like some event that lets a server know a new place version is available
- I’d like to teleport players (individually, or in a group) once they’re at a gameplay safe state to new servers
19 Likes
BindToClose should still work as expected. This will happen after developer bind to close scripts have run. For example, teleports in BindToClose will take precedence and then after they complete, the default behavior will happen.
13 Likes