Car repository indices (CRIs)

[Daniel3D]

If we allow multiple versions with the same id we should keep them well separated. An important issue to keep in mind for car managers.
That would mean (I guess) keeping a garage folder with cars in their own "WXYZ-VERSION" folder.

[Cas]

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.

[dreadnaut]

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.

[Daniel3D]

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.

That sounds very sensible to me.

[dreadnaut]

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.

[Cas]

Right, I was thinking about something of that sort, that is, not just to find a zip online to download, but cars in a garage could just as well be zipped. Currently, PG is only moving files. The convenience is that the user can come and drop car files in the garage directory and they'll be picked up, but generally, it'd be good to implement zip at that level too.

[Daniel3D]

Is it sensible to keep zip files in the garage and only Copy (extract) to stunts and keep the original safely packed.
It would need to check if all cars in the game folder are also safely in the garage.
Or a three way split in game folder, garage and local archive.
The local archive could be useful for wip cars. When finished it can be presented to the central archive.

[Cas]

Uhm... for now, I'll keep the files unpacked in garages, but I'll be considering this. There is one thing about zipping and it is that it allows you to repeat file names (like "readme.txt"; I would recommend carXXXX.txt instead, but...). When files are unpacked in garage, files with the same name are overwritten. In fact, Pretty Garage detects cars in a directory by file name, so it currently won't recognise anything but the default car file names (compressed and decompressed) and "carXXXX.cfg". This can be changed if we decide on something better.

[Duplode]

There is one thing about zipping and it is that it allows you to repeat file names (like "readme.txt"; I would recommend carXXXX.txt instead, but...).

Side note: in a similar way, for the Competition Archive cars, I have adopted readXXXX.txt as a standard. No strong opinion on whether that's worth doing in the Car Archive -- it might make sense to keep readmes exactly as provided by the author. (Though it might also be useful to provide, or generate, readmes for cars that don't have one...)

[Cas]

For a general readme, I think the best would be to just keep whatever the author chose to provide... but if it's more like an information file that's supposed to be displayed in a client or that contains complementary information for the car, then it probably would be best to use something like the carXXXX.cfg files I used in Simple Garage. As I said, Pretty Garage currently counts them among the car files, but does nothing with them. I did little to nothing with them even in Simple Garage, so I'm open to change their name and/or format, but I think the idea itself is useful. Dreadnaut mentioned something similar recently.

[Daniel3D]

I think the best would be to just keep whatever the author chose to provide... ... use something like the carXXXX.cfg files I used in Simple Garage. As I said, Pretty Garage currently counts them among the car files, but does nothing with them.

You could include all files that are anyXXXX.any as general rule. Then it doesn't matter what additional files are used, even images or websites can be added.
The car archive can include extra files as an separate addition to the car.

[Cas]

That's a good one!  For now, Pretty Garage can handle up to 8 files per car. I don't remember for Simple Garage. Originally, this is to contemplate the possibility that a car contains both a compressed and an uncompressed version of its files, even if only one of them will be used, that is, so that the file isn't just ignored.

[Daniel3D]

That's a good one!  For now, Pretty Garage can handle up to 8 files per car. I don't remember for Simple Garage. Originally, this is to contemplate the possibility that a car contains both a compressed and an uncompressed version of its files, even if only one of them will be used, that is, so that the file isn't just ignored.

Then you never have more than 7, because for some reason the car res files a never compressed into pre...

I don't know if the game would accept CARVETT.PRE if it was there. Don't know if that was even tested before.

[Cas]

As far as I know, that has never been tested. My gut tells me that it would be accepted as long as the RES file isn't there. Anyway, I'm looking at Pretty Garage's code at that point and I'm thinking that maybe taking any *<car_id>.* for a valid car file is kind of risky. Depending on the car ID, it might pick up files that have nothing to do with it, especially when reading the Stunts directory. Within garages, it's not a problem. But I'm still evaluating it, because I'm thinking, as long as it's not *<car_id>*.*, this is very much unlikely to happen, except on purpose.

Yet, suppose a very wrongful car maker decides to use the car ID "UNTS", or "AULT". Maybe this is safe enough if I exclude some extensions, such as EXE, COM, TRK and RPL, but it gets complicated to do that. So for now, I leave it as it is and I'll keep thinking about it.

[Duplode]

Those concerns, I think, do suggest it's better to leave it as is rather than imposing extra requirements on what an ID should be. There's nothing inherently wrong with UNTS or AULT as an ID, and conversely STAATZ.TRK and DEFFORD.TRK are perfectly reasonable track names.