Topics

Very good racing around the park, beginning with the Oxia in the first week, and now with the Indy!

While the schedule of live races may have slipped a bit since last year (these last few months have been very busy for many of us), there's still plenty of time to set up a nice live racing session in the second half of the year! I know, for instance, that both @alanrotoi and @Erik Barros have ideas for events; also, I would be happy to host a race as well (ideally closer to the end of the year).

Might as well make a poll this time!  The context:

@ Herr Nove, I will add a new color after the public days making it even more colorful 

I am not surprised that @ Argammon is going to hide the secret sauce he's preparing with a (I guess) blue car.

Audi or Mercedes? 🤔 This is not the first time the Audi Quattro runs along one of the DTM cars. In ZCT217, for instance, the Audi Quattro and the BMW DTM stayed at close quarters for pretty much the whole race.

Speaking of projections, the PTB update at the end of public days (and 360 hours from quiet days) has just been posted. While having half a dozen pipsqueaks in contention for PTB +1 is a pretty realistic scenario, only Frieshansen has a chance of reaching PTB +2 (margin at midnight: 31:44).

A minor update (way more minor than the ones by @dreadnaut in last year's thread): in the sent replays stats page, the bar chart for specific races now includes days before the official start (a common case being the Sundays when a track is posted), and subtly highlights the days in which the different phases of the race begin (official start, non-public days, and quiet days).

Just an idle thought: "live race" is an established term in our jargon, but is there a reasonable word or expression for the opposite of that -- that is, a race with a deadline measured in days rather than minutes, in which people send replays in their own pace? The first thing that comes to mind is "monthly race", but that doesn't always apply -- the race could be weekly, biweekly, etc.

This track is an amusement park!  So many different lines to try, with the various cars offering wildly different rides.

Would you like to join a team, move team, or start a new one? This is the place to discuss and look for friends!

This is also a good place for lineup confirmations, available seat announcements, and transfer rumours  (cf. last year's thread.)

New thread for the guest tracks! (see 2024)

Want to design a competition track? Book your race below.

Tracks for the competition are designed by its participants. If you have an idea for a track and would like to contribute, just choose an available month below!

Some notes about the calendar this year. The dates in the list below are submission dates, following the procedure set by @dreadnaut last year in which tracks should be sent one week before the race start, to make sure there's time to catch any pitfalls. I'm assuming the season will start on 12 Jan. The calendar might have to be shifted one week forward; we'll let you know if that happens. For the first race, since the planned submission date is four days from now, some extra leeway will presumably make sense.

• ZCT282 (submission by 10 Jan) - @Argammon
• ZCT283 (submission by 2 Feb) - @Duplode
• ZCT284 (submission by 2 Mar) - @alanrotoi
• ZCT285 (submission by 30 Mar) - @Cas
• ZCT286 (submission by 27 Apr) - @Erik Barros
• ZCT287 (submission by 25 May) - @Overdrijf
• ZCT288 (submission by 22 Jun) - @Shoegazing Leo
• ZCT289 (submission by 20 Jul) - @Frieshansen
• ZCT290 (submission by 17 Aug) - @alanrotoi *
• ZCT291 (submission by 14 Sep) - @dreadnaut
• ZCT292 (submission by 12 Oct) - @Zapper
• ZCT293 (submission by 9 Nov) - @Mortimer Macmire

* If you aren't on the calendar yet and would like to have the ZCT290 slot, just let us know!

[position time bonus]

In this post, I will sketch a possible implementation of a position time bonus system for ZakStunts, in the context of the discussions about LTB (leading time bonus) reform started in the 2024 pre-season that we're revisiting now (cf. the Cars and rules for 2025 thread). Position time bonus is a way to expand LTB to further positions on the scoreboard. The idea originates with the podium time bonus system (which helpfully also abbreviates to PTB  ) used in the later seasons of USC; a similar suggestion was also made by Alan Rotoi in 2021. The system presented below is far from the only reasonable alternative bonus system, or even the only way to do PTB (the USC system, for instance, was different in quite a few ways). While I do feel it could be implemented successfully, it is also meant as exploration of the design space, highlighting some aspects we would want to consider in this or any other possible LTB reform.

General premises

In addition to the main goal of providing further opportunities for earning bonuses and thus involving more pipsqueaks in the bonus fights, which would be the main point of adopting PTB, there are some positive aspects of the current LTB system that are worth trying to preserve in any reform. I would highlight three of them:

• Waste of "partial credit" -- hours that do not add up to a whole bonus point -- should be kept to a minimum. (The current system achieves that with accumulated leading hours carrying over across races until the pipsqueak earns a point.)
• It should be possible to track your progress and know what you need to do to earn your next bonus. (With the current system, you just have check how far your total hours are from 240 or 480. In the pre-2020 system, which gave points to the two pipsqueaks with the most hours in each race, while it was possible to get LTB +1 with as little as 24 hours, you'd always be at risk of being overtaken late in the race.)
• The amount of bonus points given shouldn't be as large as to unbalance the season scoreboard. (The current system is a marked improvement in that aspect over the pre-2020 one, as the total amount of bonus points fell by about a third, mainly thanks to hours after gaining an LTB point not carrying over.)

The extent to which the PTB system below addresses these goals is up to discussion, and to the evaluation of you all.

The system

Without further ado, let's look at how this version of PTB is supposed to work. It gives bonuses for time spent in the top 6 positions, with the bonus gains being weighed by position. Top 6 is a familiar threshold at ZakStunts, being used for things like XP Points and car coefficient updates.

To make gains incremental and granular in a way that extends to the whole top 6, bonuses are granted in increments of 0.05 points. In that aspect, the mechanics are similar to the current system: you accumulate hours and, at certain amounts, earn your next (fraction of a) point.

For each position, the weights are applied through the number of hours needed to earn the next 0.05, as follows:

• 1st place: 0.05 every 14 hours (1 × 14)
• 2nd place: 0.05 every 28 hours (2 × 14)
• 3rd place: 0.05 every 42 hours (3 × 14)
• 4th place: 0.05 every 70 hours (5 × 14)
• 5th place: 0.05 every 112 hours (8 × 14)
• 6th place: 0.05 every 182 hours (13 × 14)

(Why multiples of 14? I'll get back to that later.)

A pipsqueak can earn at most 2 PTB points in a single race. While that doesn't make a big difference to the amount of points available (without the limit, the maximum would be 2.1 points for a lead of 14 × 42 = 588 hours), it makes the system tidier in a couple ways: by making the maximum PTB per race a whole number, and by making such a maximum still attainable even if hard to reach (at 560 leading hours out of 600) rather than nearly impossible (as it would be at 588 out of 600).

There is no carryover of hours between races, as the granularity of the 0.05 point increments should be enough to make that superfluous.

Within a race, however, hours are transferred between positions when the scoreboard changes. For instance, if a pipsqueak spends 72 hours in fifth place (out of 112 needed to get 0.05 at that position) and then moves up to second, those hours are converted to 72 × 2 / 8 = 18 hours, and so they will only need 10 hours in second place (instead of 28) to get the next 0.05. Internally, that could be implemented by tracking the fraction of "credit" earned towards the next 0.05, or by incrementing a counter every hour according to the proportions shown above. (How to display that information to pipsqueaks is a different matter, which I'll get to in a moment.)

Initial comments, potential pros and cons

Quoting myself from the 2025 rules thread:

We could perhaps begin by looking at possible motivations for changing LTB. Looking back at past discussions, I would highlight two issues that I've seen mentioned with some frequency:

• Most pipsqueaks never or only rarely partake in LTB fights.
• Intense LTB fights can be exhausting and time-consuming.

To my eyes, the primary goal of adopting PTB is dealing with the first of those issues: involving more pipsqueaks in bonus battles, while providing further incentive, and benefits for, posting replays regularly. It does not directly address the second issue; however, it becoming possible to earn bonus points while in lower positions might ease some of the tension that an LTB fight can bring.

The choices of granting bonuses at multiples of 14 hours and of using Fibonacci (1-2-3-5-8-13) multipliers for the positions might appear surprising. Playing a bit with the values suggests that is one of the very few combinations that gives, at the same time, reasonable point gaps between the top 6 positions, nice fractions for the maximum bonuses per position, and evenly spread intervals on the 600-hour race window (which is specially important to avoid wasting too many hours at the lower positions). The table below shows some of those properties:



Note, in particular, that in a system of granular bonuses without carryover it's a good thing to have "hours for maximum" close to 600, as that minimises waste. (Having it equal to 600, however, wouldn't be quite as good, as it would make the maximum essentially unreachable.)

While the system conceivably might be made even more granular by using 0.01 or some other smaller fraction instead of 0.05 for the minimum bonus amount, my view is that doing so would only make season scoreboards harder to follow for little benefit.

With bonuses being granted in 0.05 increments, this is a very nearly a continuous system. One of the consequences of that is LTB tactics, be them aimed at reaching your next 240 hours or stopping someone else from doing so, will be greatly simplified. In my book, that counts as a negative, as the nature of such tactics under the current rules makes the fights more interesting than they have ever been. However, for those whose main concern is making bonus fights less exhausting, simpler tactics could also help with easing the pressure on the contenders.

Across all pipsqueaks, this PTB system would give a maximum of 4.65 points per race (while the sum of the "maximum bonus" column in the table above is 4.55, the 2-points-per-pipsqueak limit usually won't need to be applied if multiple people spend time on first place). While that might look like a large increase over the current rules (a bit under 2 points per race in average), or even the pre-2020 system (in the absence of ties, a maximum of 3 per race), the points should be spread across more pipsqueaks, and in a much more even manner, so chances are the season scoreboard wouldn't become unbalanced. Ideally, we'd evaluate the potential effects of adopting PTB with some simulations. While I haven't done so beforehand to avoid delaying this post too much, I plan to try that over the coming weeks.

Last but not least, there's the important matter of how to report the bonus battles in a clear way to drivers and spectators. Replicating the detailed hours table we use for LTB six times, one for each position, feels like overkill. It would probably be more useful to have a concise summary displaying the situation of everyone who has been in the top 6 in the current race. Something like this:



"Pos." is the current position on the scoreboard. "Points" is the PTB earned so far. "Progress" is how far on the way to the next 0.05 the pipsqueak is, reflecting in a more user-friendly way the internal counter I mentioned when discussing how hours would transfer upon position changes. Finally, "Hours to next" is how many hours remain to the next 0.05 assuming the positions don't change (for pipsqueaks currently outside of the top 6 that doesn't make sense, so it is left empty). A table like this might well cover most information useful in practice to pipsqueaks, so the detailed hours charts could be relegated to a secondary page, or removed entirely. (I'd be happy with keeping a leading hours chart, though, even if it's just for nostalgia reasons  )

The drafts feature is now enabled in the Forum. If you are writing a longer post and have to stop in the middle, or would rather do it bit by bit over the course of a few days, you can use the "Save Draft" button below the reply boxes. Later, you can find your drafts and resume your writing through the "My Drafts" button on the user pop-up menu, or "Show Drafts" on your user profile.

San Marino has just been promoted to the Nations League C!! 

Given that it's quite possible that we'll see a draw (or even a few draws) somewhere on the season scoreboard, it makes sense to have a look at the issue of tiebreakers, in order to clear any lingering ambiguity.

The ZakStunts rules page says that "in case of a draw, the pipsqueak with the most victories / best positions / number of best positions is announced as the winner". That provision was added for the 2016 season, after we realised in the previous year that the rules were silent on tiebreakers. Sounds clear enough, right? However:

• Somehow, and in spite of being involved in the discussion about it back in 2015, I either forgot completely about the rule change, or was never aware that the text of the rules had actually changed to begin with! I suppose others among you might be similarly surprised about it.
• The season scoreboard page currently doesn't break ties using the number of wins and so forth.

The point of this post is just to put the matter up for consideration. For this season at least, I won't push for any particular way of breaking, or not breaking, ties. I can't do that with a straight face given that I was confidently misquoting the rules as late as yesterday 

Ever since ZakStunts started having multi-car races, the balanced bonuses question has been a matter of interest to pipsqueaks and track designers alike: which set of bonuses would give all cars even chances of winning? This post presents a what I believe to be a sensible, comprehensive way of answering that question. A list of bonuses estimated for most cars featured in ZakStunts can be found towards the end of the post. Before that, a few words about my methods and assumptions.


A couple pre-season rule reviews ago, I suggested figuring out balanced bonuses by comparing pairs of cars, sorting the races they were involved according to the ratios of the bonus multipliers (or the advantages, which is how I'm calling the differences of the multipliers' logarithms, and which are easier to work with as they are on a linear scale), and finding the point at which the winning car changes. While that idea is basically sound, there were a few obstacles when it came to applying it systematically:

• Figuring out which races are relevant for each pair of cars. (Two years ago, I picked those in which at least one car of the pair reached the top 6. However, that might discard quite a lot of useful information, specially for the last two seasons, with close bonuses and single-car podiums.)
• Reliably estimating the switch point between the cars. (Eyeballing only takes you so far, specially when there is significant overlap between the winning ranges of the cars, or with custom cars for which not many data points are available.)
• Distilling the pairwise estimates into a single, overall estimate of the bonus for each car. (With 33 cars used in ZakStunts since 2008, we might have up to 32 different pairwise estimates for each car!)

For #1, after playing a bit with the available data I have settled on picking matches (that is, comparisons between cars available for a specific race) in which at least one of the cars either reached 120% of the winning time or had at least 10% of the submitted replays. That seems to give a good balance between preserving information and excluding accidental results.

For #2, a simple and well-established solution is logistic regression: using the advantages and the record of wins and losses for a pair of cars, we can fit a model that estimates the winning probability for the given advantage. For instance, here is an updated version of the Carrera versus Lancia chart from my older post, with a fitted logistic curve:



The midpoint of the curve, the point at which the model predicts the cars have the same chance of winning, is at an advantage of +0.056, which would amount to a +5.4% relative bonus of the Carrera over the Lancia.

(Side note: while the logistic model has the great advantage of simplicity, there are other reasons to regard it as a reasonable functional form for our problem. In particular, the winning probability as a function of the advantage should in any case be a sigmoid, as it must go to either 100% or 0% as the bonuses grow apart from each other, and also must be symmetrical around the midpoint.)

Obstacle #3 was arguably the decisive one. Ideally, we'd want to use the full wealth of pairwise comparisons to reach an overall value for each car, but do so in a principled way. After trying a few ad hoc approaches with limited success, I learned there is a standard way of taking in the pairwise models all at once: the Bradley-Terry model. It is similar in a few ways to an Elo ranking but without evolution in time (so the abilities of the players are assumed to remain constant), and is commonly used to estimate the abilities of players or teams within a tournament. In our case, the cars are the "players", and each pairwise meeting in a race is a match. The bonus advantages, then, can be incorporated in the same way that, in more typical uses of Bradley-Terry, home advantage for sports teams is handled: as an added term to the car "ability" scores.

With those pieces in place, fitting a Bradley-Terry model to the ZakStunts data is straightforward, giving us abilities for each of the cars, which are displayed with error bars on the chart below:



Up to a scaling factor, these abilities correspond to the intrinsic advantages for each car, and so they can be easily converted to balanced bonuses. You'll note I have excluded a few of the ZakStunts cars:

• Acura, GTO, Indy and Vette, due to the notorious problem of powergear leading to too much variability from one track to the next. (For a rough idea of where they stand relative to the others, see the Magic Lamp experiment.)
• Xylocaine, which, besides also being a powergear car, was never competitive in its one ZakStunts season so far.
• Speedgate, whose driving technique evolved so much that it is questionable how representative its historical results are.

It might be prudent to take the estimates of cars which only had one or two seasons so far with a grain of salt, as the error bars in the chart above suggest. (Uncertainty is specially high for the 911 Turbo because the seasons in which it was competitive were at the height of the far-apart-bonuses era, which tends to make its matches less informative.)


With the i's dotted and the t's crossed, here are the balanced bonus estimates:



These percentages should not be taken as definitive: the methodology might be further refined, and there will always be more races to add, with different scenarios to try out the cars. In any case, they are an auspicious start! 


One direction that might be explored in future work is adding more predictors to the model. The Bradley-Terry framework allows bringing in extra factors that might be additional sources of advantage or disadvantage for the cars. We might collect data on track-specific (e.g. the proportion of non-asphalt elements) or even replay-specific (e.g. how much of a lap is spent accelerating) variables, incorporate them to the model and see if they interact with the car abilities. That might be one way to quantify situational advantages of, for instance, off-road cars, or even powergear cars.

Both the data and the (very unpolished!) R code used to fit the model and obtain the bonuses are attached, in case you want to reproduce the calculations or tinker with them.

There is a long history in our community of Stunts tracks being named after music tracks, a history of which I'm but one of the continuators, having acquired the habit from Mark L. Rivers once upon a time. It would make a lot of sense to be able to listen to those tracks, so here is a playlist of them!

• Spotify version
• YouTube version

Though having a majority of rock songs, the playlist features quite a variety of styles. I have included every track-naming track I know of, plus a few bonus tracks sprinkled around. Please let me know if I have missed or misidentified anything!

A two-in-one announcement! Thanks to some recent conversations, I realised the in-game car testing methods used, for instance, to get stats for the Megathread were not documented anywhere. To rectify that, I have created the "Car testing" article in the Wiki, which describes reliable ways of measuring top speeds, acceleration and dragstrip times.

But wait! There's more! As a companion to the article, I am sharing a recently upgraded Proving Grounds track, which is attached below and linked from the Wiki. It provides facilities for doing the tests described in the article, as well as three testing circuits (dirt, low speed with multiple configurations, and high speed) and several other goodies. Enjoy!

Here is a tiny Restunts plaything -- thanks @alanrotoi for the idea of looking into it!

The starting line truck features an actual raised platform with a slope, as demonstrated by the animation at the beginning of the race (as well as the car dropping glitch that happens when you pause the game during it). This platform then magically disappears along with the truck once the lap begins. It turns out the surfaces that make up the platform are part of the start/finish line element; however, their existence is controlled by a conditional in build_track_object which skips them unless the animation is running. Since this is such a simple test, it is straightforward to disable it by poking at the executable with the help of a debugger. That allows us to get a taste of what would be like if the truck platform were a real track element!

Attached to this post you'll find a Restunts game executable that has been hex-edited to disable the aforementioned test. I have also added a demo track, in which you can drive straight at the beginning (out of the broken path and onto the chicane) in order to break the path finding, thus allowing you to drive through the start/finish line in either direction as many times as you want.

As expected, the platform works as a small ramp when driven the wrong way. While there is no slope when approaching the platform from behind while driving along the direction of the track, the platform is low enough that hitting it provides a well-behaved bounce, not unlike the boulevard bug one. Another quirk is that the platform covers only the right lane, as there is no truck for the opponent car on the left side.   

First, a little background: In last year's pre-season, there was some discussion about increasing team sizes, given that most teams were at or over the 4-member limit -- and, with Slowdrive having recruited a fourth pipsqueak, all teams are now in such a situation. The proposal didn't succeed, with the advice to teams being to instead lean on the distinction between, so to speak, unofficial members (as many pipsqueaks as desired racing together) and official ones (at most four people registered and scoring points for the team).

Thanks to @Overdrijf , though, I have realised there's an effective compromise solution right under our noses, one which can be implemented right now, under the current rules: B teams! If, for instance, Team Orion were above the size limit and had four of their pipsqueaks already active in the season, the extra members could be registered as Orion II (or The Belt, et cetera). Using B teams, I believe, allows us to steer clear of the potential problems with both a team size increase and an inflexible limit:

• Extra members now are recognised and shown on the scoreboard as being part of a team, which is much more welcoming and avoids any harsh feeling of exclusion.
• The scoreboard team affiliations now correctly show that the extra pipsqueaks aren't actually racing alone, making things a little more transparent.
• The official size limit keeps being 4, so there's no risk of affecting the competitive balance.
• There's no need for the rule book to continuously play catch-up with the trends, as a size increase might induce. (For instance, if we were to increase the limit to 5, it's not unlikely that the teams would take up the opportunity and expand, leading us to restart the discussion, but now about increasing it to 6).

As I mentioned above, it should be possible to start using B teams right now, as soon as the circumstances call for them. The only slight tweak to the procedures we'd need to do is waiving the minimum size of 2 restriction for B teams (and only B teams), as they are an extension of the main team, and it doesn't really make sense to allow 6-member teams to use them but not 5-member ones. A feature that would be nice to have but isn't essential is displaying B team status on the site, perhaps through a link between the team profiles in the database, or even just a notes field in the profiles that allows us to mention the affiliation.

One question that comes up every now and then as we look at our community venues is how effective are our options when it comes to having, so to speak, a social lobby: an official, easy to reach place with active conversation, both "on" and "off"-topic, where, in particular, newbies can land on and settle. Below is a quick (and not necessarily neutral!) review of where things stand, meant as a conversation starter should we feel like shaking things up a bit. (For another take, see this post by @Cas , written in a similar spirit last year.)

Now, for a very long time this Forum has been the central hub of the community, providing a space for conversation and linking various initiatives across the Stuntsphere. The usage patterns of the Forum, though, have changed significantly over the years. On the one hand, it remains a key venue for Q&A, technical discussion, project coordination and team activity. On the other hand, the volume of open-ended conversation in the Forum has fallen a lot since, say, the early 2010s, specially when it comes to off-topic chat. While a concerted drive to make the quieter corners of the Forum more active could be a worthy initiative, I see open questions about how accessible the old-growth structure of the Forum is to newcomers, and more broadly about what kind of forum culture we can hope to rekindle in this day and age.

Meanwhile, the Stunts group on Telegram, started by Cas about two years ago (cf. the thread about it here), has become a pretty successful experiment in running a "third place"  for casual chat, a role not unlike that played by the Stunts IRC channel, in tandem with the competition sites and the Forum, back in the early 00s. It sparked many interesting conversations, bout about Stunts and otherwise, and helped us keeping in touch with a few long-absent pipsqueaks. While the group is open to people from the community (let us know if you want to join!), up to now we have hesitated a bit when it comes to actively advertising it, or bringing it to a more central place in our ecosystem. One reason for that, I reckon, is the fact that the group is hosted on Telegram, a social media platform which, like most social media platforms, offers us little control over its workings, and which people might be unwilling to sign up for due to various reasons.

There are, of course, other spaces we might conceivably explore. In particular, last year we had a brief look at Element/Matrix (cf. this Forum conversation about it), and how it potentially could offer the amenities of modern group chat/messaging in a platform providing us more meaningful control, thus making it easier to bring under the stunts.hu umbrella. It could be a fitting time to revisit Element and consider what would it take, and what issues we might have to deal with, in order successfully set up a chat venue based on it.

[with track position at 8:00 as the tiebreaker]

Running Le Stunts races with a live broadcast (see the videos for Fortitude and Texarkana -- thanks @Erik Barros!) was an interesting experience that has provided food for thought about live racing formats. In this post, I'll talk about (and give my own spin to) one specific matter that concerns how we figure out results in the Le Stunts format.

The familiar Le Stunts rules specify that pipsqueaks have to drive an 8 minutes long replay and post it to the Forum within 12 minutes. Results are then defined by the number of completed laps, with track position at 8:00 as the tiebreaker. This way of assigning the results is as simple as it gets for the drivers (save your replay when the game clock gets to 8:00 and you're good to go). However, an outcome which depends on track position in an incomplete lap can be a little confusing to live spectators. Also, things sometimes get tricky for the race stewards as well, as small margins might require a photo finish for confirming the results.

That being so, there's a decent case for, instead of relying on track position at 8:00, only counting full laps. Results would be according to the number of completed laps and, as the tiebreaker, the game time when the final lap is completed. Now, that can be done in a few different ways. I'll say a few words about three of them, the third one being my preferred approach.

To begin with, we might simply rewind to the last lap before 8:00, checking lap count and finish time at that point. This is the simplest option, as the driver doesn't need to do anything different than under the traditional rules. However, I believe this approach has a serious flaw: the driving between the end of the final lap and the 8:00 mark no longer actually count for the results. That goes against the basic concept of the Le Stunts format, in which everyone is supposed to race for 8:00 of game time. Furthermore, discarding some of what has been driven can lead to awkward corner cases. Consider a track with laptimes around 1:00, and a driver who, approaching the end of their race, completes a lap at 7:02. The driver is now suddenly pressed into a quick decision on whether to make a mad dash to finish an extra lap in 58 seconds.

The obvious alternative, then, is to ask drivers to cross the finish line after 8:00. This approach, which mirrors the rules of endurance races, makes everyone drive at least 8:00 and gets rid of dead time in replays. The corner case problem, however, remains in a different guise. A driver who crosses the line at 7:59 now must complete one extra full lap, substantially increasing their risk of having trouble with the 12 minutes deadline. Meanwhile, there are no such concerns for someone who completes a lap at 8:01.

How, then, to require the line to be crossed after 8:00 while keeping things equitable? The way out that I can see is to add tolerance to the deadline to account for the final lap. In order to avoid giving everyone lots of extra slack, the tolerance should grow with how much game time each driver actually uses to complete the final lap. That can be done without resorting to calculators by using a table like this one:

In-game finish time    Deadline
-------------------    --------
8:00.00 -- 8:19.95     12:30
8:20.00 -- 8:39.95     13:00
8:40.00 -- 8:59.95     13:30
9:00.00 -- 9:19.95     14:00
9:20.00 -- 9:39.95     14:30
9:40.00 -- 9:59.95     15:00

(Side note: this approach might also be useful for alternative formats with a fixed number of laps.)

For instance, in a race which officially starts at 18:25:15, someone who completes the final lap at 8:46 on the game clock would have until 18:38:45 (thirteen and a half minutes later) to post their replay.

Keeping track of such adaptable deadlines would in principle be a little harder for drivers. In practice, though, it should be enough for pipsqueaks to set a 12-minute countdown like we currently do, knowing things will most likely be okay as long as you get to 8:00 in game with 1 or 2 minutes remaining out of the initial 12. (Also note that the adaptable deadlines are never stricter than the simple 8-in-12 rule.) As for the result checking process, figuring out the deadline from the finish time would be required; this extra step, however, looks like a fairly straightforward thing to do.

In summary: while counting only full laps is an attractive proposition, it doesn't come for free, requring some sort of compromise: be it going against the spirit of the format by embracing drives shorter than 8:00, tolerating potential unfairness in how much each pipsqueak is required to drive, or handling a little additional complexity brought by adaptable deadlines. In any case, I would be happy with the extra-lap-plus-adaptable-deadlines rule, and consider it a slight improvement over the status quo.