Created attachment 3017[details]
Add support for .pk3dir
This patch adds support for .pk3dir; folders in a search path which end in .pk3dir are treated like .pk3 files.
For example:
baseq3/textures/foo/whatever.jpg // normal file
baseq3/mymap.pk3dir/textures/mymap/tex1.jpg // files in the pk3dir for my map
The patch does this by finding folders ending in .pk3dir and adding them to the search paths in the correct order.
This is awesome for mapping/modding, you can keep all the assets for your project bundled together making it easy to zip them into a pk3.
Another advantage: with modern version control you can make each pk3dir a submodule and have a real neat repository.
Notes:
- pk3dir are not read like pk3s on a pure server
- pk3dir should be accessed in the correct order as it it was a pk3s
- This patch doesn't handle recursion or avoiding reading the pk3dir as a folder, but I see no need to (and not having it keeps it backwards compatible if you happen to have a resource at "mymap.pk3dir/textures/mymap/tex1.jpg")
I had to revert the patch. Apparently there's a problem where the code gets stuck in an infinite loop.
User who reported this:
quazgaa (at) gmail (dot) com
[01:36:50] <Quazgaa> svn borked? sits at ----- FS_Startup -----
[01:51:10] <MAN-AT-ARMS> for what its worth..mine does not
[01:51:28] <Quazgaa> trying to start with +set fs_game q3ut4
[01:51:37] <Quazgaa> just starting it with no options it starts
[01:51:59] <Quazgaa> to regular q3
Maybe you can debug this with him. For now I'm removing the patch.
(In reply to comment #3)
> I had to revert the patch. Apparently there's a problem where the code gets
> stuck in an infinite loop.
I didn't reproduce this error, but I see an infinite loop. If you take "if (pakwhich)" and the FS_LoadZipFile call fails, it will keep retrying the loop with the same check. pakfilesi and pakdirsi are never incremented if the FS_LoadZipFile call fails.
I think the solution to the infinite loop is to increment pakfilesi:
if (pakwhich) {
// The next .pk3 file is before the next .pk3dir
pakfile = FS_BuildOSPath(path, dir, pakfiles[pakfilesi]);
if ((pak = FS_LoadZipFile(pakfile, pakfiles[pakfilesi])) == 0) {
// Invalid *.pk3. Skip it and go on to the next pk3/pk3dir.
pakfilesi++;
continue;
}
TBH I'd reject this feature. Just add a Makefile, script or whatever to your assets that zips your files and copies the archive to the q3 dir automatically.
(In reply to comment #4)
> (In reply to comment #3)
> > I had to revert the patch. Apparently there's a problem where the code gets
> > stuck in an infinite loop.
>
> I didn't reproduce this error, but I see an infinite loop. If you take "if
> (pakwhich)" and the FS_LoadZipFile call fails, it will keep retrying the loop
> with the same check. pakfilesi and pakdirsi are never incremented if the
> FS_LoadZipFile call fails.
>
> I think the solution to the infinite loop is to increment pakfilesi:
>
> if (pakwhich) {
> // The next .pk3 file is before the next .pk3dir
> pakfile = FS_BuildOSPath(path, dir, pakfiles[pakfilesi]);
> if ((pak = FS_LoadZipFile(pakfile, pakfiles[pakfilesi])) == 0) {
> // Invalid *.pk3. Skip it and go on to the next pk3/pk3dir.
> pakfilesi++;
> continue;
> }
I agree with this fix, and tested it. I also made the loop a little more robust.
(In reply to comment #5)
> TBH I'd reject this feature. Just add a Makefile, script or whatever to your
> assets that zips your files and copies the archive to the q3 dir automatically.
This is a much better option. Viewing things in game is essential, artists do it continually. Artists want to minimize this loop, not waste time reassembling a bunch of pk3s each time. Think of how awesome it is to have incremental builds when you are developing code. I think it is a very worthwhile feature.
Created attachment 3017 [details] Add support for .pk3dir This patch adds support for .pk3dir; folders in a search path which end in .pk3dir are treated like .pk3 files. For example: baseq3/textures/foo/whatever.jpg // normal file baseq3/mymap.pk3dir/textures/mymap/tex1.jpg // files in the pk3dir for my map The patch does this by finding folders ending in .pk3dir and adding them to the search paths in the correct order. This is awesome for mapping/modding, you can keep all the assets for your project bundled together making it easy to zip them into a pk3. Another advantage: with modern version control you can make each pk3dir a submodule and have a real neat repository. Notes: - pk3dir are not read like pk3s on a pure server - pk3dir should be accessed in the correct order as it it was a pk3s - This patch doesn't handle recursion or avoiding reading the pk3dir as a folder, but I see no need to (and not having it keeps it backwards compatible if you happen to have a resource at "mymap.pk3dir/textures/mymap/tex1.jpg")Created attachment 3247 [details] Add support for pk3dir (v2)