Now ready for general usage/testing

Note that all indices are 0-based instead of 128-based.
Requires (only) JDK5 (since Mac people are likely to use this <_< ).
Works with Windows .plt pilots and Macintosh MacBinary .bin and raw resource fork pilots, regardless of the presence of a data fork in the MacBinary file (I think) and any other resource in the resource fork.

There are two major sections not filled in. Some part is probably planetary destruction status, since I haven't got that yet. Note that most things are shorts, even when a byte would suffice. Some knowledge of hexadecimal may be required. If you fill in all the unknowns, I'll create a converter, since I figured out where the missing 6*16 bytes went (this information is noted when running it). However, I can't do this until I know at least the sizes of the remaining.

Thanks to Guy for help and resources.
Some code contained in this resource was covered by the MIT X11 license. This information is covered in the readme.

Binary only (to most people).

Usage: from a terminal:
java -jar PilotReader.jar pilotfile.ext>outfile.txt

It'd be possible be write a batch/shell script to make some of this easier, using readline (Unix) and set /p (Windows). If created, I'll edit them in here. It'd probably be a good idea to allow passing a command-line argument and check if it is there before prompting for pilotfile, but always prompt for outfile (although perhaps save a default, or allow a simple numbering scheme)
-NC

This post has been edited by Nonconventionally Creative : 20 August 2009 - 04:32 PM

Fixed bug with a constructor not existing in Java 1.5. This should only affect Mac users without 64-bit Intel.

Edit: to use directly on a resource fork, pass "<filename>/..namedfork/rsrc" as the filename.

This post has been edited by Nonconventionally Creative : 14 December 2008 - 05:52 PM

(minor gravedig of my own release topic)
Finished resource 129 (thanks to seant via Guy's adaptation), correcting a shift, and filling in all of the unknowns (some are simply "unused" and are expected to be always 0).
This program may now be used to show the exact state of a pilot file.
I intend to use this information to create a converter between Mac and Windows pilots.
This program contains one (1) undocumented feature.
This program is not very smart about file types. Please be nice to it.

If any fields marked "Unused" are not 0 (except as marked), this is a bug; please report it.
If any fields do not align correctly, or do not translate correctly, or if a Macintosh pilot fails to read due to presence of other resources, please report it. In the former cases, please include the undocumented feature in your report.
PilotReader_2.zip (22.57K)
Number of downloads: 92

This post has been edited by Nonconventionally Creative : 15 January 2009 - 10:14 PM

While working on the converter extension, I discovered a possible bug; I have not checked it thoroughly yet.
The bug relates to endianness and may affect the following fields:
Mission + i + unknown (flags? not from misn resource) //I have no idea where this comes from, but I know it occasionally has different values
Mission + i + ScanMask // for some reason I'm doing this as a (decimal) short right now, but it really is just a bunch of bits
Mission + i + Flags
Mission + i + Flags2

This bug probably only affects windows pilots, but I'm not sure.

Edit: discovered that the following value assumptions are wrong: (from http://nevermore.uri...pilotformat.txt ; offsets are wrong for Windows and are not present for the 15 following missions)
29ac short unknown (-1)
29b4 short unknown (-1)

This post has been edited by Nonconventionally Creative : 21 February 2009 - 03:12 PM

Implemented converter. Confirmed that a conversion Win -> Mac -> Win returns an identical file, and diffing the outputs outputs only foreseen differences (note that some of them might not be correct. Basically, anything that is a type of flags might be wrong, since I don't know whether to do it as a single integer or a sequence of bytes)

But, as long as you don't have any active missions, you avoid all the problem areas.

Also, I added a primitive GUI including save file for text output (convert output is done automatically)
Insert legal disclaimer about not being responsible for damages

Implemented converter. Confirmed that a conversion Win -> Mac -> Win returns an identical file, and diffing the outputs outputs only foreseen differences (note that some of them might not be correct. Basically, anything that is a type of flags might be wrong, since I don't know whether to do it as a single integer or a sequence of bytes)

But, as long as you don't have any active missions, you avoid all the problem areas.

Also, I added a primitive GUI including save file for text output (convert output is done automatically)
Insert legal disclaimer about not being responsible for damages

Edit: oh, and at some point I added autodetection of a real resource fork (Mac < 1.1 pilots) for reading/converting to Win, but converting Win -> Mac outputs the resource fork in the data fork (as MacNova 1.1). Users of older versions will have to copy this into the resource fork independently.

Wanted: someone to write a (Edit2: user-friendly ) readme for this. (Particularly the Mac side)

Attached File(s)

• PilotReader.zip (25.76K)
  Number of downloads: 33

This post has been edited by Nonconventionally Creative : 20 August 2009 - 06:48 PM

That's pretty neat!

It'd be great if you could add the ability to save the unencrypted .plt file (perhaps as a platform-independent unencrypted version), and import from that same unencrypted format.

That would be a jumping-off point for anyone who wanted to write a character editor (and would also allow people like me whose characters are bugged to reset their mission flags with a hex editor!).