search

ppy / osu-web

the browser-facing portion of osu!
https://osu.ppy.sh
GNU Affero General Public License v3.0
978 stars 382 forks source link

Beatmapset playcount doesn't match beatmap playcounts after update #8875

Open cl8n opened 2 years ago

cl8n commented 2 years ago

when a map is updated, its beatmap plays/passes/fails are reset to 0, but the beatmapset total isn't reset, so they get out of sync. I think it'd make more sense if the set total always reflected the sum of its (not deleted) maps

and it may be a good time to re-assess whether or not these stats should reset on update at all. it's come up in Loved a few times now because beatmap playcount can be a quick check for how popular each diff is, or each game mode in a multi-mode set, but the timing of mappers' updates can make it unreliable. I also get some confused messages from mappers who didn't expect an update to reset their playcounts

example: https://osu.ppy.sh/beatmapsets/817308

peppy commented 2 years ago

The problem with not resetting is it opens the system to weird edge cases, like a user uploading a completely different beatmap in place, and retaining statistics that shouldn't be there. Curious to hear further thoughts on this kind of case.

downpour-osu commented 1 year ago

My thoughts are that's exactly what the GMT is for... We shouldn't destroyed the loved subsystem over edge cases.

Walavouchey commented 1 year ago

maybe an admin-only way to update a map without resetting its statistics would be a way to go about this in the case of loved, while also preventing any abuse

peppy commented 1 year ago

Destroy the loved subsystem what? Please provide context.

downpour-osu commented 1 year ago

I have a beatmap with like 41k plays since graved playcount was implemented (along with 200+ favorites). On loved.sh, score, which is a combination of favorites and playcount, is calculated using sum of beatmap playcounts not beatmapset playcount, which according to clayton, resets on update, even though the number visible on the website does not change. Thus, when I updated a map that I was trying to rank for a second time and ultimately failed to rank, I destroyed its chances at a loved nomination by tanking its score into the ground by erasing its score on loved.sh

Since there is an official "ranked reject" category on loved, this seems quite a bit short sighted. Clayton said to me in discord that it may be confusing, but he can't fix it without this. Please don't let other mappers torpedo their own maps accidentally anymore. It's too late for mine, but it's an awful feeling. Please let the GMT handle edge cases so that map score isn't erased for hardworking mappers :/

furiner commented 1 year ago

I agree with proposing that beatmapset playcount totals should always be a fixed sum of the playcounts for beatmaps it contains, because this would remedy the issue of the fact that it's inconsistent with each beatmap, and avoid having to "reset" it altogether.

cl8n commented 6 months ago

sorry I never followed up on this one, at least not here and I don't remember if I wrote something elsewhere :thinking:

The problem with not resetting is it opens the system to weird edge cases, like a user uploading a completely different beatmap in place, and retaining statistics that shouldn't be there. Curious to hear further thoughts on this kind of case.

I don't think the impact of this is significantly different with the changes I'm proposing. arguably the most important and most referenced statistic here is the beatmapset playcount, which already does not reset on updates. moderators should continue to address (or not address) these cases however they currently are, because room for confusion is already there

as for pass/fail rate and failtimes, I can understand wanting to reset those on every update since they are potentially meaningless at that point... only problem is they currently depend on playcount as well (pass rate = passcount / playcount) so I guess it would have to be completely detached in some way. also, I just discovered that failtimes don't reset on updates, so this has been wrong all along :smiling_face_with_tear: and also converts are polluting pass rate in some way due to increasing, at the very least, playcount :smiling_face_with_tear::smiling_face_with_tear: seems like a rabbit hole...

Destroy the loved subsystem what? Please provide context.

I probably could have made this more clear, but the only reason I mention Loved is that as an API consumer, this issue makes beatmap playcounts difficult to meaningfully use. for the purpose of this issue there's no need to care about all the details of how Loved works and it's my fault that my project can behave in a weird way because of this (it's also not that dire like downpour is making it seem though lol, which is why I still haven't done anything about it...)