ml>> when do you expect to have reading binary config files and jam
ml>> support working? is there a timeline?

 ac> JAM support will be fixed as soon as someone (possibly me)
 ac> fixes it in SMAPI.  I was hoping to take a look at it but
 ac> haven't had the time.  Which reminds me, I don't think *.MSG
 ac> support in timEd 1.11.a4 has really been tested properly.

understood...

 ac> Binary config files are another matter, and really depends on
 ac> what people still want support for,

i don't see where they are another matter... the code should work as it was
unless there have been updates to those binary formats... they should work
straight out just as they did before... hummm... unless there's some sort
of byte alignment problem...

 ac> as I don't intend to re-add code for all the obsolete config
 ac> file formats that timEd 1.10 supported,

re-add? why chop them out in the first place?

#DEFINE FE_BINARY_CFG
#IFDEF FE_BINARY_CFG
  blahblah
#ENDIF

seems logical to me ;-)

 ac> particularly since I have no way of testing those.

that's why other folk download, run and report back... we/developers don't
always have access to everything we write for... there are times that we
have to write "blind" based only on what info we can gather and
sample data file and let others report the situation... i know, its hard to
do but if i, a lowly self-taught pascal coder can do it, i _know_ that
others can do it too >

 ac> So, if something is simple to add, and test, I will probably
 ac> do it.  In the mean time if you can export your binary config
 ac> file to AREAS.BBS or SQUISH.CFG formats then do that.

exporting to those formats looses some of the benefits of reading the
binary directly... some necessary options cannot be expressed in those
formats...

)\/(ark