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), ...]