When Tiger shared his compile script, I had a brief look at it, and I noticed he intentionally tells it to use advanced compression methods. It does save on space, and unfortunately, I really believe compressors and decompressors should get with the times and start supporting them - they may not be as fast as Deflate, but they sure are smaller by a factor of at least somewhere between 22% to 33%. In the days of metered internet connections becoming increasingly common, this is *EXTREMELY* important.

NeoHippo wrote:Something I noticed before but failed to mention.
Slade3 cannot open your pk3 files

I have to un7zip the pk3 first and then re7zip it before Slade3 accepts it.
Not difficult to do but a nuisance.

I am sorry, but I don't know how I could even address this issue without having to change the method used which will inflate the file size. I have received too many complaints on the over all file size of the archive file before the compression\clean-up updates. As of right now, I don't know what I could do.

I know this doesn't really help, but since its merely a zip file (if I remember to use the pk3) you can extract it and edit the data as you see fit without needing to use an external tool - - besides notepad++ or the like.

Eruanna wrote:Like I said - I believe it's up to SLADE to update itself to the newer compression methods. They are standard, now, and useful enough to ensure they will not be going away anytime soon.

It could be a dependency issue with what SLADE is having to use, but I am only pulling straws -- I can only assume that its a limit of its internal dependencies, or else it is just easier to default to old standards. But you are right, I would like to see SLADE support such formats.

Eruanna wrote:Bandwidth is a commodity, too much so to ignore.

Biggest problem with bandwidth is not the files in which is sent and received, but the politics that drives ISP's and mobile carriers. A lot of programs and now - modern Operating Systems takes full advantage of the end-users WAN connection for an abundance of things. Programs such as SkullTag that rely heavily on the WAN connection in order to have a net game, or programs that are web-focused that it must connect to one or multiple servers in order for it to receive data or content (maybe ads or legit useful data). But to throw to the mix, now Windows [7|8|10] will now send telemetry data to Microsoft's services every so often - not excluding under-the-hood data sharing services, in which whatever internal functions the user utilizes via the Kernel\Windows code is recorded and set to Microsoft for analyzing and optimization in the future. With all of this data, although I mentioned very few there is without a doubt an innumerable vast of wealth of software available that requires a WAN as a dependency, the demand of better networking should be on the rise. A lot of ISP's, or the most common, does not really help to push data to the foremost focus - instead its capped to a certain degree and its not negotiable without an increase bill.

Now, for those that bring up torrent hoggers and the like, - yeah that's bad, but ISP's have grown smart to use techniques to combat such ridiculous transfer rates by simply shaping or throttling the network of the end-user's connection. With such techniques, we should be able to push forward - yet we're not. To flip the side of the coin, hard disks are simply getting larger (10TB and more now) and there price continues to dwindle over time. Yet, ISP's refuse to shift forward and impose 25 or 30GB cap limit.

All of that is very true, but my point was more focused on the idea that every byte saved matters through all of this bullshit. Doing things like setting Windows 10's network settings to metered helps a lot. Downloading mods that are compressed with LZMA compression instead of Deflate helps.

To strengthen my case, attached is a file that was generated by SeaMonkey pointing to Wikipedia's English home page as of today (approximately 9:19AM eastern time) and then stored inside of a TAR archive. Then, I compressed the file 3 times using the most common compression types, and included them alongside the original raw TAR archive which they contain. Notice how the ending file size changes with each compression type, and also take notice how the XZ archive is at least 8% smaller than the GZ archive.

Each compression was generated with nothing more than the default settings. Nearly 10% is too significant to ignore, especially with larger archives.

Eruanna wrote:but my point was more focused on the idea that every byte saved matters through all of this bullshit.

#ByteLivesMatter

You're right though, squeezing as much as you can with the data does help. And it is proven given by the table you provided. Sorry it took me awhile to get back to you, classes just started and my sleep schedule is a bit wonky.

If you want to blame someone here, it's the people who wrote wxWidgets. Its Zip decompressor, despite using C++ features extensively had been written as one big black box where only comes out what its creators planned. No chance for some programmer using this library to hook other decompressors into it. Of course it's convenient to use but seriously, these days it has become close to useless, and yet there's hardly a piece of wxWidgets software not depending on it.

Maybe the best thing to do then would be to try and convince the SLADE3 creators to use the libraries ZDoom already uses instead, then? The ZIP archive itself is really not hard to decode, it's just a header at the end with an index and the offsets are all backwards-relative. And then each entry also indexes itself at those offsets. What's left is decompressing the individual chunks - and the libraries can take care of that.

It's not just a question of decoding, though, ZIPs have a lot of metadata (absolutely useless to ZDoom's purposes) that SLADE ought to preserve, such as each file's timestamp, authorization, attributes, etc. All these things don't exist in WADs, nor in most other archive formats supported by SLADE, so it's just not handled at all at the moment and instead just works thanks to using the wxZip class.

TGRDM3 has been officially released! However, I am still waiting for /idgames staff to continue with their protocols. If anyone is interested, here is the release via GitHub. I'll update the topic when an /idgames link is available. Until then, enjoy this medieval piece:

I really like the maps and the atmosphere that resonates from them, they definitely have a high quality play style that you don't get from most of the current stuff that comes out.
truly outstanding man i give this a 10/10, just wish there was more maps like these.