Module library disappearing from the Module Manager

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
windows C:\Users\USERNAME\AppData\Roaming\VASSAL\
macosx ~/Library/Application Support/VASSAL/
linux ~/.VASSAL/

Specifically, the file

OS File
windows C:\Users\USERNAME\AppData\Roaming\VASSAL\prefs\V_Global
macosx ~/Library/Application Support/VASSAL/prefs/V_Global
linux ~/.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
windows copy C:\Users\USERNAME\AppData\Roaming\VASSAL\prefs\V_Global C:\Users\USERNAME\AppData\Roaming\VASSAL\prefs\V_Global.backup
macosx cp ~/Library/Application\ Support/VASSAL/prefs/V_Global{,.backup}
linux cp ~/.VASSAL/prefs/V_Global{,.backup}

and restore it from that back-up

OS Restore command
windows copy C:\Users\USERNAME\AppData\Roaming\VASSAL\prefs\V_Global.backup C:\Users\USERNAME\AppData\Roaming\VASSAL\prefs\V_Global
macosx cp ~/Library/Application\ Support/VASSAL/prefs/V_Global{.backup,}
linux 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-modules and 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.ModuleInfo which would have the new member functions isAccessible and 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-modules command line option, but the command line option --clean-modules could be added which would force-clean the list of modules on load.