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

Main 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

Chat - Misc / Re: Association game
February 08, 2024, 05:34:46 PM
@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.
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/ 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.
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.
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...)
Stunts Chat / Re: Stunts pages
January 30, 2024, 11:31:57 PM -- Nick's Stunts Page, lovingly preserved from the Geocities era to the present day by another Nick -- or is it the same one? -- Nice recent (December 2023!) French review. Links to us!
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  :)
Team Zone / Re: Teams for 2024
January 30, 2024, 11:08:15 PM
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.
Team Zone / Re: Teams for 2024
January 30, 2024, 04:27:06 PM
Quote from: Daniel3D on January 30, 2024, 02:19:42 PMI 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.
Team Zone / Re: Teams for 2024
January 30, 2024, 11:31:09 AM
Going back to this discussion...

Quote from: Daniel3D on January 09, 2024, 11:05:59 AMI 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.
Car Archive project / Re: Car repository indices (CRIs)
January 29, 2024, 01:37:44 AM
After a nice chat with @Cas about this topic, I now have a better understanding of how CRIs are meant to work. In particular, I no longer feel they clash with the vision we're going for with the Car Archive. Below is a summary of why I have changed my view.

The key point is that a CRI does not belong to a repository, nor it is meant as a manifest of the full contents of a repository. Rather, a CRI is at heart a Pretty Garage group definition, with added information on how to obtain the car files from chosen sources. The goal of writing a CRI should not be describing or exposing the contents of a car collection, but merely offering Pretty Garage the means to fetch a selected group of cars.

Here goes a concrete example of an use case. In the future, when the Car Archive is fully functional and the Southern Cross collection has been made obsolete by it, I may nonetheless want to provide an easy way for visitors to the Arrabona project to download the set of custom cars that were used in USC. One way I might accomplish that is by making a CRI available. This CRI would list the USC cars and specify the Car Archive as the source from which to fetch them.

The example illustrates two aspects of how CRIs can be put into use. Firstly, there need not be a conflict between sites offering their own CRI files and centralising downloads and metadata at our consolidated Car Archive: to promote centralisation, all we have to do is to encourage site admins to use the Car Archive as the source in their CRIs. Secondly, while in theory I might try writing an omnibus CRI file indistinctly covering the whole legacy Southern Cross collection, that's not the intended usage for the format, or even a particularly useful thing to do. Pretty Garage is primarily not a remote collection browser, but a local collection manager, and an indistinct omnibus group makes little sense in that context.

CRIs, then, are not an alternative way of defining repositories, but a way for Pretty Garage, or a client like it, to access repository contents. Now, there might be finer aspects on the interaction between client and repository which might affect the CRI format -- for instance, perhaps using directly using URLs for the files will prove inconvenient, and it will be better for the file to just point to the Car Archive root and let further talk to be done through the API. Those, however, are technical decisions we can work out, rather than fundamental philosophical disagreements. 
Quote from: Cas on January 28, 2024, 08:23:19 PMSo the report would separate the list of differences by car ID, in the same format, right?

Yup: it prints the diffs in that format, separated by headers with the pair of file paths. Here's a sample:


Car {gsna = "Shamal\NUL" /= "Sha\NUL", simd = Simd {carMass = 29 /= 34}}


  { gsna = "Thema\NUL" /= "T832\NUL"
  , simd = Simd {carMass = 28 /= 30, brakingEff = 256 /= 285}

Lately I've been using the tool to detect performance changes between different releases of cars, and it's been very helpful for that purpose.
Car Archive project / Re: Car repository indices (CRIs)
January 28, 2024, 05:59:29 PM
Quote from: Cas on January 28, 2024, 05:24:52 AMI am aware that repositories already exist and have existed for a very long time. I only want my garage program to be able to access them as well as the Archive and I would like that, if anybody happens to have an repository for any reason (for example, it'd make sense for a creator to want to have their own car repository with their own cars even in spite of the existence of a centralised archive), they can easily gain access to their own files through Pretty Garage.

Quote from: Daniel3D on January 28, 2024, 05:00:50 PMIf it needs to match the level of detail the repository has, I don't know.
Maybe pretty garage can automatically generate the ini based on the source (for instance ryoma) or combine it with archive information (in case of and updated version of Mark)

Here, I think, lies the core issue. In abstract, we can think of something like Cas' initial design for CRIs as a way to make the downloads in any Archive-unaware site (for instance, Southern Cross) accessible to tools like Pretty Garage. @dreadnaut's point, however -- and I tend to agree with him -- is that introducing a second repository format at this stage would put at risk some of the advantages in having an unified archive (a crucial one, for me, being clarity about car versions). It would also disperse efforts when we'd really want to concentrate them instead. (Ergo my insistence in that the Southern Cross collection will be superseded by the Car Archive once it becomes fully functional, and any improvements to the former should be regarded as addressing a temporary situation).

The Android app store/Linux distro repository analogies don't really work once we allow two different formats. For that model to work well, you'd want to have all source sites running the full-blown Car Archive software (or at least offering the same interface) and providing cars through the same format, so that tools can learn and meaningfully decide about available versions, rather than being limited to a minimal set of fields shared between two formats. While this is a good model in theory, I don't think it is realistic for us as a general solution, as I can't see it being accessible enough for creators universally wanting to provide their cars in such a way from their own sites.

The alternative design Cas mentions is a more natural fit for working in tandem with the Car Archive. It could play out like this: a site (competitions would make for a typical use case) makes a list of required cars available from a file (that would be essentially a Pretty Garage group definition, perhaps optionally augmented by exact version specifications whenever that becomes necessary). Pretty Garage would fetch this list and use it to download its cars from the Car Archive (or any mirror thereof).
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: . As ever, feedback is most welcome!
Car Archive project / Re: Car repository indices (CRIs)
January 28, 2024, 02:49:58 PM
Quote from: Daniel3D on January 28, 2024, 01:23:08 PMPreferably only one backend, car archive, but mark will probably keep his up as he should.

Mark can flag his cars as bug fixed, since he only fixes graphics related issues.

There's a distinction here that I think we shouldn't lose track of. Mark's cars page is not just a collection of cars, but also a primary source for his bugfix releases. Other examples of primary sources include Alan's Google Drive, Ryoma's Mega, and even the threads in the Custom Cars board here. Primary sources will keep existing independently, because authors will share their new creations however they find most convenient, and we can't really demand them to do that through the Car Archive, or some other broader repository scheme.

In what seems to me as the most likely scenario, authors will release their cars in the usual ways (that won't necessarily be integrated into any database), and then the new car (or version) will be catalogued and added to the Car Archive (either by the author themselves or by someone else) in a separate step. On the one hand, independent primary sources will continue to exist, and we'll keep an eye on them for new stuff; on the other hand, when it comes to telling people where to find cars we'll point to the Car Archive, a consolidated, tidied up and convenient secondary source.

(A different approach to this distinction that, in theory, could be supported by the project, would be for authors to run the Car Archive software on their sites with a different repository of cars that provides the latest versions of their cars. Clients could then retrieve cars from different source repositories, kinda like how it's done for Linux distribution package repos. I don't actually see that as the main way new releases will be done in the future, though -- in particular, uptake is highly unlikely to be universal.)