Senior Member
Smeg: this is 1000 heroz, not trials haha
Alvy: I was wondering about that too since rook tried to get my replay and couldn't.
Senior Member
Originally Posted by Nytmairthere i go again
Nytmair: this is Arianj, not Alvy haha
Senior Member
Damn it haha. Sorry! I couldn't remember and didn't feel like going back to check. Oops!Originally Posted by arianj
I'm still convinced that the softwares' TIMER itself measures far beyond .xxx but the database for the leaderboard, as well as the showing of the game timer is set to allow .xxx only, the database software I've used requires "rule" for such cases. Easiest being that it simply rounds things to the nearest .xxx. Since, we're NOT talking about timer on a stopwatch, we're talking about software driven timer....a limitation of .xxx seems highly unlikely to me. Since all other reasonable solutions to where to place the player in such cases have been debunked as far as I can tell....and nobody...not even a dev has given the "rule" that gives the solution....I'm going with my own answer, since it makes the most sense. Well to me anyways.
Moderator
I looked at the server code and when you open the leaderboards the scores are fetched from the database like this:
[code:2gu6z4kn]SELECT ... ORDER BY score ASC[/code:2gu6z4kn]
However, it used to be like this:
[code:2gu6z4kn]SELECT ... ORDER BY score, timestamp[/code:2gu6z4kn]
I think this was changed over 2 years ago, maybe even before the launch.
Also, there's no magic, extra/unlimited decimals or whatever. The DB software is responsible for handling the ties, but I would have to dig really deep to figure out how exactly this happens.
AnttiKi - thanks for looking into this further and responding. Based on the query that you listed, since "score" is the only column in the ORDER BY clause, the order of rows that have the same value for "score" is unpredictable. It really depends on what the query plan and optimizer decide is best at the time you are executing the query. Even if you have specific indexes in place, that does not guarantee order.
Any clue why the "timestamp" column was removed from the ORDER BY? That seems more "fair" and also adds predictability to the order.
Nice work, Anttiki! It's encouraging to know someone -was- digging around in there, trying to arrive at the truth. So if I am reading this right, the code used to order the times by the (1) score received, and in cases where the score is the same (2) by the time at which the score was submitted. A ideal situation. But it no longer reads that...instead, it now orders by 'asc'. Pardon my ignorance, but what does 'asc' stand for? ('at server's convenience?' heh.) Has the code been changed back? Or will it continue to order by 'asc'?
Also, while digging around in there, did you notice any bit of code that reads
[code:2rkghnv8]if eisegete ATTEMPTS sign in, then SCREW WITH HIM every once in a while by initiating complete shut down[/code:2rkghnv8]or something similar?
Seriously, though, thanks for the effort!
Yeah - your interpretation of the query is correct.Originally Posted by eisegete
"ASC" means "ascending". There is also "DESC" for "descending". The default for ORDER BY is actually "ASC", so that is not actually necessary to specify, but it is sometimes nice to explicitly show the direction of the order.Originally Posted by eisegete
And just to clarify, "ASC" would be:
1
2
3
...
8
9
10
And "DESC" would be:
10
9
8
...
3
2
1
Thanks for the effort on this, even if it meant that I needed you guys to "Prove me wrong".
NOW I feel pretty confident that what I was suggesting is completely, utterly, absolutely, and unquestionably NOT to be the case. Which I'm not the least bit upset about...I'm actually quite happy to get a much clearer explanation.
It's a pretty interesting topic imo....especially since its taken us nearly 800 days to come to the answer....but the fact that you guys (RL) took the time to bring us the answer speaks volumes to your commitment to your fans.
Anyone that completely "gets" it now, care to give a visual demonstration of it?
