Vassal not launching

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.

Thus spake ronljacobsen:

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.


J.

Thus spake Joel Uckelman:

Thus spake ronljacobsen:

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.

Try this build:

vassalengine.org/~uckelman/b … indows.exe

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.


J.

I was having the same problem. I installed and ran the last build that you provided and it now works. Thank you.

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 am having the same problem. It will not launch. I am bumming…

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.

Thus spake armadillobandwagon:

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.

What path was it looking for?


J.

J:\users\paul\VASSAL\key

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)

Thus spake bharath:

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.


J.

Thus spake armadillobandwagon:

“bharath” wrote:

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.

vassalengine.org/~uckelman/builds/


J.

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?

Thus spake bharath:

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?

Slower in what way?


J.

Seem to take longer to load (Start)

Thus spake bharath:

Seem to take longer to load (Start)

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.


J.

3.2.0-svn8146 works perfectly for me as well, thank you.

Thus spake armadillobandwagon:

3.2.0-svn8146 works perfectly for me as well, thank you.

In that case, I will backport the home-directory-finding change to
3.1.19, so you can take advantage of it there.


J.

Thus spake Joel Uckelman:

Thus spake armadillobandwagon:

3.2.0-svn8146 works perfectly for me as well, thank you.

In that case, I will backport the home-directory-finding change to
3.1.19, so you can take advantage of it there.

I’ve backported the bugfix to 3.1. Please check 3.1.19-snv8150 to see if
it also finds the correct location of your settings directory. If so,
then I’d like to release it as 3.1.19.


J.