Leaderboards in milliseconds need better precision

[suXinjke]

The Time (Milliseconds) format right now is formatted to two digit precision like 1.23 instead of 1.234 , which I guess actually corresponds to Centiseconds format specified in RAIntegration and relevant codebases - which is also misleading.

This can be rather bad for certain games. I recently did regular "less readable" Score format for Gran Turismo 4 leaderboards exactly to preserve the millsecond precision.

The Time (Milliseconds) should be renamed to Time (Centiseconds), and actual new Time (Milliseconds) format should be introduced.
And I see that would require lots of work: rcheevos, RAIntegration, existing emulators, RAWeb

If all of that gets implemented, some leaderboards may want to update their results, I believe it's trivial database queries but still requires care to avoid screwing up:

Value	Display	Note
101	1.01	As centiseconds
1010	1.010	Multiplied by 10, now as millseconds
1020	1.020	Incremented value above by 10. If leaderboard logic took a value of 1.019, divided it by 10 to convert it to centiseconds, then it'd be unfair to keep it as 1.010 because it's by 9 milliseconds faster than it originally was.

[Jamiras]

Fixing the label was recently done in #1162. It'll be deployed with the next release.

[CookiePLMonster]

For what it's worth, time display in emulators could be trivially hacked by using tags in leaderboard descriptions telling the emulator to apply custom formatting to the entry, but no matter what this will change nothing on the website itself.

[suXinjke]

Ideally if rcheevos wouldn't allow math logic on value submitted, then all the RAWeb could do is to specify "presentation formula" to represent that original value.

You know, bandaid solution could be to implement this feature anyway, and keep it exclusively to the website.

[CookiePLMonster]

Still needs a differentiator on integers and floats, but otherwise I agree.

[CookiePLMonster]

I'll bump this discussion - are there any obvious blockers from this being added? I suppose updating the existing boards may be a risky operation, but adding a new display format to the website and rcheevos itself shouldn't pose any risk whatsoever.

[Jamiras]

The biggest hurdle is probably just the naming itself. Despite all the player-facing changes to correctly call it CENTISECS, it's still MILLISECS in the database/API.

> SELECT Format, COUNT(*) FROM LeaderboardDef GROUP BY 1 ORDER BY 1;
+-----------+----------+
| Format    | COUNT(*) |
+-----------+----------+
| MILLISECS |     8457 |
| MINUTES   |       61 |
| SCORE     |    11122 |
| TIME      |    18604 |
| TIMESECS  |     3659 |
| VALUE     |    26681 |
+-----------+----------+

[CookiePLMonster]

The API would at least be backwards compatible, because a renamed enum would still have the correct index, so old rcheevos would "correctly" request centisecs when it's asking for millisecs. Or are those requested by a string name? Unlikely.

[Jamiras]

They're strings in the DB/API

  `Format` varchar(50) DEFAULT '',

  "Format":"MILLISECS",

They don't get converted to an enum until rcheevos processes the response.
https://github.com/RetroAchievements/rcheevos/blob/8a717b1b303be636213a3e6612b059c1c0e98102/src/rapi/rc_api_runtime.c#L287

[CookiePLMonster]

I see, so that is a potential compatibility issue - if the current MILLISECS entries get converted, old clients will start showing values 10x too large, and if they don't get converted, they never end up being truthful. Tricky...

[CookiePLMonster]

If nothing else works, maybe the PHP route is the least bad solution? REAL_MILLISECS for a new data type, and have the current one be a deprecated alias of CENTISECS.

It is horrible, but probably best for backwards compatibility.