Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
22 of the results ends in 26 or 76 (which are 50/1000 apart).
There is no way this can be random. My current time is
02:54.676 , and my previous time was
02:55.076
I have also had 92 repeating in my own times.
42 and 92 is repeated 32 times in the top 100. (which are 50/1000 apart)
09 and 59 is repeated 25 times (which are 50/1000 apart)
I have seen this in DR1 also. With my own times, where some numbers gets repeated
way beyond random.
Something seems wrong, which would not be a surprise..
EDIT:
Added 1 more group. What is obvious is that the repeating numbers in each group is 50/1000 apart.
This is most likely indicating that time is the max you can do with your current skills (and, well, for that setup), even considering you do a bit better here and there sometimes, you also screw here and there too and the time remain about the same or exactly the same.
Make videos of your driving, take to Youtube and put video side by side of each try and compare if turn by turn, inch by inch, you are really doing at the exact same times.
Also, the game tells you the difference after each sector too, check if the difference is 0.000 through sectors.
That is not what we are seeing here. Having 3 groups of 2 digit numbers from 50 to 100 different players is way beyond statistical random. 80-90% of the results have one of these numbers:
26 and 76 - 0.050 seconds apart
42 and 92 - 0.050 seconds apart
09 and 59 - 0.050 seconds apart
Sometimes you find over 100 players within 0.100 second apart and not even top 500.
It ... Just happen.
There are 94 more numbers than never or hardly ever occures in the top 100.
How do you explain that.?
When I'm practicing, I can predict that the next time I get will end with
26, 76, 42, 92, 09 or 59. No matter what. Do you understand how
impossible it is for the splitimes alone to always add up to those 6 numbers?
(Which btw they dont!) My splittimes are always different.
And no, you NEVER find 100 players within 0.1 second! But even if it did, that is not what
is seen here, Even if 100 players were within 0.1 sec of each other, they could still all have
different times, since that are 100/1000 in 1/10... So it woud still be very odd if most of them ended with mostly 6 different numbers,
If so, most of those players would have the same time. If spread evenly out, about 15 players
ending in each place. 15 players at 1st place, 15 players at 2nd place, 15 players at 3rd place aso.. Never seen anything like that...
Sure you do. There are leaderboards all over the genre with 1000's of drivers separated by 0.01 of a second. F1 games are notorious for it. Forza has it in spades, where people using identical setups end up with same times. Gran Turismo again has it, even to the point where they have had tied times in events. Plus people use Ghosts on track to copy lines, which makes repeat times even more prevalent from identical duplication.
When you have over 500,000+ people doing the same thing, over and over and over again there is always going to be extremely close times. There is no tin-foil hats required. It is what happens when people compete with near identical hardware. What you are seeing is the limit bands, where hardware and skill are comparable. That is entirely normal and extremely predictable.
Disclaimer: I do not know the inner workings of Dirt Rally 2.0, EGO Engine or Codemasters. This is just my hypothesis.
I have analyzed several time-trial leader boards and found a few familiar things. As discussed above, a pattern emerges when comparing times on the Sweden - Älgsjön Sprint, R5 leader board. However, this pattern does not appear to be consistent across all leader boards. I am comparing data in the "DIFF" column of the leader board, not the "STAGE TIME" column. This is to eliminate any potential initial offset.
The observed pattern can be defined as follows. For any entry (DIFF), convert the time to milliseconds. For example "+00:03.683" becomes 3683 ms. Divide 3683 by 16.666... (recurring) and the result is 220.98. Note that 220.98 is almost 221 (a whole number): this is key. The number 16.666... is also key. Do this division for any entry and the result is always very close to a whole number, that is, the decimal value is close to zero. There is some inaccuracy, likely due to rounding errors. It is clear that every entry is a multiple of 16.666... This has some strong implications.
This game most likely uses deterministic physics. What this means for the user is consistency. Under the hood, this means that the physics (including the measurement of time) are calculated independently of frame-rate. It would appear that the physics are updating at 60 hertz, which is very common. In terms of milliseconds, 60 hz is 1000/60= 16.666... Again, this is independent of frame-rate. This has nothing to do with playing the game at 60 FPS, nor 30 or 120. This would explain the pattern, but things are often not that simple.
Of course you would want to measure time more accurately than in increments of 16-17 ms, preferably down to a single millisecond. The good news is that, not only is this possible to achieve with deterministic physics, but it can be extremely accurate, even at 60 hz. This is the reason why you always see speed-runners of any game use game-time rather than real-time when provided, even for old games. The bad news is that things get complicated. The extra accuracy needs to be calculated somehow, in-between the individual update cycles.
What may be happening is that the sub-16 ms accuracy calculation fails. Perhaps some finish lines do not register properly, and others do. Bugs related to physics are common.
In conclusion: is there a reason to panic and assume that all leader boards can no longer be trusted because they are inaccurate and therefore invalid? Personally I would not draw this conclusion. Your times are probably off only by a few milliseconds, on some stages.
We are talking about rally here :p Theere are no such thing as 500.000 people running a stage.
I did not want to nag about it, but if all these times was within 0.1 second, it would actually be even more mysterious if 80-90% of the times was ending with those 6 numbers for hundreds of players. Something is off. Period.
Interesting. How does this explain how these numbers adds up in pair, 0.05 sec apart?
Have you also noted that times seems to be calculated in 0.0001 secs?
If you add split times, they very often are lower than the resut from the game, implying that numbers are rounded up.
Multiply 16.666... by 3 and you get exactly 50 ms (0.05 seconds), so it is effectively the same observation.
Internally, time is not even stored in terms of seconds. It is stored in terms of number of elapsed physics ticks. This is then converted at a later time for display, with minimal error. This allows for accuracy much greater than even a millisecond.
As for your last point, I assume you are saying that your split times total something less than the final stage time presented by the game. I have not looked into this, but if it is a small amount then it sounds like this is simply a rounding and/or conversion error.
Each displayed split time has some conversion error. When you keep adding multiple errors together, it worsens increasingly. However, this should not be occurring internally, so you are not actually comparing the same thing. You are comparing the final time (which has some error applied to it only once) to multiple split times (with errors added up for each split). In other words, your manual total is less accurate than the actual total. This is expected.
From what I can tell, the developers have done everything right when it comes to timing, except for the one potential bug explained above, which is not a big deal in my opinion.