Future of the car collection at Southern Cross

[alanrotoi]

Ooh I get it! thanks! Yes, that's better.

[Duplode]

Why a backend source? Is it safer?

As @Daniel3D said, the goal would be avoiding duplication of efforts, and having a single source of truth for the data.

One caveat is that the default configuration of the Wiki doesn't provide a way to fetch external data, so we would need to do some research to try and find a way to incorporate metadata from such a repository into it. (From a quick glance at the docs, it looks like Extension: External Data might be enough, though we'd want to consider it carefully). Also, there seem to be some disadvantages in displaying external images in the Wiki, so we might prefer to consolidate image uploads in the Wiki. (Files uploaded to the Wiki get predictable URLs, so I don't think we'd have a problem with getting stable links.)

What about an archive directory where...

That does feel like the proper way to tackle it, details to be hashed out aside. For the implementation effort to be worth it, though, I think we'd want to have buy-in from @KyLiE , who is maintaining the unified collection we have right now, and possibly from car creators in general. Git is probably the right way of setting up the repository, from a technical point of view at least. Familiarity with Git might be a bit of a concern if we are aiming at a larger number of maintainers -- though I guess that, if need be, we could easily introduce the basics needed to update the repository over a chat session 

[Duplode]

Eleven months have gone by, and nothing really happened towards deactivating the Southern Cross car collection. Inertia or indecision, you name it, but maybe there's a point in it still existing for the time being (if nothing else, the inbound links won't vanish at a snap of my fingers) That means it's about time to make sure it remains useful, to the extent the current format allows.

The first concrete step, then, is something that I should have done a long time ago: temporarily hiding links to outdated versions of cars by Ryoma whose performance has changed since the first half of 2021. That is the sensible thing to do in order to avoid further spread of potentially incompatible versions (I know, for instance, that @Spoonboy was bitten by that in a R4K race -- sorry!). Over the next few days/weeks, I'll gradually re-add Ryoma cars, prioritising those that aren't available from KyLiE's site.

(By the way, it's worth reminding that thanks to @dreadnaut we now have a laid out vision of what a unified car archive, as in the discussion upthread, could look like!)

[Cas]

You guys let me know and I make sure Simple Garage follows the guidelines for that. I could even give it an integration so that you can directly install cars from Simple Garage by downloading them from a repository that follows the format, being it SCR, Mark's site or anywhere else

[Daniel3D]

You guys let me know and I make sure Simple Garage follows the guidelines for that. I could even give it an integration so that you can directly install cars from Simple Garage by downloading them from a repository that follows the format, being it SCR, Mark's site or anywhere else

That would be awesome. I could make an update to the stunts menu (that I use for CCC) that check's the required cars for the race and installs the cars if needed.

[alanrotoi]

That would be awesome indeed.

[Duplode]

Over the next few days/weeks, I'll gradually re-add Ryoma cars, prioritising those that aren't available from KyLiE's site.

First step done: several of Ryoma's cars have been re-added to the car downloads with updated versions; additionally, a number of others that weren't easily available elsewhere were added. There will be at least a second batch of additions, in which I'll also bring a handful of cars from other authors into the mix.

[Cas]

That would be awesome. I could make an update to the stunts menu (that I use for CCC) that check's the required cars for the race and installs the cars if needed.

Yes!  Car repositories don't necessarily have to be car archives. That's one possibility, but they can also be tournaments. A tournament can provide a CRI (Car Repository Index) with the list of cars for that season, then you go to the garage program with the repository address configured and whenever you want, you can tell it to put all those cars in your Stunts or garage.

There will be at least a second batch of additions, in which I'll also bring a handful of cars from other authors into the mix.

I would like to know if you and Dreadnaut want to set up CRIs for Southern Cross, ZakStunts and the coming Car Archive, so that I can prepare Pretty Garage to recognise the format. I'll be discussing more details about it in that subforum.

[Duplode]

I would like to know if you and Dreadnaut want to set up CRIs for Southern Cross, ZakStunts and the coming Car Archive, so that I can prepare Pretty Garage to recognise the format.

I'll be happy to set up Southern Cross so that Pretty Garage can use it as a source. There are several caveats, though:

• The current incarnation of Southern Cross collection is not meant to be exhaustive, and most likely will remain pretty far from that, so it won't give a full picture of what is available to a Stunts pipsqueak.
• A means of integration that makes sense for Southern Cross might not be a good fit for the future Car Archive (cf. my reply on the other thread).
• In the long run, I expect the Southern Cross collection to be fully superseded by the Car Archive, at which point switching sources will be the sensible thing to do.
• I'd prefer to avoid doing any major changes to how the files are offered at Southern Cross (e.g. coming up with some tidy directory layout), given how #3 means any such effort is expected to become obsolete.

That being so, if we're doing this I suggest sticking with a simple format, which allows retrieving files from Southern Cross as it currently exists while carrying as little information as you can get away with -- the expectation being that both the format and the Southern Cross collection will be superseded in the future.

[Cas]

Yep. That could be... Let me answer to your points first...

1. The repositories in Pretty Garage are not meant to be exhaustive. Quite the contrary, the idea is not to represent "all the cars", but the cars that are present at each site.
2. As I said in the other thread, the Car Archive is a very different and more important project. I wouldn't call it a "repository" although it could be interfaced as one. Pretty Garage is not meant to be a client for the Car Archive, but a client for repositories in general. A client for the Car Archive would not be a garage program. It'd be more like a browser, the way I see it, with the capability to download files too.
3. Yes, that may be the case with Southern Cross' repository because the cars there are a general group. For some repositories, there is something linking the cars contained there. For example, in CCC and ZakStunts, there is always a set of cars that can be used for the season (for ZakStunts) or for the current race (for CCC). Regardless of cars being available at the Car Archive, one will still be interested to know which cars currently exist at those repositories. It'd be very useful to be able to quickly download and update the cars for the race you're going to participate in. Mark's collection is also general, yet I don't think he'll consider his repository "superseded"... It's kind of personal, but that's another story.
4. The simplest way to do this would be to run a script, say, a php page, that would look at the directory and take note of every car it finds and build a list. This is easy to do if the files are loose. If they're zipped, there is no way for the script to tell what car that is unless they have predictable names like <car_id>.zip. Anyway, there's no hurry or push to do this. I'm just offering to pick a format that's comfortable for whoever wants to implement this. That's all.

I can think of simpler formats than the YAML one I posted, but that's also relatively simple. An INI format would be even simpler. But I've no problem. The information is simple so I can parse most formats. If it is for testing, I can test this with local files. It's not that I'm needing to implement it on every repository site. Not trying to cause problems here, just offering cooperation with formats.

[Duplode]

Mark's collection is also general, yet I don't think he'll consider his repository "superseded"... It's kind of personal, but that's another story.

Mark's collection does differ from Southern Cross in an important way: while we use it as a general collection, it is also a primary source for Mark's bug fix releases. Then, at the other end of the scale, there is Ryoma's Mega, which is pretty much strictly a primary source.

My main point here is that, looking at it from the opposite direction, I don't want for Southern Cross to create requirements for CRI/Pretty Garage. Southern Cross can be a source, but it's best not to grant it too much influence over what the format will be -- the competition sites, at least, will likely be more important sources in the long run, so their needs should have a bigger sway.

As things stand, the car collection page at Southern Cross is written entirely by hand. I could (and arguably should) have automated its generation at least in part -- say, by reading the data from a CSV file in the static site build process. Implementing that so I can have a CRI file generated automatically won't be a big deal -- my hesitation is not about writing code, but about committing to some kind of archive organisation, specially if doing so risks influencing how the broader project(s) will evolve.

As far as Southern Cross is concerned, a simple YAML format along the lines of what you posted in the other thread is good enough, and we can work out the remaining details from there. If other sites add extra requirements for the format, Southern Cross will try to follow them, but it shouldn't become a roadblock for the whole project if it somehow can't.

[Cas]

I agree. I'm asking about formats on the forum because I wouldn't want a wide proliferation of random formats or procedures. I'm not wanting to come up with a format that you should implement. It's more like, if you're going to implement anything, let me know so I can read that too. And preferably, if tournaments and sites begin implementing these things, it'd be good if they did something similar, to prevent this proliferation.

YAML sounds good. JSON is a headache. I can read some ZakStunts stuff, but JSON always forces me to implement "tricky parsers" with a higher chance of bugs. Besides, JSON defeats its own purpose of being human readable sometimes, while you could practically come up with a YAML compatible configuration file and not realise you're doing it. Same thing happens with the "pre-INI" format I normally use. It's been used many, many times and it's the most intuitive there is, so much that MS built their INI files based on it and it doesn't even have a name, ha, ha.