Zip Support

[Mighty Duck X-treme]

Great! XP owns 98 and 2K.

You might know this already, but if you're going to go for XP, be aware that DOS support is VERY limited, so some programs you originally ran in DOS may not run with XP.

Did I mention that id Software has selected Alienware to showcase this year's QuakeCon experience? ^o^

[Sphagne]

Why not just make a wad browser that can go inside the wads by a click or "Enter", justlike 7zip or NC that lets you enter zip files and threat them as directories and copy files into or from them.

You can it them wad browser, and it would become an instant hit with all the Doomers.

[Hirogen2]

What if we just design a complete new file format (and an editor on top), which handles all these issues?

[wildweasel]

Hirogen: Because once again we are reinventing the wheel. There is nothing wrong with the WAD format, only the editors that work with it.

[Mighty Duck X-treme]

WILDWEASEL!

Now look what you've done. He made a double post, and now he can't delete it.

*edit* Never mind, Randy took care of it. Thanks buddy!

[GooberMan]

I have implemented a file managing system that will be used in my editor, Mooditor, that can handle both WADs and ZIPs. Attatched to this post is a zip containing the source code and binaries (GPL'd). Read readme.txt for instructions on how to use it.

For the coders, I have implemented an object oriented approach to archive handling. A FileManager is used to handle requests to the different files that are loaded at any time. A common file interface is used to keep track of file pointers (you can have multiple file interfaces), FileManager keeps a list of these. At the end of the food chain is a BaseFile class that has pure virtual functions in it. From here, derived classes provide the functionality for the required format.

It's still incomplete, and probably a bit buggy, but it's not bad for a couple of hour's work.

[randi]

There is nothing wrong with the WAD format, only the editors that work with it.

Actually, I can think of the following deficiencies that the wad file format suffers from:

• Eight character lump name limit
• No internal directory structure
• No type information
• No compression

On the other hand, it does have one good point:

• It does exactly what it was designed to do

[Hirogen2]

It does exactly what it was designed to do

That was 1993, ten years from now.

[randomlag]

Actually, I can think of the following deficiencies that the wad file format suffers from:

• Eight character lump name limit
• No internal directory structure
• No type information
• No compression

On the other hand, it does have one good point:

• It does exactly what it was designed to do

Exactly - it does exactly what is was designed to do. And that is my point about VALID comparisons. If one takes the PWAD structure and made it follow the QUAKE pak directory expansion (which is extremely similar in concept to PWAD) all those issues are solved easily, quickly and without much trouble.

Force fitting something else (zips) to do this job is about as far away from this "designed to do" concept as it can get.

If you wanted to expand the PWAD format -AND- still be compatible with old tools, it's pretty simple. What you do is create a directory subset with the PWAD. It will look like a giant LUMP to all the old tools, but to newer tools they could have ALL the things you mentioned above. Not unlike the way you stuck the fonts into one lump.

Now you still have ONE PWAD with total object focus, not a disastrous mess the will escape the installation capability of most users.

[randomlag]

. Zip files are much less likely to get damaged than WAD files. I've had several WADs get screwed up because of editors crashing etc, but never had a zip break to this date.

NOT true. Anything that compresses has a much higher chance of failure. As an aside, the pkfix thing also FAILS 1/2 of the time. And the rest of the time you loose a significant part of your work. That's from experience.

3. Since I'd normally be working with a directory structure outside the zip, damage to the file would only require me to re-pack.

You just admitted the problem. And you just showed there is no need for a zip since you are already working with a directory structure.

Effort as in what? If you change anything about the WAD format, you wouldn't have any editors that supported it.

Read my prior post - it's simple. The 2nd part is umm, funny. You want to create something really different and then you argue about editors Let's get real eh.

No, they wouldn't need any tutorials at all! People'd just have to select a couple of files and put them in a Zip. Even newbies are familiar with that procedure.

Right, no tutorials. Saying something is so, doesn't make it so. I can show you a 1000 posts on DW even simpler that stump newbies. To assume/state that newbies are familiar is an argument without substance. It's simply not true.

Just the fact that you can have a directory structure makes it more elegant than the WAD format.

Again not true. You are merely making up your own definition of elegant. It's not elegant at all. It's a force-fit for something it was not designed to do. That's what this whole argument is so far.

You can't just up with an idea and refuse to consider the bad aspects or other methods that yield better solutions for the work put out. IOW, I don't mind change, but let's make it something that is an extension that fits the general philosopy and intent of PWADs.

[Mighty Duck X-treme]

Deep, did you take a good look at the file managing system that Gooberman's going to be using for his editor? This might be helpful to you when you're implementing new Deepsea features (as always), should Randy add ZIP support.

[Fredrik]

NOT true. Anything that compresses has a much higher chance of failure.

You don't get it, do you?

1. The point in time where files usually break is when they are modified. The main Zip tools out there are well tested and inspected - they are extremely unlikely to fail no matter what the situation. Unlike many WAD editors.

2. As I said before, you *can* disable compression for Zips if you really think you're going to lose data. There's something called "backup", too.

4. Zip files have never broken for me, WAD files have. This is a fact so how can it not be true?

And you just showed there is no need for a zip since you are already working with a directory structure.

The need of the Zip is obvious:

1. I can't distribute a directory structure.

2. I can't distribute a directory in a WAD once I'm done, since the WAD doesn't have a directory structure at all.

You want to create something really different and then you argue about editors

The entire point is that editors for Zips ALREADY EXIST. *cough* *cough*

Right, no tutorials.

Fine, then the newbies can stick to the old method. No damage done - and I can do things the way I prefer.

Again not true. You are merely making up your own definition of elegant. It's not elegant at all. It's a force-fit for something is was not designed to do. That's what this whole argument is so far.

Zips are designed to be container files. There's no force-fitting.

And again, if you don't find a Zip feature useful, then you don't have to use it. I don't find the multiplayer feature in ZDoom particularly useful myself, but I'm not arguing that it shouldn't exist for others to make use of. The hypothetical introduction of Zip support would NOT modify anything already in there.

[randomlag]

I see you referring to Enjay's posts instead of copying/pasting. Quote was the best word that came to mind, and yes it isn't exactly the right word but it gets my point across

Cut the crap. I wasn't quoting and what you are doing is distorting the simplest of concepts. If you don't see quotes, it doesn't take much smarts to realize it's not quoting. Or are we rewriting the dictionary too.

Refer to my post about thinking from a different perspective. Also notice how Enjay posted the exact same amount of steps to make a WAD and to make a ZIP. Same amount of work, different program used for the last step (or if incorporated in to WAD managers, it can even be the same program).

LIST the steps. If it's the same amount of steps then you have gained nothing.

I am quite willing to think for a different perspective. Mine is quite more flexible and adaptive than zips. Rather than sticking stubbornly to "zips", how about you thinking from a different perspective. There are many other ways to make WADs more flexible. I just listed an obvious one. But there are many others.

Or you could provide a set of functions that act as a common interface for WADs and ZIPs. Quite easy to do, and saves trying to make a ZIP act exactly as a WAD and vice versa.

Lots of things are easy to do. Mine suggestion is even easier. And there's very little to new to learn conceptually. All you need to provide is a set of functions that act as a common interface for WADs and extended WADs. See how easy that is to write

You crack me up. I sure do miss reading a deep/everyone else thread on Doomworld Oh, Fredrik pretty much stated my thoughts on why that statement is flawed, so refer to that post if you must.

Both you and Fredrik run on the premise that if you say something it must be true. It's NOT. Remember, it's you that said DeePsea was just like DEU. Probably still want to insist that is true too. I wouldn't put too much faith in your logic

[Fredrik]

common interface for WADs and extended WADs. See how easy that is to write

But why would you have to waste your time to create a whole new file format called "extended WAD", and get programs to support it, when you can have a format that already exists, is easy to interface to, and is already supported by many other programs?

[wildweasel]

ZIP support is not needed. There is no reason why we can't just write a really comprehensive tutorial to manipulate a WAD. In my eyes, this is the END of the discussion.