Messages

The version being specified is indeed important. What about several versions of the same car when the author makes an upgrade?  Just curious. But it does sound good.

Having the internal files specified like that does help. Of course, one could just unzip the file and look, but being able to gather the file names from the list itself is quicker.

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.

About YAML files, I don't think it's difficult to read a specific YAML file and they look good, in contrast with JSON. My concern was about having to support the whole YAML spec, which is very large, just to read a specific case, since that would either force me to include a 3rd party library and make my code large or have dependencies... or, write a very long parser that could have bugs. Yet, whenever it's sufficient to just parse a specific case, that's not a problem for me. This other format does look very simple indeed.

Ah!  Great tribute!  Honouring one of our greatest legends. Uhm, which is that track on the left hand side?  It's not AbuRaf's Avenue. Maybe a track he won on?

Really convenient!  The only thing I had done in that regard was when Daniel3D asks me to auto-generate a spreadsheet with the car specs. Not sure where I left the program that generates that. But it's a lot better to be able to just select which cars and characteristics you want to compare, like you do here

Uhm... was the purple Lambo in the default replay already present in the DOS version?  I don't remember because I never let the demo play, ha, ha. I used to when I had 1.0, but there I had a different demo

Hey, I think this got too complex. I've realised the solution for all of us is very simple. When we see something we don't like, we tend to feel that our work is being sabotaged and we have the urge to respond quickly. I understand Dreadnaut perfectly on this because I feel the exact same way. But we both know this is just a feeling and we really just want to do our work and follow our plans and develop. So... I cooled down and thought "what is it that is causing the problem and how can we get rid of only that?"

Well, the idea I proposed initially was that CRIs should have: an ID, car name and list of files. Any more information can be there, but is not necessary. Now I think we just need to restructure it this way: an ID, car name, list of files and where to find them. With that, the conflict is over. Example (doesn't have to be this format):

Code Select Expand

car:
 name: Porsche March Indy
 id: PMIN
 files:
 - pmin.zip
 location: https://whatever.com/car
car:
 name: Some Custom Car
 id: SCCR
 files:
 - carsccr.res
 - stsccr.3sh
 - stdasccr.vsh
 - stdbsccr.vsh
 location: http://this.otherplace.net/carfiles
This means that, if I want to grab pmin.zip, I'll curl it down from https://whatever.com/car/pmin.zip and if I want to get stdasccr.vsh, I'll go and download it from http://this.otherplace.net/carfiles/stdasccr.vsh.

Done. So, if you have a tournament and want to host your cars, that's OK. If you want to have people get them from the Archive instead, it's OK too. I don't get into convincing people to do either way. But, regardless or where the cars are located, you, in your site, provide the list, the CRI, which is the thing that doesn't make sense to centralise. There really isn't much philosophy here.

Like always, I'm open to ideas on what to add or change. I just don't want to be told not to develop something. I'm trying to cooperate here. I hope that is always clear.

This is really good!  So the report would separate the list of differences by car ID, in the same format, right?  Very useful for somebody who's working on a car and needs to check without going back and forth between existing cars.

I still have to release a car of my own!

Yeah, I got that feeling from our previous discussion in the previous posts of this thread, but I still think we're on the same page on what the Car Archive intends to do.

Well, to clarify on my end, I don't intend to duplicate anything. I 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. This should not interfere in any way with the Archive. That's to explain the idea I originally came with and I still have.

Now, after our conversation here, I have taken what you said into consideration and developed a different idea (in addition, not to replace the other one), that is that, sometimes somebody will want to be able to retrieve a list of cars, but not a repository. For example, currently, ZakStunts does not provide cars, but it does provide a list of allowed cars for each season. This may change with the Archive, but it's still something that may happen in other occasions. So the garage should be able to retrieve the list of cars from a "CRI" like the one there, but it'd be a group, not a repository. The user would have to have the cars locally. It'd nevertheless be useful, because it'd help them quickly configure their Stunts to have ZakStunts-allowed cars at hand.

I apologise for making it all too long. It's always very hard for me to summarise my ideas, especially when I'm trying to prevent clashes and conflicts. As you already know from me, I like to create and I usually have no problem to retouch, but I don't like abandoning productive ideas. I try to count to ten before replying because I tend to be more clashy otherwise. I think we both know this feeling.

That's really good!  It prevents unnecessary dependencies on third party libraries and reduces the chance of bugs on independently developed software.

I did the best I could with group handling, but I can tell you that that bit about the behaviour of unknown cars was partly luck. I'm very happy with the result, though!  When you list a group, Pretty Garage will try to identify where each car is found. It'll first look for it in Stunts and then in the garages in order. It'll report where the car is found and leave it as unknown otherwise. If repositories are added, I'm not sure yet if the listing should fall back to them if the car is not found in any garage, but if I do that, definitely repositories and online-based groups should be different things.

Yeah, I've realised too late that I could've been more flexible with window resolutions. Also, FreeBasic had a bug in the past when the program decided to change resolution at run time. It doesn't have it anymore. Now Bliss and CarWorks are designed for a fixed size and changing the resolution would mean a lot of modifications. For Bliss, maybe I go for version 3.0 at some point. The more I learn with this project, the more I'll be able to apply later.

Simple things that can't be done and I want to implement:

• Ability to remove groups from the interface
• Ability to create and remove garages from the interface
• Ability to reorder groups and garages
• Maybe auto-selecting a single car with the left mouse button if none is yet selected

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.

Good, then yes, we're approximately on the same page
I've been thinking about this and looking at the two links from the ZakStunts API. The second one, I realised, would be a CRI except it doesn't include links to car files, but then I thought... sometimes it's useful to be able to download a list even if the list doesn't provide such links. It'd be like creating a group in the garage, but instead of having to do it manually, you query online and so you can automatically generate a group with the cars used in ZakStunts this season or in CCC for this race, or the cars made by Alan Rotoi, or something like that. Since you say you'll probably change this format once the Archive is up, I'll leave ZakStunts for later, but generally, what I'd be interested is in something like https://zak.stunts.hu/api/seasons/2024/cars. It doesn't matter if you can download cars from it or not and if you can, it doesn't matter if they're stored locally or somewhere else.

When the Car Archive is ready, there could additionally be something to allow obtaining cars in general. There, the list would be less important, because it'd be just the "list of all cars".

Alright... so how about four live race events this year?  Like we've done before, the four of them on a weekend and for each case, we decide on which day and time within the weekend. To split them more or less evenly, I'd suggest something like:

• First event: March
• Second event: May
• Third event: August
• Fourth event: November

By default, say, second weekend of each of these months, but the organisers can pick another weekend in the same month. This is just an idea. I would happily pick the first or second event and optionally accept a co-organiser.

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.

Uhm... I think these are two different things. That is, I agree with the idea and it's good, only I was trying to refer to a different aspect of it. Let me explain...

The Car Archive is meant to be a centralised project, which makes sense. The idea is that there's an official place where you can find a car so that you know that that one is the "official" one and that all cars you look for will be at that spot, but as I see it, this centralisation has more to do with the information the car represents than with the files that make up the cars, even though, of course, those will also be available there. In other words, it's the identity of the cars that's protected by this centralisation. Do I see it correctly?

Now, as regards availability, it's best to have as many sources as possible. Just as identification works better centralised, mirroring strengthens availability. It is because of this that we've been gradually developing several car sources. So, given that I see that there exists Mark's site and also Southern Cross and CCC has cars and ZakStunts already has cars too, etc., it's those sources that I've been seeing as "repositories". The Car Archive is a much more ambitious project with a lot more to do than what a simple repository does. It can, of course, also work as a repository, but if I've understood it well, that's not the main idea.

CRIs are descriptors for repositories. One for each. The idea of having them contain this info is that one can just curl them down from a web address, no need to send any special information, and then, once the list is down, there's no need to keep on interacting with the website unless one actually wants to download a car. This minimises information exchange. Besides, the CRIs can be cachéd and updated every now and then (at the client side). So anybody can go up and set up their own repository freely.

As regards which files, it could be all zipped or separate. If zipped, the garage program would realise and unzip the file after downloading it. It may be better to not have several cars zipped in the same file, but if that were the case, we can still refer to the same zip file for all cars involved. The important thing is that the program knows which file has to be downloaded and from where. Downloading a file this way would also be a simple curl. No need to exchange packages of specialised data.

The Car Archive API is very useful if you want to retrieve information from cars and I suppose, give it a filter and have it return a result, complex things like that. I could implement that too, for example, if there's an option in Pretty Garage to find all details about a car you have or to obtain the latest official version, etc. But that's a different thing. It's two different features.

As I mentioned in the thread about Pretty Garage, I'm ready to develop the part that interacts with repositories. This is not something only for the Car Archive or sites like Mark's Stunts Custom Cars or Southern Cross, but it can also be very useful for tournaments. For example, Daniel3D has expressed his interest in implementing this for CCC and ZakStunts, which every season has a set of allowed cars, could provide a list of allowed cars that way. In R4K, it depends on the race, but there could be a list of cars that can be downloaded there too, although it wouldn't be as important.

I call these lists CRIs because that's what they are, car repository indices. The format could be any we agree on or there could be several, as Dreadnaut said they could in the other thread. What's important is what information at least has to be present in the lists. For my garage program and probably, for any garage program, what seems important to have is a list of the IDs of the cars with their names and the list of the file names each car includes. This latter could be the car files themselves or a zip file containing them, but the program interfacing with it should know which file or files can be downloaded. There could be more info, but it's not necessary.

I can make my program able to read more than one format, but I'd like to agree on at least one to know it'll help. Dreadnaut gave an example of a YAML file for an individual car configuration, with much more information. I wonder if it'd be good to have a file that just contains the whole config for all cars in blocks, or to separate these two things, have the individual configurations as one file for each car and have the car list only have the basic info. I think that'd be better, but I'm open to ideas. If the list is YAML too, it could be as simple as something like this:

Code Select Expand

---
car:
 id: PMIN
 name: Porsche March Indy
 files:
  - CARPMIN.RES
  - STPMIN.P3S
  - STDAPMIN.PVS
  - STDBPMIN.PVS
car:
 id: CDOR
 name: Melange XGT-88
 files:
  - CARCDOR.RES
  - STCDOR.P3S
  - STDACDOR.PVS
  - STDBCDOR.PVS
.
.
.
I would be writing a very simple parser that only reads this, of course, so if somebody would add some extra YAML thing, such as a multi-line or quotes, or a car has "file: PMIN.ZIP" instead of "files:" and a list, then it'd break. I don't want to write more code than necessary, so that's what I would like to agree on these details. What do you guys think?