When working on code that needs to run on server shutdown, I waste a lot of time waiting for studio’s shutdown deadline when stopping Play Solo. But most of the time I don’t need the deadline to be that large - sometimes it would be totally okay for the shutdown deadline to be only a second or two, enough for my code to log some values and that’s it.
Having a longer shutdown deadline also makes it more difficult to get useful information from the output, because if any logs are being printed at high frequency (e.g. once every frame) then the shutdown deadline will always force 3000+ of them to be printed which is just creating unnecessary clutter and making it more likely that useful information will get deleted due to the output history limit.
Also I often end up in situations where I unexpectedly have to wait for the shutdown deadline, and so may not have had the foresight to do things like turn of the BindToClose code (or change a shutdown deadline setting if that feature ever gets added).
For example, I am quickly testing a situation where I wanted to break all DataStore requests in my game, but forgot that that would also cause studio to hang for 30 seconds or whatever waiting for the shutdown deadline.
The core of the issue is that shutdown deadline is just painful to deal with. It completely hangs studio, and there’s no option to speed it up if you know you don’t care about hitting the full shutdown deadline.
Having a nice big panic button “I don’t care about waiting, just shutdown everything immediately” would be useful to me. Being able to change the shutdown deadline would be helpful as well, but as I said above it requires foresight which I don’t always have.
If your game has code which is specifically set up to run on server shutdown, it will prevent studio from stopping a Play Solo test until the code has completed. The shutdown deadline is studio’s way of automatically preventing you from getting stuck forever (if your code happens to be broken or requests keep failing or whatever) by just forcing everything to stop after a set period of time. I think the deadline is about 30 seconds or something like that right now. But it’s usually very annoying to deal with.
No. I need to test data saving code. I need to test as many codepaths as possible to make sure there aren’t bugs. And the long shutdown deadline is especially frustrating in the scenario where I am trying to debug problems with data saving code (or other things that need to run on game shutdown), as it wastes my time and makes me think harder about how I choose to print debug information.
I’m still quite confused about what the ideal behaviour would be. The ‘deadline’ is defined by how long your code yields on BindToClose, yielding for less time decreases the hanging time. I could only assume that running this code after Studio has been restored to it’s pre-running state could have unintended side-effects.
I am not aware of any settings for this. There is the “Script Timeout” setting, but that’s for normal runtime script execution and is only 10 seconds (instead of the 30 seconds I observe with the shutdown deadline).
That’s not correct - the thing I am talking about (the deadline) forcibly stops the execution of all code, and is completely unaffected by what your code does. It’s a fixed time limit. All I want is a better UX for managing when this force stop occurs, instead of being stuck with 30 seconds of studio hanging every time.
Long BindToClose yields are actually correct and normal behavior of server-side code, as that is necessary for things like saving data and making network requests when the game is shutting down. Even if the long yields are from bugs in your own code, the BindToClose behavior itself is still a real component of the engine.
So I do not want to eliminate the yielding entirely. Instead I want studio to give me better tools for avoiding unnecessary long hangs when I know that I don’t care if the server code is still yielding.
This feels like an A/B problem, where you don’t actually want a timeout. What you really want here is an easy way to choose whether to continue waiting, no?
What would you think if pressing the stop button an additional time cancelled the onclose handler and forced immediate shutdown?
A better general feature request (unless if I’m misunderstanding this) is for a play session to clean itself up in the background - letting the developer immediately get back to the main studio interface and work on / fix anything they encountered during the play session. Studio could ‘grey out’ the test buttons, so you can get back to the main studio window - you just won’t be able to hop into another session until the server and client(s) closed.
Usually for this I just avoid doing anything intense in BindToClose (if I can) in Studio, and just accept the fact that data may have a super duper slim chance to not save (only affecting me).
If it was something like this, then I feel that could help satisfy your request but also many cases that I (and I assume others have) where we need to quickly exit the play session to adjust something so we can hop back in without having to wait as long. This could save a lot of time since I’m always going in and out of play mode, and if some of that closing time could occur in the background, that’d be sick.