Car repository indices (CRIs)

[Cas]

I agree. In the future, if we need to use more files for car packages, we can implement a rule of what their names would be like. Maybe car<car_id>.* or <car_id>*.dat.

[dreadnaut]

I'm thinking garage programs, in general, should only copy the four standard data files into the Stunts directory, and ignore any other files included in the "bundle" (zip or set of files).

This would avoid any risks of collisions (between cars or with Stunts itself), and the need to create naming rules. After all, we have old cars that don't follow these rules already, and anyone in the world might create a car without being aware of conventions used elsewhere.

[Cas]

That's a good point. When the target is a garage, it doesn't matter much, but when it's Stunts directory, unzipping the whole package there could bring problems. Pretty Garage is currently doing just that. On the other hand, if you unzip to a garage directory and then try to move the car to Stunts, it will only pick up relevant files.

In order to fix this for extracting towards Stunts directory, one alternative is to extract files one by one from the zip, but I think it'll probably be simpler and faster to unzip to a temporary directory, then move the relevant files and delete the rest.

Relevant files currently are as many of the following as they are found in the package: carXXXX.res, carXXXX.cfg, stXXXX.3sh, stXXXX.p3s, stdaXXXX.vsh, stdaXXXX.pvs, stdbXXXX.vsh and stdbXXXX.pvs, case insensitive. If Linux, these could be really many files because you can have both carpmin.p3s and Carpmin.p3s in a zip file, but this normally won't happen anyway.

[dreadnaut]

I think it'll probably be simpler and faster to unzip to a temporary directory, then move the relevant files and delete the rest.

That's probably the easiest solution. A step more complex: you could list the content of the zip file (e.g., unzip -l) and only extract the four files that Stunts needs.

[Cas]

Yes, that one is better, but it brings me one concern. You currently can set up in the configuration which unzipping command you will use and its arguments. Because I'm only unzipping and nothing else, I can verify success by checking on the present of the resulting files. I don't need to read the output. If I want to query the file list, I will need to check on the output, but different unzipping programs may have a different listing output format. Maybe some can't list the file names alone and provide some table form instead or something. I could be losing support for those if I do that.

I really don't know what's more commonly used in Windows for unzipping from the command line. I think in most GNU/Linux systems, it's InfoZip

[Daniel3D]

I really don't know what's more commonly used in Windows for unzipping from the command line. I think in most GNU/Linux systems, it's InfoZip

For windows the most common known program is WinZip. But since windows has zip integrated since W10,
In command line you use 'expand' + path/file.zip

[Cas]

Uhm... so say you are at C:\this\directory and there's a zip file there called thisfile.zip and you want it to be unzipped and it's contents dropped at D:\this\other\directory. Do you necessarily have to go there, that is, do something like this?:

Code Select Expand

d:
cd \this\other\directory
expand c:\this\directory\thisfile.zip
Can you also do something like this?

Code Select Expand

expand .\thisfile.zip d:\this\other\directory

[dreadnaut]

I think expand only supports .cab files. Powershell has an Expand-Archive command apparently, never tried using it though 🤷

[Daniel3D]

I think expand only supports .cab files. Powershell has an Expand-Archive command apparently, never tried using it though 🤷

Apparently both expand and tar (from the tar archives) are nowadays able to work with zip

Code Select Expand

expand source [destination] [/r] [/i] [/d] [/f [:filespec]] [/y]

Expand Command Options
Item   Description
/r   Renames expanded files.
source   Location of the compressed file. For example, this would be the location of a file on the Windows CD.
destination   The directory where the source file(s) should be copied to. Can consist of a drive letter and colon, a directory name, a file name, or a combination of these. If source consists of multiple files and you don't specify /r, destination must be a directory.
/i   Renames expanded files but ignores the directory structure. Applies to Windows Server 2008 R2 and Windows 7.
/d   Lists the files contained in the source but doesn't extract them.
/f:filespec   The name of the file that you want to extract from the source file. If the source only contains one file, this option isn't necessary.
/y   Prevents the command from informing you if you are copying over files in this process.

[dreadnaut]

Apparently both expand and tar (from the tar archives) are nowadays able to work with zip

Do you have a link to this information? The quote above does not mention zip files, and I can't get it to work here.

[Daniel3D]

Trusting indirect sources (that's why I used "apparently" in my remark earlier) here is the information:

Softkeys.uk blog on using 'expand'
Answers.microsoft on using 'tar' for zip files

[Cas]

Uhm... well, if one of these can do the trick, it could get its commented default configuration for Pretty Garage

[Daniel3D]

Uhm... well, if one of these can do the trick, it could get its commented default configuration for Pretty Garage

I'm not provisioned enough to make the judgement, even though I might be able to test it, I probably won't be able to judge the results well enough.

[Cas]

Well, currently, Pretty Garage does support configuring any command line unzipping program that can take a zip file name and a target directory