Most players who want their changes saved will not invoke /save-off, except in the course of a backup. If they forget to re-enable saving then...the backup process is doing it wrong and already jeopardizing loss of data given there are tons of ways that a process can be killed. It seems like you're advocating for a safety net in case these kinds of processes are not tidying up as they should be? But consider a backup that hasn't turned saving back on and the following circumstances...
host machine is rebooted
host machine loses power
etc, etc
These are the equivalent of a SIGKILL, and will be problems for backups no matter what. Backup processes should do the right commands.
It's not good form to have another command having magic, undocumented functionality to guard against behavior like forgetting to turn saving back on. At the very least, the documentation for /save-off should be amended.
Best? /save-off works as described and has no side-effects. There's actual use cases for this like running a pvp day on a server that is normally pve and letting people go wild on each other's creations or loading up special mods for an event day that no one wants persisted to disk.
I shouldn't have to login to my host (which I may not have access to a shell to do) and send a SIGKILL. Instances where someone may not have access are due to hosting provider or someone is an operator level 4 but doesn't have shell access to the host.
As someone managing a cloud VPS for a server, I would /never/ give shell access to anyone but myself, period, but I do want to allow other operators who might be throwing events while I'm unavailable, etc to do the above.
This is a bug. You are able to bind alt+<key> and then it does not work. It fires both <key> and alt+<key> bound actions. So this is not a feature request.
fuzzyweapon
Re: Stabel, this is confusing.
Most players who want their changes saved will not invoke /save-off, except in the course of a backup. If they forget to re-enable saving then...the backup process is doing it wrong and already jeopardizing loss of data given there are tons of ways that a process can be killed. It seems like you're advocating for a safety net in case these kinds of processes are not tidying up as they should be? But consider a backup that hasn't turned saving back on and the following circumstances...
host machine is rebooted
host machine loses power
etc, etc
These are the equivalent of a SIGKILL, and will be problems for backups no matter what. Backup processes should do the right commands.
It's not good form to have another command having magic, undocumented functionality to guard against behavior like forgetting to turn saving back on. At the very least, the documentation for /save-off should be amended.
Best? /save-off works as described and has no side-effects. There's actual use cases for this like running a pvp day on a server that is normally pve and letting people go wild on each other's creations or loading up special mods for an event day that no one wants persisted to disk.
I shouldn't have to login to my host (which I may not have access to a shell to do) and send a SIGKILL. Instances where someone may not have access are due to hosting provider or someone is an operator level 4 but doesn't have shell access to the host.
As someone managing a cloud VPS for a server, I would /never/ give shell access to anyone but myself, period, but I do want to allow other operators who might be throwing events while I'm unavailable, etc to do the above.