Replay frames should use stable sort algorithm
See original GitHub issueDescribe the bug: Not sure if this should be opened seeing as #12532 is already tracking inaccuracy involved with classic mod, but I did find that the replays are still inaccurate even when classic mod wasn’t applied/used.
The issue that I’ve came across was that the replay was “double tapping” at seemingly random places, there doesn’t seem to be a pattern to this “double tapping” but the issue is consistent and repeatable on isolated replays.
Screenshots or videos showing encountered issue:
This is one of the better examples I can put on tape as all my other replays are mostly littered with inaccurate play by myself to begin with which will probably make it very difficult for you to pick out the actual issue, but unfortunately there’s only 1 “double tap” in the entire replay which happens on the stream after 1:27 in the video. As you can see the older game version which this score was set on (2021.331.0) can accurately replay the score.
I am also attaching the replay in question so you can investigate it deeper if desired Integer playing Feint - Tower Of Heaven (You Are Slaves) (eLy) [Extra].osr.zip
This I already mentioned in #12532 but I’ll leave the clip here as I don’t really want to ping everyone again with another comment. Look for 1:20 and 2:05 in the video, note that this score is SS
osu!lazer version: 2021.424.0
Logs: I deleted the logs folder, played the 1st replay mentioned, then quitted the game network.log performance.log runtime.log
Issue Analytics
- State:
- Created 2 years ago
- Comments:14 (12 by maintainers)
Top GitHub Comments
I understand the issue now, simply both keys are pressed at once when only one was pressed in the original play, is that right? and is that the same for the other score you attached?
I don’t believe
SortedList
will fix this properly, because I don’t believe itsAdd()
method is stable wrt insertion order (as in, it does not guarantee that if the list already has items with the same sorting key, the item will be added after all of them). This is because it internally usesBinarySearch()
to find the insertion index, which does not have this property and can return the index of any of the existing items as long as the sorting key is equal (see sharplab).