News:

Herr Otto Partz says you're all nothing but pipsqueaks!

Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Duplode

#46
Live Races / Re: Live races 2024
February 20, 2024, 01:13:02 AM
It's somewhat likely I won't be able to race on 31 March (Easter Sunday); the earlier three days are should be okay for me. For now I'll vote on the 17th, the earliest date with minimum confirmed absences so far.
#47
Live Races / Re: Live races 2024
February 18, 2024, 06:56:17 PM
I should really sign up for hosting one of the events -- it's been a while! Either August or May would work for me (there's some chance I won't be around for the March and November ones, depending on the exact dates).

Quote from: Chulk on February 17, 2024, 07:24:50 PMgotta get to it!

That's the spirit!  8)
#48
Stunts Chat / Re: Stunts WIKI
February 18, 2024, 06:30:42 PM
Quote from: alanrotoi on September 21, 2023, 12:53:06 PMThe team needs a stunts wiki article :D

Done!  :D The text is a basic stub for now; I encourage the team's members to expand it  ;)

You'll also note I have added a team infobox, mostly to make current and past members easier to spot at a glance.

@dreadnaut : I have enabled Extension:ParserFunctions for the sake of tidier optional fields in the infoboxes (I plan to experiment with that on the car infoboxes as well). Both the additional string functions (abominations) and Scribunto (YAGNI?) remain off for now.
#49
Competition 2024 / Re: ZCT271 - Dopamine Pathways
February 18, 2024, 05:30:43 PM
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  :)
#50
Team Zone / Re: Teams for 2024
February 17, 2024, 01:33:48 AM
I am thrilled to announce that, having accepted Cork's offer, @Spoonboy is now a member of Cork's Crew -- welcome!! 🥂
#51
Quote from: Cas on February 15, 2024, 10:05:30 PMHow 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? :)
#52
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:

#53
Stunts Chat / Re: Browsing that old drawer...
February 13, 2024, 12:52:17 AM
Quote from: Duplode on April 05, 2009, 02:20:14 AMObviously 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!)
#54
Chat - Misc / Re: Association game
February 08, 2024, 05:34:46 PM
Moonwalk
#55
@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.
#56
Car Archive project / Version management and coexistence
February 03, 2024, 09:33:39 PM
Here go a few thoughts about handling different versions of the same car. I'll begin with a @dreadnaut quote from another thread:

Quote from: dreadnaut on January 29, 2024, 09:42:23 AMYou 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:

Quote from: cars/README.md in the GitHub repoFor 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.
#57
Car Archive project / Re: Car repository indices (CRIs)
February 03, 2024, 12:18:08 AM
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.
#58
Car Archive project / Re: Car repository indices (CRIs)
January 30, 2024, 11:45:00 PM
Quote from: Cas on January 30, 2024, 05:26:49 PMThere 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...)
#59
Stunts Chat / Re: Stunts pages
January 30, 2024, 11:31:57 PM
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!
#60
Stunts Chat / Re: Your best track(s)
January 30, 2024, 11:15:12 PM
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  :)