Car archive

[dreadnaut]

We need to start somewhere: https://github.com/dreadnaut/stunts-cars/

Comments, suggestions, thoughts: everything welcome!

[Cas]

I had been thinking of auto-generating car images viewed from the side to make a graphical garage, but had not considered SVG. It would be a nice thing to have, as the same image could be used for many things. My idea was to just generate a large bitmap, then scale it down to average colours and produce a softer image.

I don't understand most of the concepts in the idea, but it sounds cool!

[Daniel3D]

What about adding the txt file in resources as info####.txt or info####.nfo
in this case infoCDOR.txt

And an multi platform accepted thumbnail image.
Img1CDOR.bmp.. (or tif, gif.. whatever is most convenient for programmers)

That way the car files are extended to 6 and include metadata and an image (or a few).
And can be used by other tools, like car managers.

[dreadnaut]

What about adding the txt file in resources as info####.txt or info####.nfo
in this case infoCDOR.txt

In my mind the archive is not meant to invent a new standard, that we cannot (and should not) impose on car makers, but to work with whatever they create — be it 30 years ago, or today. I think this is where tools that can generate images from the car files come in. Structured data would also live outside the car files, in the archive itself.

Part of the plan is a front-end to the archive itself, that can make data and images available in a consistent way:

- car makers make cars as they prefer
- the archive collects them and compiles details
- front-end generates images and offers a standard interface (e.g., zip files, previews, etc)
- tools can talk to the front-end and download data or files

[Cas]

Simple Garage does support a very basic additional car file. I think it's CAR*.CFG, but I don't remember. If it's not there, everything works as usual. If it's there, you can specify the author and version number. I would have to check back on the code to remember the details.

An interface for a car archive does sound great indeed. Lots of integrations and exchanges can result from that

[dreadnaut]

After adding a first car I'm starting to think that Markdown might not be a good idea. Yes, one can write free text, but a free text description would be a minor part of the archive. The most important information for each car is structured data: author, date, powergear yes / no, colours, etc. A brief description could be one of this attributes. This brings it closer to @Cas configuration files, and indeed those could be generated automatically.

The main bit would then be something like this:

Code Select Expand

---
name: Melange XGT-88
nickname: Melange
author: Alan Rotoi
year: 2013
colors: [ Blue, Red, Yellow, Light Grey, Brown, Black, Green, Purple, Striped ]
urls:
  wiki: https://wiki.stunts.hu/wiki/Melange_XGT-88
description: |
  Alan's much-loved machine is a timeless classic with a long and proud
  history in prestigious contests. It is an IMSA pipsqueak with more than a
  few twists to spice it up.

With more attributes to come of course (suggestions?) and structure to be defined. But this feels like a more productive direction.

[Daniel3D]

Combined with the SVG images...

My idea was. If you make a database with additional information. Make it so that there are flexible uses for it.
Like a resource/database for other programs or the wiki...

[Erik Barros]

I still miss download links in the wiki, and in cases like Melange it would be cool the link to different versions.

[alanrotoi]

I still miss download links in the wiki, and in cases like Melange it would be cool the link to different versions.

I'll add my cars. They're already in a free access google drive.

[alanrotoi]

Ok added the download links from every car page and in the list of custom cars:

https://wiki.stunts.hu/wiki/Custom_cars#List_of_custom_cars

[Cas]

@dreadnaut - Yes, Simple Garage's config files are super simple, a lot more basic than that. I think they use the equals sign instead of the colon, but other than that, they're pretty much the same idea. As they have not been used much, I could follow your standard for the next version for exchange

[dreadnaut]

Next steps:

Find a decent initial set of car attributes
It will change over time, but it's helpful to consider use cases early. For example, the Custom cars page in the wiki has a few interesting column. What should the website for the car archive show?

Add a few cars to the repository
To road test the structure, in particular for cars with multiple versions.

Set up a rough web front
This can sit under stunts.hu/cars or similar. A simple list of cars, and links to download them, to prove that the repository data does what we need.

Write down a definition of the structured format
So that other websites can produce similar data, and tools can consume it.

Add all the cars! 💥

[Cas]

Sounds great!  Decentralised is better, like, same basic structure ("protocol", but more like directory structure and perhaps GET query, at most, something simple) and so you pass a base path or domain to a tool and it can browse or download from any car repository.

So car IDs, I guess, we keep using the four letter system that's default in Stunts. In other words, same four letters, same car, except version in any case. Right?  To follow DOS, it should be case-insensitive and most ASCII wouldn't be allowed. Safest is letters, numbers, and underscore. Daniël recently introduced the number sign. In DOS, extended ASCII was allowed, but this brings problems for new Unicode based systems. What do you think?

Also, would a repository be able to have several subdirectories, like several "garages"?

Your config file example is interesting. It allows for multi-line values and is multi-dimensional. Just checking on this idea to make sure we understand it the same way:
* Pipe as the first significant (non-space) in the value side of the colon means multi-line
* Lines containing no colon are ignored except as part of a previously defined multi-line value
* A line with a colon provides a key:value pair and breaks any previously open multi-line value
* Identations allow for nested key:value pairs
Am I right?

Here my only doubt is how to handle when you need to enter a colon as part of a text. In my older configuration format (with equal signs), an equal sign is allowed in the value because only the first one separates key from value, so not allowed in the key. I was also just ignoring indentations.

I imagine these two could be internally seen as identical:

Code Select Expand

default_color: blue
urls:
  wiki: https://wikiaddress
  author_site: https://authorsite
author: Overdrijf

Code Select Expand

default_color: blue
urls.wiki: https://wikiaddress
urls.author_site: https://authorsite
author: Overdrijf
Just some thoughts

EDIT: Another thing to consider... how about lines that begin with spaces? I would like a simple format that looks good to the human eye, doesn't need escaping, is easy to parse, yet powerful. I can think of some opitmisations

[Duplode]

Meta question: should we have a sub-subforum for this project? While my first impulse would be raising specific design questions and the like on GitHub, it's not likely everyone will be there to talk, and so keeping the discussions here would make sense.

[Daniel3D]

Meta question: should we have a sub-subforum for this project? While my first impulse would be raising specific design questions and the like on GitHub, it's not likely everyone will be there to talk, and so keeping the discussions here would make sense.

Thinking about it, and a bit broader..
The wiki doesn't have a place as well (or I couldn't find it quickly and that's basically the same thing)

Can we make subgroups underneath wiki and portal sub?

Stunts Forum & Portal

Anything about the Stunts Racing Portal

www.stunts.hu and this forum

Making subs below

• Forum
• Portal
• Wiki
• Repositories
• Car Database

~~~

• Track Database?