Odd #1 tape for Niko Böhm's Tutorial

[BryanFRitt]

For 'Niko Böhm's Tutorial · Level 001 · Emeralds & diamonds' 'anonymous' playback ranked #1 actually has more spaces traveled on playback, and playback shows more tape time than the next 11(+?) rank scores, despite having a better time listed in R'n'D score server. There is an extra space moved that shouldn't be there in an ideal run: an extra distance move to under the 'A' in 'DIAMONDS'. When completed it shows up as taking ~8s, while the next 11(+?) rank tapes show up as taking ~7s.

? an error in tape playback,
? an error in score(s),
? an error in tape,
? wrong tape shown, (there are 8.1s and 5.85s scores on the server on this level for this 'anonymous' user)
? combination of these,
? and/or something else

Could this be related to other bad tape issues?

Tapes with Scores of 413 ...

Code: Select all

Rank 	Player 	Score 	Play Time 	Tape Date
1. 	anonymous 	413 	5.85s 	2023-02-25
2. 	RND_TAS 	413 	5.93s 	2010-10-03
3. 	amperbee 	413 	5.93s 	2024-09-27
4. 	RnD_Player 	413 	6.0s 	2022-11-20
5. 	LotB 	413 	6.8s 	2022-01-05
6. 	rebca 	413 	6.13s 	2023-05-23
7. 	aflatminor 	413 	6.13s 	2024-05-01

p.s.
How are tapes with identical scores, etc sorted?
Why is 6.8s is coming before 6.13s?
A way to show fractional seconds directly in R'n'D could be added.
Also for me, it seems, server only shows one of my best scores per level, while for others, it seems, server show more than one best score per person per level.

Possibly related files/folders/links/etc...:
Main Menu > LEVELSET > TUTORIALS > Niko Böhm's Tutorial > 001: EMERALDS & DIAMONDS
~/.rocksndiamonds/tapes/rnd_tutorial_niko_boehm/001.tape
/usr/share/games/rocksndiamonds/levels/Tutorials/rnd_tutorial_niko_boehm/001.level
/usr/share/games/rocksndiamonds/levels/Tutorials/rnd_tutorial_niko_boehm/tapes/001.tape
https://api.artsoft.org/settings/edit <== to set 'Play Time Format' to show fractions of seconds
https://api.artsoft.org/levels/view/27
https://api.artsoft.org/levelsets/view/2

[BryanFRitt]

How are tapes with identical scores, etc sorted?
Why is 6.8s is coming before 6.13s?

Looking at the list some more it seems that it's sorted by decimal representation of the time N.N (no trailing zeros) via version sort instead of like it should being sorted by the unconverted binary values of the timeframe.
(What it does when it's a tie? Does it internally go further than the two decimal places shown on the server? Then sub sort that by date/time submitted?)

[Holger]

Hi Bryan, you have definitely found a bad high score entry!

I already did some checks, and for currently unknown, but very strange reasons the automated tape check results in a time that is less than the time for the rank #2 score (therefore placing the tape in question at rank #1). But it is indeed obvious that this tape is by far not the fastest solution, and has to be removed from the first place in the hall of fame.

I still have to check what's going on here, and also will provide you with more details on how scores are sorted.

However, this problem has nothing to do with that infamous broken tape bug that I am hunting for many years now... :-/

P.S.: Regarding the question "Why is 6.8s is coming before 6.13s?", this seems to be a bug when you choose omitting the trailing zeroes from the displayed time format. If you choose to display trailing zeroes, it is "06.08" iand "06:13". I have to fix this.

[BryanFRitt]

Leading zeros, and trailing zeros don't change the value of the number.
Leading zeros are zeros that are on the leftmost of a number before the decimal place -> 001.1 is the same number as 1.1
Tailing zeros are zeros that are on the rightmost of a number after the decimal place -> 1.100 is the same number as 1.1
1.1 = 01.1 = 1.10 = 01.10 = 001.100, ...

Version sorting is sorting like a number between each '.' is integer not a decimal fraction, leftmost sub-sorted by next leftmost -> 1.1.8 < 1.1.9 < 1.1.10 < 1.2.0 < 2.0.0
Note that 1.1.9 < 1.1.10, If the 10 was treated as a .10 it would be the other way around, like it was a .1, as .10=.1 < .9

P.S.: Regarding the question "Why is 6.8s is coming before 6.13s?", this seems to be a bug when you choose omitting the trailing zeroes from the displayed time format. If you choose to display trailing zeroes, it is "06.08" iand "06:13". I have to fix this.

Oh... lol [after typing the 1st two paragraphs] I get it, you meant to say the fractional part of the time shown is wrong. Like it's showing number of (1/100)s post integer seconds instead of fractional seconds post integer seconds.* So it's not the sort order. You're saying these times should be ..., 7.00s(was 7.0s), 7.03s(was 7.3s), 7.05s(was 7.5s), 7.05s(was 7.5s), 7.10s(was 7.10s), ... . Screws up my version sort theory. Leaving version sort / adding zeros info above as an FYI for those who might might be curious.

* ? proper technical wording ?

-

from other p.s.
A way to show fractional seconds directly in R'n'D could be added.
Also for me, it seems, server only shows my best scores per level, while for others, it seems, server can show more than one score per player per level.
arg... I think I may have had something else to put here, but can't remember right now.

-

The reason I had thought it's doing version sorting instead of numerical value sorting is looking at the times and order when decimal seconds are shown
27. Burnt 412 7.0s 2024-07-19
28. marcel 412 7.3s 2023-08-31
29. Algebroot 412 7.5s 2021-11-09
30. Lele 412 7.5s 2023-09-10
31. Przemyslaw 411 7.10s 2024-05-18
#28, #29, and #30 are coming before # 31 if version sorted, even though the #31 time listed is better.
Like 7.00s(was 7.0s), 7.30s(was 7.3s), 7.50s(was 7.5s), and 7.10s(was 7.1s)
The 7.10s(was 7.1s) should come before the 7.30s(was 7.3s)
[see above (starting with oh...) for alternate interpretation, 7.00s(was 7.0s), 7.03s(was 7.3s), 7.05s(was 7.5s), 7.05s(was 7.5s), 7.10s(was 7.10s), ...]

[Holger]

Hi Bryan, you have definitely found a bad high score entry!

I already did some checks, and for currently unknown, but very strange reasons the automated tape check results in a time that is less than the time for the rank #2 score (therefore placing the tape in question at rank #1). But it is indeed obvious that this tape is by far not the fastest solution, and has to be removed from the first place in the hall of fame.

I have finally debugged this problem, and solved it!

It is a bug in R'n'D that only happens if a final tape has a time that is a multiple of 50 frames -- in this case, a wrong score and a wrong time will be send to the high score server!

This bug is fixed now in the new R'n'D version 4.4.0.6 (released yesterday). However, you do not need to update (and many players maybe won't do either) to make sure that all past and future scores are correct now, as I have also changed the score tape checking code on the high score server to handle this edge case correctly even for broken scores and times now. All existing scores that were affected by this problem are fixed on the high score server, too!

So all scores and times in the hall of fame (including the resulting ranking of players) should be correct again!

and also will provide you with more details on how scores are sorted.

Not sure what I wanted to tell you here, but scores are sorted as follows: Highest scores first, and, if scores are equal, those scores first which have a lower time (in frames). If all is equal, the older score will be higher than newer ones.

P.S.: Regarding the question "Why is 6.8s is coming before 6.13s?", this seems to be a bug when you choose omitting the trailing zeroes from the displayed time format. If you choose to display trailing zeroes, it is "06.08" iand "06:13". I have to fix this.

This is fixed now, too: The wrong "6.8s" will now correctly be displayed as "6.08s".

Thanks a lot for reporting these really nasty bugs with high scores!

[Holger]

P.S.: What I want to fix next is the "problem" of several same names appearing in the high score lists for many levels, with the most prominent example of several "anonymous" entries in many high score lists. This is due to the fact that the player name is internally tied to an ID, so you can change your player name, and it will affect the player name of exactly your own scores (so if you have played as "anonymous" for a while, changing that name to something different will affect all your own score entries, but only those, and not all other players with the same "anonymous" name).

"anonymous" is the default name when playing in the Android and browser versions, while your login user name is the default name when playing in the Mac, Windows or Linux version.

But if you play the game on two computers with the same login user name, different IDs with the same user name will be used, resulting in multiple same user names in high score lists (if that level was played and solved on both computers). This does not look nice (as usually only the personal best score is shown in the high score list), so I will change this to only show unique user names in high score lists in the near future. (Renaming a "duplicate" name should then result in both scores with now different player names to be displayed in the high score list again.)

[filbo]

Regarding the solution to multiple scores with the same name:

It seems like there must be lots of cases where local usernames have been used and are duplicate, but aren't the same person; i.e. local username 'John' or whatever. So this solution will brush together a certain number of scores which actually ought to be distinct.

... but I don't really see any way around it. 'Same name' entries in a single score list could be visually tagged with their internal IDs, for differentiation; but then it's back to lots of duplicates caused by same-player-different-host. Dunno.

[Holger]

Yeah, it's really tricky (and a result of my approach to not require a unique "login" style account name).

It seems like there must be lots of cases where local usernames have been used and are duplicate, but aren't the same person; i.e. local username 'John' or whatever. So this solution will brush together a certain number of scores which actually ought to be distinct.

Yes, exactly. For example, there are several hundreds of different users with the name "michael" on the score server.

... but I don't really see any way around it. 'Same name' entries in a single score list could be visually tagged with their internal IDs, for differentiation; but then it's back to lots of duplicates caused by same-player-different-host. Dunno.

Yep, quite a number of duplicate entries may simply have been caused by people setting up a new computer, re-installing R'n'D again (but _not_ copying the program data folder to the new computer), and going on playing with their old, same player name (but now using a different unique ID). Or simply playing on more that one device in parallel.

For example, when looking at the high scores of classic "Niko Böhm's Tutorial · Level 001", there are two entries for "ncrecc" and two for "algebroot", which are most likely the same person. Then there were numerous entries for player "anonymous", which are most likely different players playing on Android or web browser (using the default player name of these devices).

(There is only one entry "anonymous" left now, as new entries for a given name already cause making sure that the same name only appears once in the high score list. This will be reset also for all other names soon.)

Finally, I plan to add a hook that makes it possible to rename your non-unique player name (like "anonymous" or "michael") not only in the game, but also for all existing score entries. So if you have a score as "michael" in the top 100 list, which is not shown due to another "michael" with a better score, renaming your player name to some other unique name will cause your score to be shown up again in the high score list, with your newly selected name. Hope that makes sense...

[BryanFRitt]

Yeah, it's really tricky (and a result of my approach to not require a unique "login" style account name).

Finally, I plan to add a hook that makes it possible to rename your non-unique player name (like "anonymous" or "michael") not only in the game, but also for all existing score entries. So if you have a score as "michael" in the top 100 list, which is not shown due to another "michael" with a better score, renaming your player name to some other unique name will cause your score to be shown up again in the high score list, with your newly selected name. Hope that makes sense...

Adding a non-uniqueness count showing the user how many other unique IDs have the same player name might help. Like if there's only 1 other unique ID with the same player name, and you have another computer with R'n'D the same player name, then you know it'll be unique to you.

Currently, the name / team name of a player can be easily set right at the top of main R'n'D page. There could be a pop up on name changes stating the non-uniqueness count.

Although, I could imagine this being scary/confusing to some players especially without given some idea of what this is and used for; and lots might not care enough to bother messing with it.

Is showing multiple users with the same name that bad that the high score list needs to be shortened? For best scores, (only best per unique id as an option, ) showing names for the unique id would probably be good enough for most people.

[filbo]

Is showing multiple users with the same name that bad that the high score list needs to be shortened?

I imagine it means most leader boards are chock full of 'anonymous' over and over :)