DRD Team

Enjay wrote:

BlackFish wrote:pk3

It is curious that the files are often referred to as that. Everyone knows they are just renamed ZIP files and that PK3 is just the id software convention (presumably indicating they view it as the third incarnation of container files for their games that started with the quake PAK file) for the ZIPped resources shipped with Quake3 engined games. To me, they are logically tied in with Quake3. I don't see why the PK3 extension should have any relevance outside that engine.

The only reason they used it was to prevent the files being recognized as ZIPs by Windows so that double clicking doesn't open them. And since it is the best known alternative extension for ZIPs it might have stuck. I used it for GZDoom.pk3 for the exact same reason id did.

But I have no idea why this name is so persistent. After all they still are ZIP files and not something different.

It just strikes me as a little odd that Doom ports and Doom players refer to them as PK3 files when they are not playing Q3. Especially when the same people refer to exactly the same format as a ZIP in all other circumstances.

Good question.

What's more, it's meant that I finally felt the need to set up an association for Winzip with the extension PK3.

With which you are negating the one reason the different extension was chosen,

Not saying there shouldn't be support for the extension (especially as JDoom has it, so people will want to transfer resources I suspect). I'm just saying.

That's the problem, isn't it? They just assume that as a game resource file it should be named .pk3 (why not pk4? It's the same content with a different name...)

Graf Zahl wrote:The only reason they used it was to prevent the files being recognized as ZIPs by Windows so that double clicking doesn't open them.

With which you are negating the one reason the different extension was chosen,

that's amusing. I'd never even considered that as a reason. To me one of the big advantages of zip support is the ability to simply double click the file and see whats in it for editing purposes. I personally view resource files (from any game) as that - a resource - and, if they are associated with anything on my machine, they will be associated with an editing program that can handle the file format. The other advantage, of course, is to be able to just drop a zip onto GZdoom and run it without having to extract a copy of the WAD first. However, I'd always want to check which files were in the zip first, in case there were multiple WADs or something.

Although I'm sure some other people will want to associate pk3s with GZdoom. That still doesn't get round the fact that most of the files they download will be inside zips. I'd be surprised if many people will start renaming the files they get from idgames (etc) as PK3. Maybe they will. I suppose the possibility existing is an advantage.

why not pk4?

Indeed. Or even a new extension specific to Doom ports. DZF Doom Zip File?

I'll stick with .ZIP. .PK3 is only supported because everybody uses it. Of course if you load it with -file extensions don't matter at all and you might as well call it myfile.thisisazipfile and load it properly.

.GZD!!!

Feel free to name your files as such. But then you will have to use -file to load them.

Zeg-Vok wrote:.GZD!!!

My suggestion of a Doom specific extension for zips wasn't really that serious (nor is your's I suspect). Especially because at least 2 ports that I know of now support the PK3 extension.

Not that it's really a big issue, in fact it's not even an issue at all. However, it still seems odd to use PK3 to me. IMO if there was a perceived need for a name that wasn't ZIP it would have made sense if JDoom (or whichever port did it first) had picked a new, generic extension for all doom ports. Which obviously would not be GZD. Too late now I guess. ZIP and PK3 it is.

I find it a bit strange as to why id decided to create the .PK3 extension in the first place. Maintaining consistency is a rather lame excuse, IMO. Not only that, but it's false as well... there was no such thing as a .PK2. Both Quake I and II used the .PAK extension. So why make the random jump from 1 to 3?

And having said that, I don't see any reason for GZdoom to have its own extension. It would just add a bit more confusion, really. If someone really wants to auto-associate a certain file with GZdoom, just rename it yourself.

Just as long as GZdoom supports any .ZIP format, renamed or not (which I know it will), we should all be safe and happy. Hell, this means I could even invent my own file extension... .ZEN, anybody?


Just my -2 cents.

Because PK3 is the third generation file type for the third generation Quake engine. Also PK3 allowed for what what Gen 1 and 2 could not allow and that was the ability to not rely on a special unpacker like Gen 1 and 2 required. Remember people had to create programs that allowed the first 2 generation PK files to be viewed and modified. It makes perfect sense to me for Id to rectify their mistake.

It would also make perfect sense for them just to call them pack0.zip etc, because that's more accurate.

The gzdoom with everyday it's cooler and new features rocks as hell with ZIPS it's a great idea it can many time solve

Xaser wrote:I find it a bit strange as to why id decided to create the .PK3 extension in the first place.

Here's the reason, taken directly from the Q3 source:

To save disk space and speed loading, directory trees can be collapsed into zip files.
The files use a ".pk3" extension to prevent users from unzipping them accidentally, but
otherwise the are simply normal uncompressed zip files.

Well, Quake and Quake 2 .PAK files were actually in a different format, I believe. The Quake II Evolved source port creators and content-makers/distributors use .PK2 files though (And they're just like Q3's PK3 and D3's PK4... they're just ZIP files.)

i'm suprised nobody has posted screenshots of models in game yet. Wasn't this one of those highly sought after features that everyone was looking foward to?

Yes, but the model def format is kinda incoml\plete, so I think everyone's waiting until there's a better way to do so. Plus, models are a pain to come by, other than the ones from JDoom.

Anything new depends heavily on Randy's progress. With the current state jump system I consider it rather pointless to do a state based model definition. Once the improved DECORATE parser with custom labels is out I can do this much more efficiently by defining animation sequences for entire state blocks. The current frame based definition is merely a compromise to allow defining simple things right now. It really sucks when you have to depend on other peoples' progress and they don't release their code for months.