Topics

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.

[2024-09-07]

As anticipated in this subforum, we'll have a follow-up race this Saturday, 2024-09-07, starting 20:00 UTC! The track, which is called Texarkana, is attached to this post. It will be raced with Zapper's Ferrari F40, which is included, for instance, in the 2024 car pack from the ZakStunts downloads page. As usual, we'll meet at the Forum chatroom.

Here is a reminder of what the 20:00 UTC start time will look like in some time zones:

    Brisbane 06:00
    Los Angeles 13:00
    Buenos Aires 17:00
    London 21:00
    Amsterdam 22:00

[Fortitude]

Here is Fortitude, the track for today's live race, starting 20:00 UTC! The car will be @Erik Barros 's Fiat Uno (Ladder Edition), which you can get from its forum thread.

(Edit: also added FUNODEMO.RPL, a demo lap on Default in case anyone needs to sanity check the car version.)

Apologies for the lateness! If need be, we can have a quick "free practice" session at 20:00 UTC, right before the race. (You might want, in particular, to do a little planning on how you'll want to approach the fast sector.)

20:00 UTC is about six hours from the moment I'm posting this thread. A reminder of how that translates to some timezones:

    Brisbane 06:00
    Los Angeles 13:00
    Buenos Aires 17:00
    London 21:00
    Amsterdam 22:00

This is an interesting take on a slowish road track. I've found it quite enjoyable after a late start.

@HunterBoy344 has generously offered to host a live race on his Stunts Online server, and I think we should definitely do it 

As usual, we just gotta arrange a date and time will make for a reasonably well-attended race. On the shoutbox, HunterBoy has suggested doing it this Thursday, June 13th. While, personally, I might be able to make it for a quick race in the South American evening, between 22:00 and midnight UTC or so, aligning schedules on a weekday could get tricky. What do y'all think about it?

A new race has started at CCC! You'll have until June 23rd to find your way around Krys TOFF's ZCT077. Like the usual CCC tracks, it features tunnel checkpoints that have to be crossed through the inside -- here, though, they are sprinkled across an off-road track, and can be driven in any order! As for cars, this being the Custom Car Championship, in addition to the Audi Quattro you'll be able to pick @alanrotoi 's Ford Sierra and, in its competition debut, @CTG and @Ryoma 's Subaru Impreza WRC!

@Daniel3D's track features (spoilers ahead!) an illusion walled chicane. While the illusion means you don't get to see the exit walls of the chicane while you're entering it, you can get a decent sense of where to place the car by aiming at the asphalt of the exit "ramp", whose underside is overlaid by the illusion.

Since this configuration is made out by fusing the lower parts of two u/d corks, there is a crest at the point they meet. While it's perhaps even be possible to take advantage of a little jump there, it's also rather easy to fly into the exit wall if you're going too fast. That being so, a conservative approach to begin with might be slowing down hard enough to keep the car on the ground, and then gradually pushing harder on further attempts.

Here is a GIF demo of navigating past the illusion:

Here go a few thoughts about handling different versions of the same car. I'll begin with a @dreadnaut quote from another thread:

You might note a version number there. The discussion above made me realise that we need to keep that explicit, because an old competition might want to point to a specific version of the car, and not to the most recent one. Versions can "branch", so it's not simple ordering. I think I'm roughly proposing WXYZ/<version-id> as a versioned car identifier.

This is a good capsule summary of what we'll have to deal with. Compared to the initial draft of the design in the GitHub repository, it also points -- rightly so, IMO -- toward more explicit version management. I'll also quote the relevant bits of the repo docs, just for the sake of providing contrast:

For each car:

• a <WXYZ>.yaml file containing
• [...]
• a resources directory containing all the car files
• an optional history directory, containing subdirectories for previous versions of the car

Such a layout would likely suffice for the happy path, in which cars always have a linear version history, the most recent release by the author is the default choice of version by the community, and there are no replay-incompatible releases once a car has been used in competition. History, though, has a way of playing tricks on us when we least expect.

One particular scenario I see as important to consider is that of a car having an initial release which is used in competitions and then, for whatever reason, gets a replay-incompatible update at a later point. It is worth noting this is not a theoretical concern: a few of Ryoma's cars which were picked up by competitions while he was away in 2022 later had performance-changing updates, most notably the Ferrari 641/2 featured in R4K last year.

With these considerations in mind, here's what, at the moment, I'd feel like adding to the repository layout for the sake of version management. This is a rough sketch, for the consideration and criticism of y'all:

• There should be an INI file for individual versions. There is no need to duplicate everything from the main INI file of the car, as the point is just providing clarity on what the version is. Plausible fields include:
  
  • car-id, for cross-referencing;
  • version-id, along the lines of what dreadnaut has suggested in the quote at the beginning;
  • release-date;
  • distributor (optional), who originally prepared the release. Relevant, for instance, to distinguish KyLiE's bugfix releases;
  • comment (optional), a one-line summary of what distinguishes the version.
  Additional information we might want to keep track of includes replay compatibility across versions, and known races in which a version was used. These are trickier, though, and can wait until we get the basics settled.
  
• All versions, including the default one, should get their own subdirectory and version INI file, ensuring uniformity of handling and documentation. (This differs from the initial GitHub draft, in which a privileged default version would have files in resources, while old versions would get subdirectories of history instead.)
• The main/default/current version should be recorded in a field of the car's INI file, so that tools and/or users can find the way to it. For the sake of convenience, it's likely we'll still want to provide the files of the main version outside of its subdirectory (e.g. as a zip in the car's root directory). I think it will be fine to replicate the files for that specific purpose.
  
  • Given the possibility of the version history splitting into branches, it might make sense to distinguish, with separate fields in the car's INI file, between the latest version by the author and the current community default (at least one of the fields being optional). The "community default" concept is perhaps similar to the notion of a "homologated" version (i.e. one that has been used in competition) that I tried to bring into the Southern Cross collection some time ago.

[diffcar]

I'm happy to announce the release of diffcar, a command line tool for comparing and detecting changes in CAR*.RES files. diffcar currently offers two commands. The first one is diffcar single, which takes a pair of CAR*.RES files and prints a nicely formatted, Stunts-aware diff of them:



The second one is diffcar report which takes two directories and prints diffs of files with matching names (case insensitively) that exist in both of them. The output is printed to the terminal by default; you can specify a destination file instead with the -o option.

You can download Windows and Linux binaries from GitHub: https://github.com/duplode/diffcar/releases/tag/v0.1.0.0 . As ever, feedback is most welcome!

[Light]

In the parent thread, one issue that has come up is how to name and record paint jobs. Here are a few notes on the topic, which might be of some use in figuring out how much will we want to standardise the descriptions.

The original cars span eleven paint jobs, with almost all of them come in light and dark pairs. The table below shows them, along with some plausible single-word fancy names that may or may not be useful to adopt. (Suggestions of nicer or more accurate, fancy names are welcome!)

		Light		Dark
Grey		Silver		Graphite
Blue		Blue		Turquoise/Aqua
Purple		Violet		Indigo
Red		Red/Scarlet		Ruby/Carmine
Yellow		Yellow		Gold
Green		Lime

The omission of a darker green was readily rectified by the community (see eg. the "British racing green" Lotus paint job #1), to the point it has pretty much become the 12th car colour. Other examples of custom solid colour paint jobs are:

• Black (eg. Speedgate #1)
• White (eg. F40 #4)
• Pink (eg. Thunderbird #1)
• Beige (eg. 911 Turbo #7)
• Orange (eg. Skyline #7 -- though note the palette there can be improved a bit)
• Brown (eg. Torino #1)

Beyond these, we have a plethora of combination paint jobs, which can be described in all sorts of ways: with slashes (eg. BMW DTM #9, Black/Pink/Red), plain descriptions (eg. Melange #3, Yellow with Black Stripes) or fantasy names (eg. Monster Truck #5, The Joker).

Welcome to the Car Archive project sub-board! This space is meant for specific discussions about the project that might benefit from having their own thread. The original "Car archive" thread remains open for general discussion and free-form brainstorming.

Useful link(s):

• dreadnaut's project repository on GitHub
• "Custom cars" Wiki article (includes an extensive list of cars compiled by Alan Rotoi)

I have worked out a recipe for making scoreboard side pictures of cars with consistent looks and angles. While not as sleek or convenient as a special purpose tool would be, it is quick enough to do that even a large handful of pictures can be prepared painlessly. The secret sauce is tweaking Stressed so that the default viewing angle is the one we want to use (more on that at the end). I've gone ahead and updated the pictures on the site, so let me know how you like it after a hard refresh -- while consistency requires a few compromises, there might be some room for adjusting the values in the recipe.

So, without further ado, here are the steps:

• Open the car P3S/3SH in (tweaked) Stressed with a maximised window, select car0 and the chosen paintjob.
• Take a screenshot of the car (leave some white background around it; no need to crop it precisely) and open it GIMP (or Photoshop, etc.).
• Use selection by color with zero threshold/fuzziness to pick all the white areas, then use color to alpha to make them transparent (this works great because Stressed renders without blurring and uses #fcfcfc rather than #ffffff for in-game white).
• Crop the image to the content.
• Look at the cropped image dimensions and calculate the height : width ratio. (We're aiming for a maximum car size of 360 x 92, so this ratio will guide how we'll scale the image.)
• If the height : width ratio is smaller than 92/360 = 0.2555..., then proportionally scale the image to a width of 360. Otherwise, proportionally scale it to a height of 92.
• Enlarge (without scaling) the image/canvas size to 380 width, centering the content horizontally, then enlarge it to 100 height, placing the content 4 pixels above the bottom. (The current size of the images on the site is 380 x 100.)
• Export the resulting image as a GIF.

Below are the the tweaks in the Stressed code. I picked 10° as the roll angle because that felt like a typical value for the old pics; 15° is an alternative value that might work as well. You'll note I have also changed the y-axis aspect ratio correction factor in the rendering from 0.8 to a more accurate 0.8333... (that's something I probably should make into an actual patch for Stressed). Note that the line numbers in this diff don't necessarily match the current state of the Stressed repository:

Code Select Expand

diff --git a/stunts/stressed/src/shape/shapeview.cpp b/stunts/stressed/src/shape/shapeview.cpp
index a92c31f..b4ecfb6 100644
--- a/stunts/stressed/src/shape/shapeview.cpp
+++ b/stunts/stressed/src/shape/shapeview.cpp
@@ -135,7 +137,8 @@ void ShapeView::reset()
         0.0f,
         0.0f,
         -distance(VerticesModel::toInternal(bound[2]), VerticesModel::toInternal(bound[5])));
-    m_rotation.rotate(10.0f, 1.0f, 0.0f, 0.0f);
+    m_rotation.rotate(-90.0f, 0.0f, 1.0f, 0.0f);
+    m_rotation.rotate(-10.0f, 0.0f, 0.0f, 1.0f);
   }
 
   QAbstractItemView::reset();
diff --git a/stunts/stressed/src/shape/verticesmodel.cpp b/stunts/stressed/src/shape/verticesmodel.cpp
index f9b7db0..0877e58 100644
--- a/stunts/stressed/src/shape/verticesmodel.cpp
+++ b/stunts/stressed/src/shape/verticesmodel.cpp
@@ -21,7 +21,7 @@
 const int VerticesModel::VAL_MIN;
 const int VerticesModel::VAL_MAX;
 
-const float VerticesModel::Y_RATIO = 0.8f;
+const float VerticesModel::Y_RATIO = 5.0f / 6.0f;
 
 bool VerticesModel::m_weld = false;


This is a thread for sharing test reports of Stunts cars: all cars are fair game, and everyone is welcome to contribute. It is a spiritual successor to the "Trying out Ryoma's cars" thread from the 2022 preseason, and accordingly tests from there will be linked from here as well.

Index of tests:

• Alfa Romeo 164 Procar *
• Citroën XM V6 24 *
• Cizeta V16T *†
• Dodge Challenger R/T Hardtop (1970) *
• Ferrari 312T and Ferrari 312T4 *
• Ferrari 365 GTB/4 Daytona *
• Ferrari 412 Automatic *
• Ferrari 456 GT *
• Ferrari 512TR *
• Ferrari Pinin *
• Jaguar XJ220 *†
• Lamborghini Diablo VT *
• Lancia 037 *†
• Lancia LC1 and Lancia LC2 *†
• Lancia Stratos *
• Maserati Shamal *
• McLaren F1 *†
• Pontiac GTO (1967)
• Porsche 959
• Vector WX3 and Vector W8 *†

*: Test from the "Trying out Ryoma's cars" thread.
†: Retest pending due to major changes in a newer version of the car.

Here's a report on a little experiment ran a while ago, with support from @Daniel3D and @alanrotoi . The first two CCC races of this season, Magic Lamp and Free The Genie were set up so that we could gauge how much difference powergear makes to the performance of powergear cars. The extent of powergear availability is a major confounding factor in the sort of bulk comparison I attempted during the ZakStunts preseason rules discussion (which is otherwise fairly accurate). In this experiment, a complementary approach was taken: Magic Lamp is a (mostly) PG-free track, while Free The Genie is a PG speedway, so the differences in relative performance between the tracks can give us a view of influence of PG.

To begin with, these are the results for Magic Lamp. Those were NoRH laps (except for redoing the finish with the flexible PG cars to avoid getting PG on the final loop) driven by me with roughly the same effort on each of them (laps and tracks are attached). For the flexible PG cars, powergear was intentionally avoided on the final loop. The final column is the bonus percentage, ZakStunts-style, corresponding to the laptimes. P962 (fixed at 0%) and LM002 laps have also been included for reference:

Code Select Expand

PMIN    1:35.85    -5.7
P962    1:41.30    0   
XCFX    1:42.90    1.6   
PFCR    1:47.30    5.6
FGTO    2:09.40    21.7
VETT    2:10.60    22.4
ANSX    2:11.35    22.9
LM02    2:19.95    27.6
PACK    2:33.55    34.0

(XFCX is the Xylocaine, PFCR is the Crown Victoria, PACK is the Packard 8.)

This comparison puts non-PG Indy at -6%, the other original PG cars fairly close to each other around 21-23%, the Xylocaine at a pretty low 2%, the Crown Victoria (which isn't quite a PG car) at 6%, and the Packard at 34%.

Next, the Free The Genie results. I drove this with RH so that a comparison of full PG laps would be realistic, again putting similar amounts of effort in each lap (though the Xylocaine one might be a touch stronger than the others):

Code Select Expand

PMIN    1:07.55    -28.6   
XCFX    1:12.45    -19.9   
PACK    1:19.45    -9.3   
FGTO    1:20.10    -8.4   
VETT    1:20.85    -7.4   
P962    1:26.85    0   
ANSX    1:29.20    2.6   
PFCR    1:48.85    20.2   
LM02    2:28.60    41.6   

Both the Crown Victoria and the LM002 lose heavily here due to not having been fast enough to cut the second u/d cork (even the P962 barely made it). As for the PG cars, we see gains of over 40% for the Packard, around 30% for the Vette and GTO, and around 20% for the Acura (as expected, gains are limited by the lack of powerslides), Indy and Xylocaine (which are a little less dependent of powergear thanks to better handling).

These are results obtained by one specific driver on two specific tracks, so they are certainly affected by idiosyncrasies and chance. Still, they should give a rough idea of what to expect when it comes to the influence of PG on e.g. bonus percentages.

Kevin Pickell's Westwood is a great retro pick! Between here and CCC, I also like seeing the Xylocaine get some regular use -- I feel we've kinda done it dirty back when it made it to ZakStunts years ago.

A bug report from @Erik Barros a while ago made me realise the language packs for the forum interface weren't working well, as they had been made for a version of the forum software much older than what we currently have. I have just reinstalled the language packs with up-to-date versions, which should provide a better experience if you ever feel like switching the preferred language in your profile. Below is a before-and-after comparison:

You cannot view this attachment.

You cannot view this attachment. 

[The proposal]

2023-04-22 update: The proposal below is being updated to better reflect our current understanding of unstable replays. To avoid invalidating the next several replies, removed passages will be struck out, while additions will be in italics. For a rundown on when instability arises and how to work around it using the replay controls, see this post.


I'd like to start a discussion about the unstable replays rule, motivated by the replay invalidations at ZCT260 (see the shoutbox posts from April 8th and 9th for what happened there, and the end note at the bottom of this post for an explanation of what unstable replays are). I will open it by putting a rule change proposal on the table for your (and dreadnaut in particular, of course) consideration.

The proposal

Change the relevant passage of the rule which makes unstable replays invalid (rules page, section "The System", bullet point #2) from:

"[...] and [a replay] should play correctly when loaded in Stunts, from 'Options → Load replay'."

To:

"[...] and [a replay] should show as complete upon loading in Stunts from 'Options → Load replay', rewinding to just before the finish line, and continuing from there."

2023-04-22 update: While checking how the replay ends upon loading from Options should be the primary means of validation, the current procedure of watching the lap from the beginning, with multiple cameras if necessary, should be kept as a fallback. That being so, it might be appropriate to concisely describe the validation procedure and how it is supposed to work in a separate item.

Rationale

My proposal tries to strike a compromise, keeping replay viewing and validation reasonably easy while excluding as few valid-as-driven replays as possible. To expand a bit on that, I'll consider the two goals which, as far as I understand it, motivated the 2021 rule change:

• Ensuring competition management can validate replays by following a simple procedure with reproducible steps.
• Avoiding confusing replay watchers who play laps from the competition archives.

Goal #1 is fully addressed by my proposal. In fact, as far as manager convenience goes it even improves upon the status quo, as it is no longer needed to watch the whole lap to be sure it is valid -- just loading from Options, rewinding a little bit, and continuing to the evaluation screen is enough. (This streamlined procedure is what I have always assumed managers short on time would default to on race closing, which partly explains my mix-up when replying to Friker at the shoutbox on April 2nd.) Besides that, unstable replays which are valid according to this procedure (i.e. the vast majority of them) can be watched to the end on normal speed through the well-known replay controls trick of rewinding a little around shortly after the point of divergence and resuming play, and are reproduced correctly by the repldump tool, and usually, with an adequate choice of starting frame, when played at double speed as well. (And conversely, Overdrijf's extraordinarily hard to verify replay from ZCT232, which triggered the rule change, fails the streamlined verification.)

2023-04-22 update: Considering what we have learned over the past two weeks about unstable replays -- in particular, that divergent timelines are system dependent, and that replays such as Overdijf's ZCT232 one aren't as rare as previously thought -- it makes sense, as suggested by Friker, to keep the current, play-from-the-beginning validation as a fallback method. It is fairer to drivers to accept as many unstable replays as we reasonably can, and keeping the current method as a fallback won't noticeably increase admin workload. The main caveat is that, since divergent timelines are system dependent, if a replay is only finished on a divergent timeline and not on the load-from-Options/fast-forward one there is no guarantee that the manager will be able to watch the lap being completed. That being so, it seems appropriate to keep the new wording of the rule as it was in the original proposal, recommending pipsqueaks to check if their laps show up as complete upon loading from Options -- if they don't, there is a nonzero chance of them being ruled invalid, even though the fallback validation might rescue them.

As for goal #2, there are two aspects to consider. Firstly, there being a reproducible way for managers to validate replays means every one else can check them in some way, and as pointed out above that also translates to reasonable ways of actually watching the laps. Secondly, I feel we should not penailse, in multiple ways, pipsqueaks in the here and now for the hypothetical benefit of a future visitor who might be confused by archival replays -- specially considering that the pipsqueaks have valid-as-driven laps and are at no fault, and that we can provide easy access to information that clarifies the matter to visitors (through Wiki articles, replay package readmes, and so on).

If need be, I can go into further detail on the points above, and in particular on what makes it so taxing to verify replays in the way specified by the current rule. But I have talked for long enough for an opening post, so it's time to give the floor to you. 


End note: what is an unstable replay?

An unstable replay is a lap, usually a RH powergear one, which plays differently in-game depending on how the replay controls are used. In the most common scenario, the player completes the lap normally without noticing anything strange, and the replay shows up as complete upon loading from the Options menu and looking at the end of the tape. However, rewinding to the beginning and playing at normal speed shows the car as crashing or veering off track.