Messages

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?

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.

Alright. I have posted the first alpha version. As you can see, no car images yet. Editing the pgarage.cfg file, you can set your directories, window size and everything else.

Controls as of now, more or less:

• Right mouse button to select cars. Combine with SHIFT and CTRL
• Left mouse button to drag cars from one side to the other
• Left and right buttons on the right hand side panel to select a garage or group
• Ctrl+drag to create a group out of a set of cars
• Del to delete cars
• Shift to force actions that get denied
• Right mouse button at the top of lists to edit garage/group name and directories
• Esc to exit saving the configuration
• Ctrl+Q to exit without saving the configuration

Some things to point out:

• Dragging from a garage (or Stunts) to another moves cars and their files
• Dragging to a group copies a car (but not the files, of course)
• Dragging from a group to a garage finds the cars that are missing at destination and moves them from their source garages
• If a garage called something that begins with "Junk" exists, deleting actually moves cars there. Otherwise, it's permanent deletion and you get a warning
• Deleting from the Junkyard is always permanent deletion

[Pretty Garage 1.1 - 2024-03-08]

Pretty Garage 1.1 - 2024-03-08
Feel free to try it. You may want to edit pgarage.cfg before running the program. Still some things can be configured while you use it. Let me know if the controls are intuitive to you.

Previous versions downloaded 1, 5 and 3 times. Updating Zip


--- Original post ---
Enter Pretty Garage
As I have been mentioning in the forum and Telegram group, I'm currently working on a new garage program. I'll call it Pretty Garage because in contrast with Simple Garage, its focus is more about the looks and comfort, although I can tell you it's simple too.

The current state of development is advanced, except for one very important feature that hasn't been implemented yet: automatic generation of car images. I left it for the end because it takes time and the program can be useful even before it has that.

So, what this is about is a visual program that you can use to move cars between Stunts and one or more garages, create groups, etc., the things that Simple Garage does, but visual. My idea is for the car lists to display a little image of the car to the left of the car name and information. For now, that side is empty. I'll prepare an alpha version and compile it and then share it with you guys, in case you want to test it. I don't think it has too many bugs. It's very stable for an alpha, but you never know.

Repositories and CRIs
One feature I'm going to include and is not implemented yet is the ability to access online car repositories. With the soon-to-come Car Archive, I think it'll be best to cooperate and see how much we can help one another in this. Anyway, my idea is to make Pretty Garage capable of reading different list formats. The program would periodically download what I'm calling "CRIs". CRI (Car Repository Index) is not a file format, but a type of file that contains certain information. It could be formatted as whatever can contain that. I'll probably make Pretty Garage support about three formats. The CRIs would provide a list of car IDs, their names and the files included in the package, so that the program knows those cars are available at that repository, then it car request the car files if the user wants to download them.

Closing
I'll soon be posting it and surely this first post will be edited to accommodate a link or package, then any discussion about the software can continue through the thread. Let me know if there's any feature that you guys consider very important or any question

We'll, I agree it's unlikely to come across collision. For the frequency of those events, we can perfectly handle them one by one. What we could do to make those cases less frequent is agree to try to avoid predictable car IDs for new cars.

For software development, it really is very comfortable to just rely on car IDs!  I can tell you that from my experience with the two garage programs. I've used that for R4K too, but the handling there is simpler.

A simple look-up table of known car IDs against their car names would be good too so when somebody wants to come up with a new ID, they can take a look there first. Not that it's a requirement, but I think it'd help.

Also:
https://wiki.stunts.hu/wiki/ISA_competition
https://wiki.stunts.hu/wiki/World_Stunts_Championship
https://wiki.stunts.hu/wiki/Race_For_Immortality