swampwallaby-merge@3515 and 3516 fixes the IOException when saving games from a module with no metadata.
To be able to debug the Player under Eclipse, I need to run it as a stand-alone program with no MM. But this causes it to wait for ever trying to read from the non-existent MM’s socket. I have hacked it on my copy to get past this for now, but can we have a -standalone option for the Player and Editor which will ignore the MM?
Ignore my previous code for finding the module name from a 3.1 save game. The best way is:
// Determine file type and build an appropriate metatdata class
AbstractMetaData data = AbstractMetaData.buildMetaData(file);
if (data == null) {
// This is not a Module, Extension or Saved game of any type, old or new
}
else {
if (data instanceof SaveMetaData) {
String moduleName = ((SaveMetaData) data).getModuleName();
if (moduleName.length() > 0) {
// Got a valid module name for the save game
}
else {
// This is a pre 3.1 save file, can’t tell the module name
}
}
else {
// This is either a Module or an Extension file, not a saved game
}
The first thing you do with any double clicked file is call AbstractMetaData.buildMetaData(file) and go from there. You could get any file presented using drag and drop? buildMetaData() should recognize any old or new module, extension or save game format.
The option is --standalone. (I’m uncertain whether this is an option
we want to publicize… For now, I’ve omitted from the help, for
which see below.)
Also, I’ve added a port of GNU Getopt for command line parsing so
that we have a standard, uniform, bug-free way of doing it. (The
Getopt JAR is 55k, so we pay virtually nothing in file file size
for this.)
This stuff shows up in the new VASSAL.launch.LaunchRequest class.
Also, you can get a summary of options and usage with the --help
option.
Yet to do: Invalid option combinations are not handled very
gracefully (right now by throwing an IllegalStateException, blech!).
I added some utility code to AbstractMetaData for clasifying file types,
and an adaptation of your code above to ModuleManager for finding modules
by name. I also added some code to the tree stuff to canonicalize Files,
because otherwise you could end up with the same module listed many times.
File.equals() sometimes returns false for files which really are the same,
e.g. if one is an absolue path and the other is relative.
It’s now possible to start games from the command-line by giving just
a save or log, so long as they have the metadata and the ModuleManager
knows about the module. The VMOD and VLOG file associations should also
work on Windows now.
(It’s not clear to me whether the keys for this belong in HKLM or in
HKCU. What’s the best way to go for things like this?)
One remaining thing which occurred to me today is that we need to have
the ModuleManager not always use the same port on the loopback device,
since that would prevent two users on the same machine from running
VASSAL at once.
The new mechanism for extension detection in the opt parser killed the importer. Fixed in r3547 where I forgot to add a log which should have said that I fixed it.
I’m still waiting to hear back from a Windows user on whether the
file associations work. This, and one more thing I’m detailing below
are the last blockers for 3.1.0-beta1.
I fixed this problem this evening. Now the ModuleManager will choose
a random port on the loopback device the first time it runs, and will
keep using that port. It’s also possible to set the port to use via
the command-line, though the only reason to do this would be if the
randomly-chosen port was bad for some reason.
This makes it possible for multiple users on the same machine to each
have a copy of VASSAL open, as their individual ModuleManagers won’t
be listening on the same ports now. I don’t expect that this will be
a very common use case, but it should work if anyone tries it.
There’s also a (very) minor security issue this raises—namely that
another user on your machine could send commands to your ModuleManager
if they found out what port it was listening on. This can only happen
in such limited circumstances (e.g, one user logged in at the machine
and another logged in remotely via SSH) that it’s almost not worth
bothering about. A simple solution would be to have the ModuleManager
respond to commands prefaced by a randomly-generated key taken from
the user’s prefs. That’s so simple I’ll probably implement it, but
it’s not a significant enough problem to hold up 3.1.0-beta1.
The final problem I’ve noticed is minor, but annoying: The prefs for
the Server Status pane in the Module Manager aren’t sticking and I
don’t see why not. I tried to fix it in 3557, but didn’t succeed. I
expect that the solution to this is very simple, but it’s not coming
to me.
windows - vmod, vlog and vsav all launch with 3558 no problems.
One thing I noticed though - saving a game or log, when it goes to the native OS dialog the “file as type” box shows “all files” - it should show *.vsav for saves and *.vlog for logs etc… like other apps - their registered file types
I concur with everything but what you say about newly created modules and
extensions. I think they shouldn’t appear in the MM if they haven’t been
saved yet—until that point, none of the operations the MM can do on them
are applicable.
Yes, that is what I meant. Whenever the Editor Save’s or Save As’s a module or extension, or when the Player Saves a file, then it should send the pathname to the MM which may cause an update of the display.