LordGolias / antistasi

Antistasi improved, a mod for the game Arma 3.
BSD 3-Clause "New" or "Revised" License
30 stars 18 forks source link

Improve save games in dedicated MP #174

Closed LordGolias closed 6 years ago

LordGolias commented 6 years ago

As I see it, there are 3 main types of people playing:

In MP, the host is not necessarily the commander, in dMP the commander is not necessarily a server admin.

Existing functionality:

(Equal for SP, MP and dMP)

  1. The first commander in-game decides which game to load on init (from its profile)
  2. The commander can save a game
  3. Games are saved on the commander's profile
  4. Saved games are broadcasted and copyToClipboarded on every client.

Problems with existing functionality:

  1. clipboard does not work in MP and dMP by the Arma engine (issue #52)
  2. on dMP, saving the game to the commander's profile only is not good enough because the commander may not be available when the server restarts.

When the commander saves the game, it has the power to overwrite existing saved games. If the game was saved on the server's profile, a malicious player as commander could overwrite saved games on the server. For this reason, the commander must not be allowed to change the server's profile nor other client's profiles. (@jlillis, this is an issue in your proposal)

There were 2 main reasons for the use of the clipboard functionality:

  1. to allow friends in MP to continue the game without the friend that was the commander the last time
  2. to allow people to share saved games (copy to a file, send the file, copy from the file)

Because of problem 1, the clipboard functionality is de-facto useless because, for the person p1 to share a MP game with p2, they would have to

  1. p1 save the game in MP
  2. p1 load it in SP
  3. p1 copy to clipboard and save clipboard on a file
  4. p1 share file with p2
  5. p2 load it in SP
  6. p2 save it
  7. p2 load it in MP

Proposal of fix dMP problem

The root cause of problem 2 is that the commander is not necessarily an admin, and saved game management of the server should be handled by server admins only.

Thus, problem 2 can be fixed by decoupling the commander's in-game permissions (buy FIA vehicles, etc.) from the commander's save management permissions (load/save games). Specifically, I propose the following save game permissions:

jlillis commented 6 years ago

I think we should treat dedicated and self-hosted MP games the same - the host is automatically an admin in multiplayer. In other words, the save game functionality is for server hosts/admins, not the commander (unless it's singleplayer).

For automatic saves, I think adding a checkbox to overwrite the most recent save every x minutes would be good - as well as displaying what the current save slot is, and when it was last modified.

LordGolias commented 6 years ago

I think we should treat dedicated and self-hosted MP games the same - the host is automatically an admin in multiplayer. In other words, the save game functionality is for server hosts/admins, not the commander (unless it's singleplayer).

So, the persistency belongs always to the persistent machine (dedicated or host). Sounds better.

This change does not break backward comp of saved games: it is only a change in permissions. This is also good.

Do you want to tackle this part, @jlillis?

The save game last modified date also addresses #165. I think that this requires some more changes because the save date should not be part of the serialized game, and instead should be a property of the save game itself. I.e. in the relational database sense, IMO a save game contains 3 fields: