Simulate plays

[jxu]

I wonder if it is within the scope of the project to simulate replays, or if it should go into a project built on top of slider. The idea being the ability to detect sliderbreaks and determine the scores of buggy replays, ex. off the top of my head, Gayz's score on The Ghost of 3.13 https://osu.ppy.sh/scores/osu/2094347618 was notorious for appearing to combo break on some clients back in the day.

[llllllllll]

Depending on the scope, I think this could definitely be a good addition to the replay API. I haven't looked into detecting slider breaks; however, I have some code for converting a vector of "clicks" into a vector of scores: https://github.com/llllllllll/lain/blob/8fd2ceafc64dddf51668f316493ef7f3a7432e05/lain/error_model.py#L714-L733. Right now I am not accounting for clicks that occur during breaks or that are too far away to matter. I think it would be a nice addition to the Replay object API to provide a (score, combo-persisted) for every hit object so that users could reconstruct the score. I think anything like rendering the play or more advanced than getting the raw data might be better in a separate library which can pull in more complex dependencies for those things.

[Liam-DeVoe]

am I misunderstanding or isn't the heavy lifting of this already done by Replay#hits (which already does sliderbreaks)? Once you have the judgments, you can reconstruct the combo and score fairly easily I would imagine.

[llllllllll]

Oh, thanks for pulling that up, I totally forgot we have that. I think that is basically what I was thinking.

[jxu]

Oh I didn't even know that existed

[blimmo]

I wrote this code quite a while ago so my memory is fairly hazy but I don't think it was ever that great at detecting slider breaks. At the time I thought that the problem was with the distance that the cursor can move from the slider while still counting as being on it being wrong: the value I eventually used was 3 times the circle radius (I think from lazer code) but I still kept getting errors. Now I suspect that there was another problem that I was misidentifying.

Also the api was pretty heavily influenced by what I was using it for so I made a PR to improve it but since there didn't seem to be much interest (and the identification wasn't working properly anyway) I never finished it.

Anyway if you want to try to improve the identification I'd be happy to answer any questions.

[jxu]

ok I guess the issue should be simulate plays correctly

[kpei]

@blimmo old bump but did you ever figure out what the issue was for the wrong slider break identifications? I'm also noticing discrepancies for 100s as well

[blimmo]

Nope, sorry! I haven't touched this in a long time so no news unfortunately. I'd definitely recommend looking at the lazer code if you want to try debugging it: when I wrote it originally I reverse engineered a lot of the calculations because I didn't realise lazer existed so rewriting it to more closely follow how lazer does it would probably give better results (pretty sure lazer handles slider breaks and stuff the same as standard though I might be wrong)

[kpei]

@blimmo makes sense, will go from there. I went through the slider processor yesterday and one example that I saw is that repeated sliders aren't being accounted for (the path back and forth).