Multiplayer room creation flow succeeds when an online beatmap was locally modified

[bdach]

By which I mean the following scenario:

1. Open multiplayer
2. Select a beatmap that has an online ID, but was locally modified
3. Click "create room", creation succeeds
4. On entering the room, the playlist item will show a download button (even though the item was just chosen from the local collection)
5. If you try to add/select the item again via "add/change item", spectator server will respond that the beatmap was modified

Kind of not sure where this should go really. Room creation is handled by web and the room creation request does not include the hash of the map, just its online ID. And so there's not much that can be done in spectator server because if the online ID is valid, then that looks as if the user just chose the unmodified map.

Plausible solutions:

1. Move room creation to spectator server and add local check there
2. Send beatmap checksums in room creation request and verify web-side
3. Add a client-side check against the beatmap having an online ID but non-matching hash when compared with web

[smoogipoo]

Not sure if this is an actual issue or whether the server should allow you to pick modified items via add/change too. So long as the server is authoritative on the hash.

[peppy]

If we're allowing modified, we need to support it fully (ie. the client should be aware that downloading the beatmap will not work, and not show the download button). Safest path for now is to not allow.

[smoogipoo]

the client should be aware that downloading the beatmap will not work, and not show the download button

What do you mean by that? That's currently what happens - if you create a room with a beatmap that's been modified it'll show the download button and allow you to play it after redownloading.

[peppy]

The issue in this thread is the host creating a room with a modified beatmap. In which case, a user playing in the room would see the download button, download but would still be unable to play.

[smoogipoo]

In which case, a user playing in the room would see the download button, download but would still be unable to play.

This is not the case - it will work after redownloading. When creating a room the hash isn't serialised at all, but the multiplayer server will populate the hash directly from the DB to give back to the clients (via MultiplayerPlaylistItem).

The difference is that when adding/changing an item, the hash is serialised, so the multiplayer server rejects it. I'm saying it could not and instead overwrite the hash sent from the client, and pass back the correct hash.

[peppy]

right, that's very hidden behaviour...

so this is just a UX issue then. probably want to allow the same thing when selecting a beatmap (that has an OnlineID) - server authoritative on the hash.