Stunts Forum

Now that I'm finally doing the sorely needed behind-the-scenes cleanup of the Southern Cross site, it is probably a good thing to decide what should happen to the car collection there (https://scr.stunts.hu/mods.html#custom-cars) -- and your input will be very helpful for doing so.

For several years, I had tried to maintain Southern Cross as the primary place to download custom cars. However, except for adding the 19th Anniversary Melange, I haven't updated the collection there (https://forum.stunts.hu/index.php?msg=83362) since May 2021. To make matters worse, many of the Ryoma cars there aren't in their final versions, and I'm not even 100% sure if the downloads of them are replay-compatible with the ones used at CCC.

As things stand, the best maintained car collection around is clearly @KyLiE 's (see the Stunts Custom Cars page at https://www.markceccato.com ), and in fact I have recently added a note to the Southern Cross page recommending it. That, however, probably means I have to find some other role for the Southern Cross collection, as I'm not sure if there's much point in me (re)creating a second collection of individual car downloads with basically the same scope. Some of the alternatives include:

• Shutting down the main part of the Southern Cross collection, leaving only the old-school cheat cars and the historical curios.


• Switching the focus of the collection to car packs. (That would be a big U-turn, as the point of the Southern Cross collection originally was to offer individual downloads, so that people could easily pick just what they needed. However, the existence of Simple Garage increases a lot the usability of car packs, making this a more attractive option than it was ten years ago.)


• Figuring out a way to collaborate on a shared collection, set up so that it can be easily made available on different sites. (This is wild speculation, as right now I have no clue about what would be a good way to achieve that.)


• Restoring the Southern Cross collection in something like its current format. (You'd probably have to persuade me there's a point in doing so, though.)

So, how should the Southern Cross collection evolve? Is there any other possible role for it that I have overlooked? Please let me know of your thoughts, as I don't think I'll manage to find a good solution without considering your views.

I am very biased in this off course. Especially since Mark has been updating cars on minor issues. And my competition uses carpacks.

@Daniel3D But I would like to hear biased opinions too!  :) If there is still going to be a Southern Cross collection, I feel it should be made helpful for everyone, including competition managers, and not pointlessly duplicate work already being done by e.g. you or Mark.

The section of your website in question also includes mods and utilities, so perhaps it might be worthwhile focusing on those.  It depends on what you want to achieve and what the community calls for.  Honestly, I think that the custom cars available from each competition website fulfil the needs of most community members, both new and existing.

Since you mentioned my website, I thought I would let you know that I plan to continue working through Ryoma's cars, as well as any others that are released in the future.  I've been doing this since I joined the community, but it was only recently that I was asked to share my work, so naturally I thought my website was the best place to do that.

Cars, so many these days! I might diverge from the initial topic here, but I see three alternatives for keeping track of all of them:

a) Individuals set up a page with a collection

pros: cheap, fast, diverse
cons: separate efforts, individual responsibility

b) We hack something into the Wiki, so cars pages include the car files

pros: easy to edit, shared responsibility
cons: "hack something", likely inflexible, might break with an upgrade

c) We build a custom system

pros: shared responsibility, customisable, over time solid
cons: doesn't exist yet, will not make everyone happy

I like (a), it's the web, but the maintenance costs are real. I expect (b) to be a pain to set up, and in the long run. And of course I'm attracted to (c), but it's something that could take time to build. Then again, it could start by hacking together something like this (https://zak.stunts.hu/api/seasons/2023/cars). Imagine Simple Garage downloading cars or pack for you...

I favour the custom system as well..

Would it be possible to render a picture out of the car file? Like a view that you can see the front, side and top of the car. And then cycle through the paint jobs?

 8) #daretoask ..

Of course it would! It all depends on how much time you want to spend on it ;D

It's something I want in a car manager like simple garage as well...
So..

And it's not a question about how much time I want to spend on it... If I do it, we can wait until the sun dies....

Quote from: KyLiE on January 31, 2023, 03:34:28 PMHonestly, I think that the custom cars available from each competition website fulfil the needs of most community members, both new and existing.

Yeah, that's a factor too. The competitions are doing a good job of making the cars they use easily available. The main use case for a centralised collection is probably for people new to the community, who aren't necessarily racing in (our) competitions.

At the moment, I'm inclined towards removing most of the collection and focusing on the tools, as you suggest. I'd perhaps only keep a few large, thematic car packs (say, the custom cars used at UnskilledStunts competiitons, or the Ryoma cars featured on that testing thread from the 2022 pre-season). I'll wait a few more days before acting on it, to let the plans settle and keep listening to opinions.

Quote from: dreadnaut on January 31, 2023, 08:17:59 PMb) We hack something into the Wiki, so cars pages include the car files

I had a quick look at the MediaWiki docs (https://www.mediawiki.org/wiki/Manual:Configuring_file_uploads), it seems that to get something basic working we'd only need to enable zip uploads. That would give us a page for the download in the File namespace (arbitrary example from Wikimedia Commons (https://commons.wikimedia.org/wiki/File:TorpedoShip.STL)), a direct download link and version control. Restricted registration means we'd be in control of the uploads, and even if we open it up at some point file upload permissions can be defined separately. Still, I'm not too enthusiastic about suggesting we actually do that, at least not without a lot of thought beforehand, as once we get something like that into the Wiki, it will be tough to remove if it turns out to be a bad ides.   

What about an archive directory where...

• Each car gets a directory named after the four-character identifier
• The car directory contains:
• an optional readme
• one or more images of the car (e.g., side, top, front, fixed angle)
• subdirectories for each version of the car
• a human-editable, machine readable text file (e.g., YAML), including:
• name, author, etc.
• link to stunts wiki if a page exists
• version history, pointing to the data subdirectories
• We put the whole archive into a Git repository
• We push the repository to GitHub or similar
• We use the repository pipeline to upload the files to cars . stunts . hu, every time something changes
  
• The website renders car lists, a page for each car, and generates NAME . zip for the latest version
  

One day:

• pack information in the repository, with multi-car zip files generated by the website
• car search

Quote from: dreadnaut on February 03, 2023, 11:22:55 PMWhat about an archive directory where...

• Each car gets a directory named after the four-character identifier
• The car directory contains:
• an optional readme
• one or more images of the car (e.g., side, top, front, fixed angle)
• subdirectories for each version of the car
• a human-editable, machine readable text file (e.g., YAML), including:
• name, author, etc.
• link to stunts wiki if a page exists
• version history, pointing to the data subdirectories
• We put the whole archive into a Git repository
• We push the repository to GitHub or similar
• We use the repository pipeline to upload the files to cars . stunts . hu, every time something changes
  
• The website renders car lists, a page for each car, and generates NAME . zip for the latest version
  

One day:

• pack information in the repository, with multi-car zip files generated by the website
• car search

I love it.
I've been thinking about a similar setup for a car catalogue/webshop.
With pictures that have the ID in their name and metadata
So that you can search and filter.
Maybe we can use a single source for both.

Quote from: Daniel3D on February 04, 2023, 07:26:14 AM

Quote from: dreadnaut on February 03, 2023, 11:22:55 PMWhat about an archive directory where...

• Each car gets a directory named after the four-character identifier
• The car directory contains:
• an optional readme
• one or more images of the car (e.g., side, top, front, fixed angle)
• subdirectories for each version of the car
• a human-editable, machine readable text file (e.g., YAML), including:
• name, author, etc.
• link to stunts wiki if a page exists
• version history, pointing to the data subdirectories
• We put the whole archive into a Git repository
• We push the repository to GitHub or similar
• We use the repository pipeline to upload the files to cars . stunts . hu, every time something changes
  
• The website renders car lists, a page for each car, and generates NAME . zip for the latest version
  

One day:

• pack information in the repository, with multi-car zip files generated by the website
• car search

I love it.
I've been thinking about a similar setup for a car catalogue/webshop.
With pictures that have the ID in their name and metadata
So that you can search and filter.
Maybe we can use a single source for both.

Like the one in the wiki?

Quote from: alanrotoi on February 04, 2023, 12:08:10 PM

Quote from: Daniel3D on February 04, 2023, 07:26:14 AM

Quote from: dreadnaut on February 03, 2023, 11:22:55 PMWhat about an archive directory where...

• Each car gets a directory named after the four-character identifier
• The car directory contains:
• an optional readme
• one or more images of the car (e.g., side, top, front, fixed angle)
• subdirectories for each version of the car
• a human-editable, machine readable text file (e.g., YAML), including:
• name, author, etc.
• link to stunts wiki if a page exists
• version history, pointing to the data subdirectories
• We put the whole archive into a Git repository
• We push the repository to GitHub or similar
• We use the repository pipeline to upload the files to cars . stunts . hu, every time something changes
  
• The website renders car lists, a page for each car, and generates NAME . zip for the latest version
  

One day:

• pack information in the repository, with multi-car zip files generated by the website
• car search

I love it.
I've been thinking about a similar setup for a car catalogue/webshop.
With pictures that have the ID in their name and metadata
So that you can search and filter.
Maybe we can use a single source for both.

Like the one in the wiki?

A backend source with all metadata and images.

Why a backend source? Is it safer? (Lacking of knowledge, sorry if it's a basic question)

Quote from: alanrotoi on February 04, 2023, 01:23:03 PMWhy a backend source? Is it safer? (Lacking of knowledge, sorry if it's a basic question)

A backend source that contains all files and information. The Wiki could use for instance pictures and metadata but no downloads,
A competition page could show accepted cars and downloads but limited pictures and metadata.
A car catalogue could show all information and provide filters and search options.

But all from a single source database.
Then you only have to keep the source updated for all sites.
That could be as simple as an FTP site

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

Quote from: alanrotoi on February 04, 2023, 01:23:03 PMWhy 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 (https://www.mediawiki.org/wiki/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 (https://www.mediawiki.org/wiki/Manual:$wgAllowExternalImages), so we might prefer to consolidate image uploads in the Wiki. (Files uploaded to the Wiki get predictable URLs (https://www.mediawiki.org/wiki/Manual:Configuring_file_uploads#Upload_directory), so I don't think we'd have a problem with getting stable links.)

Quote from: dreadnaut on February 03, 2023, 11:22:55 PMWhat 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  :)

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 (https://forum.stunts.hu/index.php?topic=4186.0) of what a unified car archive, as in the discussion upthread, could look like!)

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

Quote from: Cas on January 14, 2024, 04:45:11 PMYou 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.

That would be awesome indeed.

Quote from: Duplode on January 10, 2024, 02:49:55 AMOver 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 (https://scr.stunts.hu/mods.html#custom-cars) 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.

Quote from: Daniel3D on January 15, 2024, 09:45:22 AMThat 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.

Quote from: DuplodeThere 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.

Quote from: Cas on January 26, 2024, 11:07:03 PMI 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 (https://forum.stunts.hu/index.php?msg=92346)).
• 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.

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.

Quote from: Cas on January 27, 2024, 02:41:58 AMMark'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.

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.