The local score record is recorded using the file's hash string as the key, so I think changing only the bid will not cause score loss.spaceman_atlas wrote:
it's not super easy to fix without losing people's local scores on stable.
Maybe. Something we'll look at when reimplementing bss for lazer maybe.-Spring Night- wrote:
Can this be avoided by forcing content checks when uploading a Beatmap, or by doing additional checks when the Beatmap is about to enter the Ranked queue?
Except every score replay contains the hash of the beatmap inside. Change the beatmap file post-rank to fix the beatmap ID (which will be in there for newer maps), and the hash of the beatmap changes, and thus the replay disassociates from the beatmap. And that's not the only thing retroactive action on all ranked beatmaps breaks now - trust us, we have tested this on a small group of maps.-Spring Night- wrote:
The local score record is recorded using the file's hash string as the key, so I think changing only the bid will not cause score loss.
spaceman_atlas wrote:
Except every score replay contains the hash of the beatmap inside. Change the beatmap file post-rank to fix the beatmap ID (which will be in there for newer maps), and the hash of the beatmap changes, and thus the replay disassociates from the beatmap. And that's not the only thing retroactive action on all ranked beatmaps breaks now - trust us, we have tested this on a small group of maps.
Ok, Lastly, I would like to ask, if stable is completely phased out, is it possible to fix this?spaceman_atlas wrote:
It's not as simple as changing a single beatmap ID 'somewhere in the backend' and I'm not exactly willing to go into the ugly details why at this point. We've tried the simple method in production and it verifiably broke stuff.