[Feature request] Add 7z archive decompression support for .ftl mod archives

[heydojo]

The compression format of ftl mods is currently zip. If you load an lzma compressed .ftl mod into Slipstream, it does not error out but fails to patch ftl.dat.

Would it be possible for Slipstream to work with lzma compressed ftl mods please?

Evaluating the compression type of a mod and erroring out with a warning message before trying to extract it (if Slipstream does not support the compression format) would be a nice feature too. Say if a new mod maker were to load a rar compressed ftl mod into Slipstream (idk why you would try to do this but whatever.)

7-Zip is pretty much the standard application Windows users install to work with compressed archives. LZMA compressed 7zip archives (.7z) are a suitable alternative to zip archives and the format is preffered by many users (I remember the bad old days of zip file corruption, lol.)

The LZMA SDK is here and has the required tools to utilise lzma compression within a java application. One of the main benefits of LZMA is that it offers better compression ratios in comparison to zip archives in many situations. This benefit results in smaller sized archives. Smaller sized archives require less storage space and less bandwidth to download. This change would benefit everyone. :)

[Vhati]

Article: How to use LZMA SDK to compress/decompress in Java

Short answer: don't

The 7zip sdk is old and unmaintained and it's just a JNI wrapper around the C++ library. A pure Java implementation on a modern JVM (1.7+) is as fast as a C++ one and has less dependecies and portability issues.

The LZMA SDK, as a whole, claims to be circa 2016, but the Java files within are from 2005-2008.

I'm cautious about adding libraries, especially bindings. I'll look into libs. .

Evaluating the compression type of a mod and erroring out with a warning message before trying to extract it (if Slipstream does not support the compression format) would be a nice feature too.

Hrm, pre-scanning mods for invalid formats... the on-startup metadata harvesting pass... Looks like it ought to already be logging something when an invalid/corrupt archive is discovered. It's just that failures aren't collected and passed back to the GUI.