Sorry for disappearing for a couple of days. I was stymied in my attempt to run the diagnostic build on my work network because whenever I am connected to the network, either at work or from home, the command prompt only gives me the U: drive and all efforts to change directory to get over to the C: drive (where vassal is installed) were fruitless. The weird thing is that when I am disconnected from the work network, then the command prompt starts me in a subdirectory of the C drive. So I can get into C:\Program Files\Vassal is I am not connected to the network, but not if I am.
Today I fooled my computer by unplugging the network cable, bringing up the command prompt on the C: drive, and then plugging the cable back in. Then I installed the diagnostic build in the usual place, navigated to it, and gave the command to execute. The result was the exact same output as described in the messages above dated Feb 1 3:44am and 5:08am.
I’ll add too that I checked the C:\Users subdirectory for myself where a Vassal folder with the 'lock" and “key” files were and no new Vassal folder has been created there. I think this folder with the lock in it is being created somewhere on the work network where I cannot get to it. I think we need to either figure out how to make Vassal ignore the lock, or install in some way where I can find and control it.
At the end of the day, it may simply not be possible for me to run Vassal on a laptop that is associated with my work network, even when it is not connected to that network.
I’ll add too that I checked the C:\Users subdirectory for myself where a
Vassal folder with the 'lock" and “key” files were and no new Vassal
folder has been created there. I think this folder with the lock in it
is being created somewhere on the work network where I cannot get to it.
I think we need to either figure out how to make Vassal ignore the
lock, or install in some way where I can find and control it.
This kind of problem is why I hate lock files, but we were forced into
using them because Java does not provide mutexes. Anyway, this is our
problem, not yours.
I have a possible solution in mind, namely adding a command-line flag to
the Module Manager that lets you set what directory to use for VASSAL’s
configuration files. If the only problem you’re having is that your
system has a strange idea about what your home directory is, then this
should let you run VASSAL by specifying some directory you can access.
I’ll prepare another test build for you so we can see if this will work.
I’ll add too that I checked the C:\Users subdirectory for myself where a
Vassal folder with the 'lock" and “key” files were and no new Vassal
folder has been created there. I think this folder with the lock in it
is being created somewhere on the work network where I cannot get to it.
I think we need to either figure out how to make Vassal ignore the
lock, or install in some way where I can find and control it.
This kind of problem is why I hate lock files, but we were forced into
using them because Java does not provide mutexes. Anyway, this is our
problem, not yours.
I have a possible solution in mind, namely adding a command-line flag to
the Module Manager that lets you set what directory to use for VASSAL’s
configuration files. If the only problem you’re having is that your
system has a strange idea about what your home directory is, then this
should let you run VASSAL by specifying some directory you can access.
I’ll prepare another test build for you so we can see if this will work.
It will try to use a directory called “otherVASSAL” for storing what’s
in “VASSAL” now. I’m assuming that you don’t already have a directory
called otherVASSAL. If you do, move it out of the way first.
I am having the same problem. It’s looking for the key file on a removable disk. Too bad that test build doesn’t exist anymore. Any chance that 3.1.19 or 3.2 will have a command-line flag for this?
I discovered that mine was looking for the home directory on a drive that didn’t exist by using
java -cp lib/Vengine.jar VASSAL.launch.ModuleManager
That told me the path it was looking for. I don’t know what you would do if it was looking for a server but if it’s just a drive or something then you can create a partition with the same letter and create the \users[yourname]\ folders in there yourself. That got it to work for me.
Clearly it isn’t a perfect solution but it’s better than nothing.
The only J: drive was a “removable disk” drive I’m pretty sure I’ve never plugged anything into but I might have a long time ago. I have no idea what caused it to look for my home directory there.
I am having the same problem due to folder redirection. How to fix this?
java -cp lib/Vengine.jar VASSAL.launch.ModuleManager
VASSAL: IO error
java.io.IOException
at VASSAL.launch.ModuleManager.main(ModuleManager.java:150)
Caused by: java.nio.channels.OverlappingFileLockException
at sun.nio.ch.FileChannelImpl$SharedFileLockTable.checkList(Unknown Source)
at sun.nio.ch.FileChannelImpl$SharedFileLockTable.add(Unknown Source)
at sun.nio.ch.FileChannelImpl.tryLock(Unknown Source)
at java.nio.channels.FileChannel.tryLock(Unknown Source)
at VASSAL.launch.ModuleManager.main(ModuleManager.java:147)
That’s definitely different than mine.
The only reason I could fix mine was because it said
java.io.FileNotFoundException: J:\Users\Paul\VASSAL\key (The system cannot find the path specified)
I am having the same problem due to folder redirection. How to fix this?
java -cp lib/Vengine.jar VASSAL.launch.ModuleManager
VASSAL: IO error
java.io.IOException
at VASSAL.launch.ModuleManager.main(ModuleManager.java:150)
Caused by: java.nio.channels.OverlappingFileLockException
at
sun.nio.ch.FileChannelImpl$SharedFileLockTable.checkList(Unknown Source)
at sun.nio.ch.FileChannelImpl$SharedFileLockTable.add(Unknown
Source)
at sun.nio.ch.FileChannelImpl.tryLock(Unknown Source)
at java.nio.channels.FileChannel.tryLock(Unknown Source)
at VASSAL.launch.ModuleManager.main(ModuleManager.java:147)
Why do you think the cause is “folder redirection”? It looks to me
like you have a stale lock file.
I am having the same problem due to folder redirection. How to fix
this?
java -cp lib/Vengine.jar VASSAL.launch.ModuleManager
VASSAL: IO error
java.io.IOException
at VASSAL.launch.ModuleManager.main(ModuleManager.java:150)
Caused by: java.nio.channels.OverlappingFileLockException
at
sun.nio.ch.FileChannelImpl$SharedFileLockTable.checkList(Unknown
Source)
at sun.nio.ch.FileChannelImpl$SharedFileLockTable.add(Unknown
Source)
at sun.nio.ch.FileChannelImpl.tryLock(Unknown Source)
at java.nio.channels.FileChannel.tryLock(Unknown Source)
at VASSAL.launch.ModuleManager.main(ModuleManager.java:147)
That’s definitely different than mine.
The only reason I could fix mine was because it said
java.io.FileNotFoundException: J:\Users\Paul\VASSAL\key (The system
cannot find the path specified)
Would you mind trying a current 3.2.0 development build to see if you
get the same problem with that? Try 3.2.0-svn8146 or anything with a
higher svn number. 8146 is a change which affects where VASSAL looks
for its config directory on Windows; I’d like to know if it now picks
up the right thing for you.
3.2.0-svn8146-windows.exe worked for me. Thankyou for quick response. It didn’t work when I selected launch Vassal as soon as install completed. But then I double clicked on the desktop shortcut and it worked fine. Comparing to 3.1.18 version on other machine, 3.2 looks slower. Is this expected?
3.2.0-svn8146-windows.exe worked for me. Thankyou for quick response. It
didn’t work when I selected launch Vassal as soon as install completed.
But then I double clicked on the desktop shortcut and it worked fine.
Comparing to 3.1.18 version on other machine, 3.2 looks slower. Is this
expected?
What you’re seeing is image tiling, which only happens the first time
you load a module. Try loading the same module a second time, and
compare the load time with 3.1.18.