RobRendell

Yup, a modpack is a way for a server admin to control when things update - they can choose when they update the modpack with the latest version of the mods that go into it, and restart the server manually so it gets the latest version. However, many mods in the workshop forbid people from repackaging them, which rules out adding them to a modpack. My suggestion would allow the PZ server itself to handle updating more seamlessly, so people don't have to come up with workarounds like creating modpacks.

Now that 41.66 has fixed the bug that characters can re-watch videos every time they re-log for infinite XP, multiplayer now suffers from this issue as well. Videos are not reset to unwatched when you die. I guess the bug being the same in singleplayer and multiplayer is a step forward?

Yes, I have the same issue in single player. The watched video list is saved in recorded_media.bin in your save folder, so as a workaround, you can reset your watched videos by deleting that (or dropping in a pristine one from a fresh game where you haven't watched videos yet). Unfortunately, the same file also contains the list of spawned Home VHS tapes, which the game uses to ensure that Home VHS tapes are unique (I guess the idea is that Home VHS tapes are recorded by individuals and there's thus only one of each in the world, as opposed to the mass-produced commercial tapes which can reasonably have duplicates). So, messing with the file could have other consequences beyond resetting your watched videos - if you deleted recorded_media.bin, you might later find duplicates of Home VHS tapes your dead character(s) already found, and if you replaced it with one from a different game, some Home VHS tapes might be marked as having been spawned which don't actually exist in the world and will never spawn. IMHO, something which is specific to an individual character (which VHS tapes they've watched and thus cannot benefit from watching again) and something that is related to the world (the Home VHS spawned list) shouldn't really be saved in the same file, even if they both relate to VHS tapes. The list of watched tapes should be reset on character death, which means it probably belongs inside the player data, where it would naturally be lost when the character dies. But if it's too late to refactor that for backwards compatibility reasons, it shouldn't be too hard for TIS to add some sort of "reset watched tapes" method to the RecordedMedia class which can be called on character death.

Currently, players on dedicated servers with multiple Steam Workshop mods suffer from the problem that when a mod writer releases an update, their Steam client will auto-download the update if they are not currently playing, after which they cannot connect to the server until the server restarts and gets the latest mod versions itself. This requires server admins to set up cron schedules to regularly restart their servers, and players will still have periods where they're unable to connect until the next restart. When you're trying to connect to a server, your client informs you which mod is mismatched, but if you're already on the latest version, there's nothing you can do other than wait for a scheduled restart. The workshop does not have a mechanism to downgrade a subscribed item to an older version, and it would require some significant changes to make the PZ server send its version of its mods to connecting clients. My suggestion: since the server is aware that a client tried to connect with a different version of a mod, it could react to this situation. The simplest way to deal with it would be to only take action if no-one is currently connected... if there are 0 players on, and a player tries to connect with a mismatched mod, the server could shut down and rely on a wrapper parent process to launch it again, download the latest mods, and carry on. The connecting player could even be given status updates of this process and the client could automatically try to reconnect once the server is up again (otherwise, they could just be told "the server is restarting, trying again in 5 minutes" or whatever.) A more involved approach could involve the server reacting to such a connection attempt even if players are connected. After pinging the workshop to independently verify that the mismatched mod(s) have indeed been updated (to prevent players triggering the response inappropriately, such as if they are the ones with the old mod rather than the server), the server could announce to connected players that it will be shutting down in 5 minutes (or some such, configurable in the server settings), or sooner if everyone logs off. After the time has elapsed, or if everyone logs off, the server shuts down and restarts as above.