File compression?

[IBBoard]

Part of constructing an argument based on logic is taking the facts as they stand at the moment and deducing further facts based on them. The documentation makes a statement of truth about the compression format used in the file. With no further information, all we can do is assume that it is true. If the documentation for something makes a statement and you are evaluating something in relation to that statement then assuming the statement is true* is not a rash assumption.

If I had assumed the compression would be PKZip compatible if the documentation just said "it uses compression" then that would be a rash assumption as there are many different compression algorithms that are not PKZip compatible. What you're effectively saying is that you should ignore all statements in the documentation as any one of them could be false.

Besides, points 2, 3 and 4, and as a consequence point 5, already point out exactly what you have just repeated - the documentation is incorrect and the format is some different compression that is not, in fact, PKZip compatible.

As I said in my follow-up post, everything is based on the facts as I had them and with respect to the statement in the documentation and the future usability of the files the decision that was made could be considered to be the "wrong" one. Using zlib within a similar structure to what I had now would a) have allowed Lone Wolf development the freedom to move to other (potentially more efficient) compression libraries if they wanted, b) matched the statement in the document (which is what users read rather than source code) and c) made the file format more usable for others (which could improve the up-take of Army Builder as people build community tools around it, as I've done for Dawn of War and their SGA various "Chunky File" file formats).



* especially when it is in the 2.2c documentation - so it isn't as if it was in 1.x documentation and accidentally slipped in to the first revision, it was there for a while

[gilvagor]

Wow...while I understand (at the root of it) what your saying you are talking about Army Builder 2.2c which IIRC hasn't been supported for at least 4 years.

Your also criticizing a company for using something that you wouldn't use.

At the root of it..it's a Data file. There doesn't have to be anything efficient about it..you download it and it imports into Army Builder.

Lone Wolf really doesn't have to nor should they make a usable format for others to build tools for since it's Lone Wolf's proprietary software (licensed compression or not).

I'm just trying to get an idea as to what your asking about now.

But then it's my thinking..

[IBBoard]

I'm not really asking anything at the moment, since Lone Wolf have answered my question sufficiently for me to find out the full information (i.e. to track down that it is Greenleaf's custom compression format that was used).

The documentation I had was for 2.2c because, as I said, the community members I'm working with are 2.2c users. Also, from what I was able to find the AB3 construction kit was either lacking or hiding its similarly technical documentation. The compression used seemingly hasn't changed between 2.2 and 3 anyway, so any information on the compression is equally relevant to new files. All of the additional information in the files is very basic stuff, at least for the important bits.

As for making it a usable format, I'm not saying that they should, just that it can certainly be advantageous to them in the long run. Lots of companies have a very closed mind about "it is ours and no-one else can have it", even over simple data files, but a more open mind-set of "it's ours, but we'll make it interoperable so that we can encourage a community of tools that could increase uptake" can have positive consequences that aren't normally factored in to the bottom line.

As for criticizing, as I said in my last post and one of the others, I was making a developer's evaluation. Given all of the information to hand (including information from the Greenleaf website and my knowledge of other archive file formats for computer games) a different choice could easily have been made that would have provided more flexibility. The developers have already admitted that they have considered alternate compression but that it isn't a high priority, which implies that even they think a better choice could have been made, or that compatibility in the compression may be a better way forward.

As I said, though, I've asked my question (what is the compression?), I've got my answer (custom modification of LZW), I've done my research (it is Greenleaf's custom format) and I now know what I need to know.

[61bfe0ab023c143d]

Originally Posted by IBBoard

mpression?), I've got my answer (custom modification of LZW), I've done my research (it is Greenleaf's custom format) and I now know what I need to know.

There's not much "custom" about it, it's pure ARJ in a slightly different container

[IBBoard]

I didn't get too far with pulling apart the compression, but I've got someone else who's looking at it for the project. Do you have anything more on it being similar to ARJ? Any evidence or examples?

Thanks.

[IBBoard]

I'll take that as a "no" then!