Modules disappearing
A common cause of the problem that modules disappear from the module manager listing, is because the modules are stored on some transient (non-permanent - relative to the host machine) storage, such as an external drive (USB, network, etc.) or some sort of cloud storage (Google Drive, OneDrive, etc.).
When Vassal starts up the Module Manager, it will check if it can access the modules that it knows about. If a module file (.vmod) cannot be found, then it is removed from the Module Manager. This is by design, so as to not clutter the Module Manager with unusable files.
However, if you do store your modules in a transient location, for example to be able to share them across machines and environments, it may be frustrating to have modules disappear from the Module Manager listing.
Work-a-round
Vassal keeps a registry of all known modules, etc., as well as settings for individual modules in a user-specific directory
| OS | Directory |
|---|---|
C:\Users\USERNAME\AppData\Roaming\VASSAL\ |
|
~/Library/Application Support/VASSAL/ |
|
~/.VASSAL/ |
Specifically, the file
| OS | File |
|---|---|
C:\Users\USERNAME\AppData\Roaming\VASSAL\prefs\V_Global |
|
~/Library/Application Support/VASSAL/prefs/V_Global |
|
~/.VASSAL/prefs/V_Global |
contains a list of the known modules as well as the most recently opened modules.
Thus, if you back-up that file from time to time,
| OS | Back-up command |
|---|---|
copy C:\Users\USERNAME\AppData\Roaming\VASSAL\prefs\V_Global C:\Users\USERNAME\AppData\Roaming\VASSAL\prefs\V_Global.backup |
|
cp ~/Library/Application\ Support/VASSAL/prefs/V_Global{,.backup} |
|
cp ~/.VASSAL/prefs/V_Global{,.backup} |
and restore it from that back-up
| OS | Restore command |
|---|---|
copy C:\Users\USERNAME\AppData\Roaming\VASSAL\prefs\V_Global.backup C:\Users\USERNAME\AppData\Roaming\VASSAL\prefs\V_Global |
|
cp ~/Library/Application\ Support/VASSAL/prefs/V_Global{.backup,} |
|
cp ~/.VASSAL/prefs/V_Global{.backup,} |
you will not need to re-import the modules into the manager.
Of course, that requires a bit of discipline on your behalf.
The above back-up and restore commands will store the back-up file next to the real file. The V_Global file could also be backed-up to the transient storage and then restored from there.
Another work-a-round
Another option is to use VASSALLauncher from over at gamesquad.com. This app will wrap your module manager in another manager, and copy configurations for Vassal and modules in as needed.
Note, if you use this option, you should commit to that option. Do not mix the use of the regular Module Manager and VASSALLauncher as that can lead to some funny and unexpected consequences.
Future directions
The relevant code in Vassal is in the method VASSAL.launch.ModuleManagerWindow#buildTree (specifically lines 577-587).
There are a number of options for how to deal with module files that are not accessible at the time when the Module Manager starts up:
-
Add command line option
--keep-modulesand it’s compliment--clean-modules. If the first option is given, then modules are not removed from the list if they are not accessible, and if the second option is given (which would probably be the default),then non-accessible modules are removed. -
A suggustion by @Nico165 is to gray-out (and disable launching) of modules that are not accessible when the Module Manager starts up. Actions could then be added to the Tools menu to clean the list of in-accessible modules, or to rescan the modules to see if they are accessible.
This would entail moving the logic to discover accessibility to
VASSAL.launch.ModuleManagerWindow.ModuleInfowhich would have the new member functionsisAccessibleand which could be used to gray out (as done if the modules Vassal version is newer than the executing Vassal version).With this option, there would be no
--keep-modulescommand line option, but the command line option--clean-modulescould be added which would force-clean the list of modules on load.