Messages

As the designer of ZCT272, this concept will be a tough act to follow! Great stuff, @Overdrijf 👏

@Matei Consciousness arising from a biological substrate strikes me as, in itself, a less problematic notion than personal identity being assigned to neural (or worse still, computational) processes abstracted from their here-and-now embodiment. At any rate, I wouldn't step into a teleporter either 

I am thrilled to announce that, having accepted Cork's offer, @Spoonboy is now a member of Cork's Crew -- welcome!! 🥂

How far back can this be done?  Is it possible to have a condensed graph of the whole 21st century?  (That is, beginning with the opening of ZakStunts in 2001)

The data does go all the way back to 2001. That graph might become a little busy, but if eloratings.net can do it, why can't we?

The ZCT270 chequered flag brings the first 2024 Folyami update! Reigning champion Argammon retains a solid lead for the moment, even with his break, while race winner Alan Rotoi markedly closes the gap to me at the second place. Mark Nailwood and Spoonboy have reached personal best ratings once more. Another stand-out pipsqueak in this round was Shoegazing Leo, who had an excellent +47 rating improvement on the crest of a sustained upward trend. Below is the updated evolution chart:

Obviously none of these laps ever reached the scoreboards [in particular, You cannot view this attachment.]

Settled 



(Head over to R4K to join us at Rivendel!)

Moonwalk

@dreadnaut Yup, both points make sense. The version release date should be optional indeed, as sometimes we'll just don't know. As for having the data for the versions in the main file, that may well be more convenient for what we'll be doing, and as you say the front-end can always split it off if we need that for some reason.

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.

Those concerns, I think, do suggest it's better to leave it as is rather than imposing extra requirements on what an ID should be. There's nothing inherently wrong with UNTS or AULT as an ID, and conversely STAATZ.TRK and DEFFORD.TRK are perfectly reasonable track names.

There is one thing about zipping and it is that it allows you to repeat file names (like "readme.txt"; I would recommend carXXXX.txt instead, but...).

Side note: in a similar way, for the Competition Archive cars, I have adopted readXXXX.txt as a standard. No strong opinion on whether that's worth doing in the Car Archive -- it might make sense to keep readmes exactly as provided by the author. (Though it might also be useful to provide, or generate, readmes for cars that don't have one...)

https://nicolaszanotti.com/stunts/ -- Nick's Stunts Page, lovingly preserved from the Geocities era to the present day by another Nick -- or is it the same one?

https://www.grospixels.com/site/stunts.php -- Nice recent (December 2023!) French review. Links to us!

I'd say Eroica (ZCT147) still is my most successful track design. More recently, I've been very happy about how Atlas Air (ZCT243) and In Your Eyes (R4K39) turned out. None of them are as notable as 4:00am, though 

That would have mostly the same effect than the other rule (considering that a team can have any number of pipsqueaks not in the active list), but would go against the idea of only showing the affiliation of point-scoring members on the scoreboard.

I was thinking about a scenario where a team changes there scoring drivers based on the track so they can score on races they are good at. That feels like cheating.

That would be weird indeed. A very simple rule that would eliminate this issue would be: if a pipsqueak leaves the team (that is, the list of active pipsqueaks) during the season, the seat can't be filled until the next season. As you say, though, that's unlikely to actually become a problem.

Going back to this discussion...

I think that scoring members need to be determined before the season starts or at least before the end or the first race.

I dont't agree with this. If an inactive member of a team makes a mid-season comeback, and the team has a free seat, they should be able to rejoin immediately.  I'd also extend that to new recruitments: while there are a few more aspects to consider in that case, all in all I don't feel the rules should get in the way of people joining teams if an opportunity arises.

(It's worth noting, BTW, that both scenarios I mentioned above are allowed by the rules as they are currently written.)

You had also mentioned switches, and I agree they can be more problematic. There are, however, ways to further restrict switches without transfer windows or a blanket ban on mid-season enrollment.