Messages

@Duplode , please, confirm that this happens only with fast-forwarding.

It's fast play (also known as double speed) rather than fast forward, but other than that, yes indeed. Fast play doesn't actually make a difference when it comes to validation: depending on the starting frame, you'll get either the fast-forward timeline or the "main" divergent one, which are the ones checked by #4 anyway. (In this context, fast play is mostly useful for providing a way to watch the successful timeline without pausing.)

You are right, I had fast-playing in mind.

Then a question is - what is a real finish time? - because @Argammon showed very bizarre things.

I belive the sensible thing to do is to keep using the file length-based time shown by the site, which that corresponds to what the pipsqueak got while driving. The only tricky case, which should be very rare, is if the lap completes successfully in the main timelines, but neither matches the file length time. Options in that case include sticking with the slowest time, and ruling the replay invalid.

One can argue that he drove with fastest time in mind (even if that does not make sense because then a replay would finish sooner..) that's why I would like that clarified. I am also inclining to the file length/slowest time.

Fast playing an unstable replay from either the beginning or 0:00.05, depending on where the divergence point is, will lead to the fast-forward timeline.

@Duplode , please, confirm that this happens only with fast-forwarding.

A replay must be a complete lap of the circuit. Please validate your replay before uploading it, starting from "Options → Load replay". A replay is valid if it shows a non-crash frame when loaded, or if it plays from start to finish at normal speed. Invalid replays will be disqualified.

I would still add something about crossing a finish line (extended to the whole block). But maybe it is obvious for others.. Then a question is - what is a real finish time? - because @Argammon showed very bizarre things.

Thank you for your quick fix.
This one is a bit more annoying. Car coefficients in track page have fixed max-width. When track's author bonus/penalty is added and the bonus bar is overfloating then the bar is misaligned (as in this month's track).
See attachment.

Here goes the bigger post I promised on Wednesday.
...

Duplode, thank you for your insights. I would like to reply to it but I am quietly waiting for a rule change. Then we can continue with a discussion about these findings.

I am all for option 4 (maybe with a check of three independent persons).

Due to recent findings I would strongly prefer to add that a replay plays correctly from 0:00.00 or 0:00.05 is valid.

Option 5 seems to me pretty vague - I would be OK if it passes but only with the independent check.

Maybe bug - Countdown needle on the frontpage:
Maybe change

Code Select Expand

<svg viewBox="-100 -80 200 130"> to

Code Select Expand

<svg viewBox="-100 -80 200 132"> so that "May" at the bottom does not look like "Mav"?

As for legacy hardware versus DOSBox on low cycles, I think what happens is that you need to run the game on very slow hardware to eliminate the divergences from normal playback, and even legacy machines are often too fast for that. For instance, the configuration menus of DOSBox-X offer the following table of correspondences between processors and DOSBox cycles:

This is like a godsend. Thank you for sharing this screenshot. I was not sure how low should I get with CPU speed with PCem.. Especially because 286 are completely different beasts to setup from 486 which I was used to. So.. I tried to create a 12Mhz 286 machine (~1510 cycles on DOSBox) and watched my replay.

Guess what - It did not crash. So the result is the same as rewind 1.05s on faster machines..
Fritest - finishes at 1:57.85
Fritest2 - Crashed into water. Went swimming with the fishes

These findings don't support any proposed ruling directly, only showing that at slow CPU speeds Play button behaves differently than on higher CPU speeds. At best they show that rewind 1.05s(/more in case of Fritest) is the most consistent method (and the fastest) of all of them.

I was thinking in general about how deleting a replay (manually) would mess with Leading Time Bonus. I guess there is already some recomputing of leading time, isn't it?

I plan to do further analysis on these replays, as well as on the other ones shared on this thread, including running repldump on them all -- the working hypothesis being that repldump output always matches the load-from-Options outcome.

I can confirm this - I looked at Restunts' c code.
In Repldump there is the same initialization as in Stunts. (check also init lines before linked ones - they are also matching)
restore_gamestate(0);
restore_gamestate(gameconfig.game_recordedframes);
With only difference being framespersec = 20; in Repldump
vs framespersec = gameconfig.game_framespersec; in Stunts

Almost all of those thirteen replays load properly from the Options menu, and diverge when played from the beginning. The sole, glorious exception is Gutix's ACT13 replay...

This quite strongly supports my second option (relax the current rule).

The question about replay controls is an interesting one, which I think we might study by what happens around the divergence points. I'll also try to think of a specific experiment for that, probably involving an infinite powerslide track easy enough to be driven NoRH.

For that CAS has made a useful tool.
It exports Player input from the replay.
So it is easy to see what the Player did around the divergence..

This can be seen by ordinary hex editor. And in most cases input is really not interesting. And in my last race - also may vary. I think I got to 1:46:00 point by slightly different inputs.

I probably messed up something - for me fast-forwarding is producing the same result as playing.. :-/

Playing with this bug is very dependable on the setup used. So, don't be dismayed if you can't reproduce the anomaly...

Maybe or maybe not. @Friker: If you post a gif of what you did, I can tell if you made a "mistake".

Sorry, I do not know how to easily create a gif so you have captured video from dosbox as an attachement.
I am also attaching some other of my crashed replays for others who might be interested.

If I can do this on purpose, it can also happen by accident when using replay handling

What knowledge do you have when you can do this on purpose? This actually reminded me of Renato Biker.. He produced magic carpets seemingly out of nowhere..

I probably messed up something - for me fast-forwarding is producing the same result as playing.. :-/ I somehow assumed that (fast-)rewind and fast-forward are the same things.. Can someone confirm that they compute car state in different manner (something like - rewind recomputes car state from the beginning without graphics included, fast-forward computes "next frame" - same as with Play button)?

Despite recent findings I still think that only suitable validation methods (accessible and quick) are 1. load a replay, rewind to the beginning, press play 2. load a replay, rewind 1.05s, see if car crosses the finish line next frame (probably continue ride with input from replay and see if the evaluation screen shows up is more precise?) 3. repldump. If you produce a replay in which you have to rewind some, play some, then continue to finish then bear the consequence that other cannot validate it.

Also - to stay on-topic - is there more testing to do regarding choosing validation process for ZakStunts? I feel that we (especially Argammon) showed that we can screw the game engine in multiple ways and there is no true interpretation of what is the intended way (for me personally - I would disregard any graphics and use repldump/rewind functionality only but I understand that graphical presentation is also a part of the game). So - can we finalize some options what validation process to choose or do you think that we can come up with more insights on this topic with more testing (what specifically do we want to achieve?)?

Go to frame 1:46:00, press the 0.05 forward button until frame 1:48:00, and press play. The car finishes in 2:20:00 without penalty time.

This is a crash for me at 1:47:95. 

Wait, 4000 cycles, or 40,000 cycles?

4000 cycles. For me, 4000 cycles is enough to Stunts go slower and skipping some frames (hopefully only from drawing). That is the difference between not crashing (below 4000) and crashing (above 4000) of unstable replays for me.

In that first case I'm not surprised the other option is smoother, but I am surprised about how well you drive on Dosbox.

What do you mean?

Btw - maybe it is not smoother but something definitely feels different. As I have no reflexes so I cannot tell if it is input lag or anti-aliasing/graphical interface or nothing and I am just imaging things.

Hello with my daily update.. So.. I went down the line of testing with PCem as it is marketed as the most faithful simulator of late 80s/early 90s PC systems. I tried Windows 95 with Pentium 133, 100, 75, MS-DOS 6.22 with 486 50MHz, 25MHz, 16MHz. For starters - I REMEMBERED CORRECTLY THAT GAMEPLAY IS MUCH SMOOTHER THAN ON DOSBOX.. (sorry for shouting I am just excited about that. ) Even on 16 MHz it felt that inputs are simply crispier. There is Win95 with internet support so if I could set up that connection maybe I will switch from DOSBox to PCem.

Real deal - my replay crashed on all systems - even on 16MHz. So, what to say.. I spent 4 hours to install Win95, MS-DOS, test my replay and find out that MS-DOS at 16MHz is still quicker/doing something differently than DOSBox with 4000 cycles.

I still would prefer that we would agree on either 1. only fast-forwarding validation 2. both "Play button" validation and fast-forwarding validation is ok as far as there are independent confirmations on questionable/unstable replays. Option 3. only "Play button" validation is still somehow distant for my understanding of how game works (that means - I am still assuming that difference between Play and FF happens because of fast computation of something - most probably something during drawing routine).

Btw - I love that story about myself riding alongside the beach (hopefully not straight into the sea) in a fast car.

Btw2 - For some reason - on MS-DOS - Stunts produced invalid replay - marking 20th byte from the end of the replay as 01 and not 00. Now the bigger surprise for me - Stunts showed correct time in the evaluation screen. Maybe it is not surprising.. It shows that Stunts is checking car position not replay length.

@ all testing done - thank you guys. Really, thank you. I think it only shows that - if we are using Play button validation - questionable replays should be verified on different systems/choose one independent system on which we will verify and which is available for verification before the end of a race to all of us.
If we are using fast-forwarding everything replays the same on all systems and there is no difference between systems (at least PCem with various hardware simulation and DOSBox).

[unstable replays]

Now, let's define unstable replays as replays that load in a crashed state, or load in an OK state but play to a crash. Both are a thing

Ugh, really there exist replays which load crashed but replays ok? And you can continue driving before the finish line and they produce the evaluation screen? I want to see some to analyze them with other settings. Still, it seems my last comment holds true - the problem is with the Play button.