epithumia on 23/3/2005 at 18:00
Exclusive or. Please pick one format, so that poor people like me don't have to deal with a bunch of different tools. The format must have both the compressor and extractor available for Linux, for free, in source form, or else thiefmissions.com won't be hosting missions in this format. The reason is simple: I need to be able to test and unpack submitted files. Occasionally I need to be able repack archives as well (because people send me single updated files and whatnot).
RAR, btw, is right out: no source (that I know of). I have no preference between Zip and 7Zip.
SneaksieDave on 23/3/2005 at 18:24
epithumia, fair enough.
I guess then it comes down to efficiency versus nonstandard obscurity. I'd personally vote for standard zip because that's one less tool I need to install for nothing other than FMs.
Shadowcat on 23/3/2005 at 22:14
For those who haven't used (
http://www.7-zip.org/) 7-Zip before, let me just reiterate that the client software is a mere 1MB download, and that creating an archive can be as easy as this:
Inline Image:
http://tinypic.com/2bpjd3And the people who are only going to
play the Fan Missions won't need to download anything at all.
I would again suggest that for the FM authors, installing and learning to use the 7-Zip client software pales so far into insignificance when compared to the countless hours that will need to be invested into learning and using the Thief 3 editor, that it seems like it should be a total non-issue.
edit: Yep, there are both GUI and command-line versions for Win32, and a command-line version for Unix/Linux/MacOSX/BeOS. See the (
http://www.7-zip.org/download.html) downloads page.
sparhawk on 23/3/2005 at 22:43
Is there a commandline version as well? I don't like having to use a GUI for such a tool.
dracflamloc on 23/3/2005 at 23:01
Yea I only downloaded the command line version.
Check your email sparhawk.
Andruha on 24/3/2005 at 10:45
The choise of the archives IMO is not important. The thing is, data from one archive can be easily repacked into a different archive, all automatically.
Quote Posted by Shadowcat
.. for item 2, provided the code exists to render each case, the loader can display TXT, HTML, or RTF as appropriate. If the briefing is TXT, show the text. If the briefing is HTML, call the HTML viewer.
That's only one side of story.
Freedom of choise for item2 has to be more constrained simply because it is hard to automatically convert texts from one format into another correctly and without loss of information. It will require certain manual aspect (how big that will be, it depends..). Now look at the issue not from the consumer point of view, but from that of FM repository providers. In order to make some sense from briefings (e.g. integrating FM into their content management systems), they'll have to deal with text, RTF, HTML, etc.. There's bound to be duplication, loss and manual work. How much - I don't know. FM repository providers should voice themselvs on this issue..
With the above in mind, here is my vote:
1. Whatever the programmer chooses, as long as there are lossless bi-directional conversion tools between the format of choise and other common formats.
2. i) Text to ease conversions or ii) Structured Text to automate conversion into multiple rendering formats (HTML, RTF, etc..) and illiminate duplication.
