I’m uploading svn4000 right now. There’s at least one thing which I know of
which must be done before we release beta3, which is adding a time limit
for reporting with the BugDialog—I don’t want to be seeing automatic bug
reports from beta3 more than 30 days out or so. (If we haven’t released
beta4 within 30 days of releasing beta3, I swear I’m going to lose my mind.)
Are there any bugs left which we know didn’t exist in beta2? At this point, I’m not
averse to releasing beta3 with no known new bugs, even if that means leaving
lots of known old bugs.
One thing else I thought if - If a module is added into the manager, then any Extensions that exist in an old-style module_ext directory should be loaded into the manager as well. We need to make the move from 3.0 to 3.1 as painless as possible.
With the same module I’m now getting the following Joel(build 4000). I tried uncompressing then re-compressing with the same error. Doesn’t seem to happen with other modules though.
java.util.zip.ZipException: invalid entry compressed size (expected -1 but got 10053 bytes)
at java.util.zip.ZipInputStream.readEnd(Unknown Source)
at java.util.zip.ZipInputStream.read(Unknown Source)
at java.io.FilterInputStream.read(Unknown Source)
at VASSAL.tools.IOUtils.copy(IOUtils.java:67)
at VASSAL.tools.ArchiveWriter.write(ArchiveWriter.java:311)
Oh and something which is of less importance… For some reason the module “OCS - Tunisia” is appearing at the end of the list in the module manager as opposed to alphabetical order.
I reported that here (vassalengine.org/forums/viewtopic.php?t=961)
yesterday. The problem is that the sort key is the module filename, not
the module name. Brent, do you want to take this one?
Argh. This worked when I tested it last night, but now I have the same
exception you have. The ZIP documentation in the JDK is awful—it’s
almost wholly silent on what conditions will cause the exceptions which
the methods throw: “ZipException - if a ZIP file error has occurred”.
Wow, you mean that I’ll get a ZipException if something goes wrong?
Gee, thanks for that stunning insight! It would be nice if someplace
there were an indication that ZipEntries are live, in the sense that
the ZipInputStream also holds a reference—but there is NOTHING in
the docs which indicate that you’ll screw up the ZipInputStream by
altering the ZipEntries it returns.
The solution was to create fresh ZipEntries for compressed files.
ZipEntries for stored files can be reused, as none of their fields
are altered when they’re written.
As of svn4009, the bug dialog won’t offer the option to report bugs if the
build is more than 30 days old. (This is temporary—I only intend for the
betas to be this way. I’ll devise a better system for full releases, but I
don’t want to hold up beta3 for it.) After 30 days, this is the message
you get in the bug dialog:
“VASSAL had an internal error. Becasue this beta version of VASSAL is more
than 30 days old, bug reporting is disabled. If you can reproduce this bug
with a current verision of VASSAL, please do so and alert the VASSAL
developers to the problem.”
I’m uploading svn4010 right now. I’d like to release this as beta3, unless
there are objections. The remaining bugs are either pretty obscure or were
already in beta2. We can solve the remaining bugs for beta4 (which I hope
will be the last beta for 3.1.0).
Ok, I didn’t see any objections to the most recent build, so I’m promoting
it to beta3. I’m putting up the announcement now, and them I’m going to go
sleep the sleep of the (sick and) tired. (Sick, really. I think I’m coming
down with something.)
I finally tracked down where the space (" ") was coming from for the
blank layer filenames: ImagePicker.imageName is initialized to " ",
so if you never set an image then it stays that way. (That line is
from revision 5, BTW, so it goes all the way back to October 2003, at
least.)
I changed it to be initialized to null, which gives the right behavior
in the case you pointed out as a bug. However, I don’t know whether
anything else was depending on the filename to be nonnull for empty
layers, so I can’t say if this breaks other things (Brent? Rodney?).
Only thing I can think of is writing the piece’s type to a savefile or saved module. Should be fine so long as you can save/load games with blank piece images.