Messages

If all cars are going to be in Zip format, that structure is perfect. One thing I could point out is, suppose that for some reason a car is not zipped, then how would a link to the individual files be specified?  Maybe just take the same zip directory and get to the last slash.

I would put zip files as a requirement. Cars are distributed like that to begin with, they are easy to link to, they reduce the risk of losing files along the way by forgetting or overwriting (e.g., readme.txt files). Much easier to compile the index for competition managers.

If the index contains the cars names, tools don't even need to open the zip until they copy files into the stunts directory, so "garage" folders would contain a tidy list of zip files.

YAML and a basic INI file are equivalent in terms of expressive power for what we would do here, so it might be better to implement full INI support than partial YAML 🤔  Less ambiguity in the future.

Is it worth at least converging to one format? Apart from the difficulty that @Cas would have building a YAML parser, which I realised going through the spec, it would save consumers effort.

A search or multiple-car request to the Archive would respond with something like this:

Code Select Expand

[PMIN]
name = Porsche March Indy
nickname = ...
urls[wiki] = https://wiki.stunts.hu/...

[CDOR]
name = Melange XGT-88
nickname = ...

Which is basically the same content as the example in the first post. I could extend it to make it explicit where to download the zipped version

Code Select Expand

[PMIN]
name = Porsche March Indy
version = dsi-1.1
zip = https://stunts.hu/cars/PMIN/dsi-1.1.zip

while the list of files in the repository index could be specified as

Code Select Expand

[PMIN]
name = Porsche March Indy
version = dsi-1.1
files[] = readme.txt
files[] = CARPMIN.RES
files[] = STPMIN.P3S
files[] = STDAPMIN.PVS
files[] = STDBPMIN.PVS

[...]

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.

Well then, I've put online a first version, and added three cars:

- https://stunts.hu/cars/CDOR
- https://stunts.hu/cars/ZGT3
- https://stunts.hu/cars/ZF40

I've converted the yaml files to INI to make them easier to consume by low-tech tools. I've dropped the descriptions: multiline and INI files don't get along, and it makes sense to keep the archive dry — the wiki can have a longer description.

Good, then yes, we're approximately on the same page

I am uncertain, I wonder if I managed to be too vague   I'll go direct, apologies in advance if I will sound blunt:

I think the "CRI" as described above are a bad idea which creates duplicate work for anyone interested in "listing cars" for whatever reason, and ambiguity by spreading car files around — which was exactly what we wanted to avoid by having a single car archive.

But I'm going to leave this to you folks this year.

Someone else will have to take initiative here. You 🫵 are the right person for the job!

1. propose some dates
2. prod people to sign-up
3. create a calendar

The Car Archive is meant to work like a wiki, where anyone can go and add cars. If you know that car CDOR exists, you can look for the latest version at https://stunts.hu/cars/CDOR.zip.

That is meant to avoid multiple people having to collect files, make sure they have the latest version, zip them up in a consistent format, keep their page up to date. Anyone can still build a website with their favourite list of cars, but they can defer the boring work to the archive.

In this model, all that a website, competition, etc... needs to publish is a list of card identifiers.

My suggestion would be to separate the list of cars from the cars files: competitions publish a basic list (e.g., CDOR, PMIN, PCAR, ZF40), and a tool can retrieve the needed cars from its favorite archive front-end.

This way there is only one place that needs to know about which files are needed for a car. And we avoid the risk of two sources defining different files for the same car.

ZakStunts already publishes the list, at least in one format:

- https://zak.stunts.hu/api/seasons/2024
- https://zak.stunts.hu/api/seasons/2024/cars

In the future, I would probably replace the car details with links to the archive 🤔

Cas' Repo definitely belongs on the list!

I spotted Old'aVista and of course I had to search for Stunts. I found this archived 1999 page for a Stunts webring

- www.geocities.com/siliconvalley/2536/joinring.htm

At the bottom there's a list of related newsletters, and links to the ring's websites: Lukas' and Kalpen's are there of course, before moving to its own domain! Quite a few I had not seen before

My preference would be to move all details from the portal to each competition page in the Wiki, where they are easier to edit, and then replace the many banners without information with a single link to the Competitions category. The portal would then represent the live community, while the wiki would be its archive.

Then we have more space on the portal for... <suggestions welcome!>

I have created a new portal page for inactive competitions, so they are gone from the home page.

1. Do we have Wiki pages for all competitions? Can you help me compile a list so I can link to those pages from the inactive competitions list?

2. Let's restart this thread: what do you think should appear on the Stunts portal?

I think we should have more links out to cool resources!

With that in mind, I've added a links page under the portal, and the first handful of websites that came to my mind. We need more though!

Ideally, that page should include only links to websites that:

• talk about Stunts, or Stunts and DOS games, or close enough
• we know of, admire, have interest in
• are a work of love

I would exclude soul-less directories, anything even remotely spammy, but also super-experimental stuff that might disappear at any time.

This thread is to discuss the page, but more importantly to suggest links to add! Would be great to hear why a website deserves to be on our list, and to have a brief description I can add to the page.

Thank you all!

Let's stick to identifiers as primary, unique key. We can handle duplicates when (if) they arise.

Beyond the methods discussed above, we can also rename the car, but add a alternative-ids property to list any aliased ones.

Prior art: ZakStunts own cars.ini, compiled over the years

One more question, and a difficult one: how would we store a car that has both a 1.0 and a 1.1 version, with the same car id?

A few options I can think of:

- No no no, the archive is only for 1.1 cars
- Mmmh, should we have two separate archives?
- Two root directories?
- Append the version if needed? So CDOR, but PMIN-1.0 and PMIN, or similar?
- Two versions under the same car-id directory? Like PMIN/1.0 and PMIN/1.1
- Very few cars have a 1.0 version, handle that as an alternative version, and consider 1.1 the default? E.g. PMIN/ and PMIN/stunts-1.0

At first look, I think I prefer the last one, but I'm looking for feedback.