How do you define the “VASSAL.port” property as referenced inside
Launcher.java? I tried other modules without any problem but when I
tried VASL, then it crashed at that point. So I added
-DVassal.port=5800 as VM arguments to the debug configuration and the
launch ended with a caught exception. Wrong port number?
This is the port on the loopback device on which the Module Manager
listens. The port number is specified by the MM when it launches a
Player or Editor, and is likely to change with each run of the MM.
If you’re running the Player in a debugger, you should be using the
–standalone flag and omit defining VASSAL.port.
I added the standalone flag and debugged it as Launch.Player and I ran into this attached uncaught exception in jpg. It is not just VASL but other modules as well. So I think something is missing for the debugging of the Launch.Player main class.[attachment=0]error.jpg[/attachment]
Hi Lance,
That error is actually indicating that Vassal can’t find the icons that included in the trunk source. In your src folder, there should be a folder named icons containing 5 more folders containing the icons. The icons missing are VASSAL.svg from the scalable folder and VASSAL.png from the other folders. I’ve just run Player under the eclipse debugger on the latest trunk with no problems.
Brent.
It turned out the problem did have something to do with the VASL mod. I wonder for the 3.2 build, how should the VASL map files be set up in the package? Currently, when I try to load up VASL, start a new game offline and then select a new board, the program will crash at:
vassal.build.module.map.boardPicker.Board.java’s line 389:
if (obs == map.getView()) …
The map object is null.
Note that I used Vassal 3.2’s VASL and CASL classes to recreate a corresponding VASL.mod for this test. (Current VASL.mod contains classes that use VASSAL.tools.image.memmap.MappedBufferedImage package.) I wonder why map is null here. How was it done before in 3.1?
It turned out the problem did have something to do with the VASL mod. I
wonder for the 3.2 build, how should the VASL map files be set up in the
package? Currently, when I try to load up VASL, start a new game
offline and then select a new board, the program will crash at:
vassal.build.module.map.boardPicker.Board.java’s line 389:
if (obs == map.getView()) …
The map object is null.
You might be able to change this to
if (map != null && obs == map.getView())
but I don’t know whether this will be hiding a deeper problem.
Note that I used Vassal 3.2’s VASL and CASL classes to recreate a
corresponding VASL.mod for this test. (Current VASL.mod contains
classes that use VASSAL.tools.image.memmap.MappedBufferedImage package.)
I wonder why map is null here. How was it done before in 3.1?
Have you checked your changes into the repo so we can see them?
I added the changes as suggested but instead of the crash, I got blank maps. So, it seems to be that something new in 3.2’s Vassalengine code is not working well with VASL. (As an experiment, instead of the current release of VASL.mod, I replaced it with a copy of the VASL.mod that was built with 3.2’s code and loaded it up with Vassal 3.1 GA build. Then I had no problem loading up the mapboard.)
I have not checked in the change done in ASLboard.java. I will do it soon.
Oh, I just noticed that there are quite a few lines of “FIXME” in that Board.java file, especially around the problem areas. I wonder if they are related.
Oh, I just noticed that there are quite a few lines of “FIXME” in that
Board.java file, especially around the problem areas. I wonder if they
are related.
Many of those indicate that the exceptions being caught are bugs if
they occur, but won’t be bugs if/when some other code is written. I
doubt that those are relevant.
I added the changes as suggested but instead of the crash, I got blank
maps. So, it seems to be that something new in 3.2’s Vassalengine code
is not working well with VASL. (As an experiment, instead of the
current release of VASL.mod, I replaced it with a copy of the VASL.mod
that was built with 3.2’s code and loaded it up with Vassal 3.1 GA
build. Then I had no problem loading up the mapboard.)
I have not checked in the change done in ASLboard.java. I will do it
soon.
You might have been having problems with bugs in the trunk which have
been fixed since you posted this. Do you setill have problems with
trunk@HEAD?
Yes, unfortunately as late as the trunk dated on 10/11/11. I checked for the map object’s null value. That fixed up the crash but the VASL board cannot be loaded at all. When I click the “Finish” button, the VASL controls panel will post lines of output like this:
Bad Data in Module: Image not found 2980ec082ac2a9411d7e0f…
I thought someone working on VASL might have noticed this by now but still it seemed to be only me. So, any clue on what is going on here or where the above error could have come from?
Yes, unfortunately as late as the trunk dated on 10/11/11. I checked
for the map object’s null value. That fixed up the crash but the VASL
board cannot be loaded at all. When I click the “Finish” button, the
VASL controls panel will post lines of output like this:
Bad Data in Module: Image not found 2980ec082ac2a9411d7e0f…
I thought someone working on VASL might have noticed this by now but
still it seemed to be only me. So, any clue on what is going on here or
where the above error could have come from?
The filename in the error message is for a map tile. (Map tiles are
identified by the SHA1 of some of their identifying data. See
TileUtils.tileName() if you want to see exactly how this is computed.)
What’s the full error message? This appears to be truncated.
Please feel free to take a look. I can’t use the VASL.mod out there because those released VASL mod builds are still using the MappedBufferedImage.class that you took out in Vassal 3.2. Now I think I realize why I am the only one who have seen it.
The VASLmod file that I use for testing is built with a modified ASLBoard.java in the ASL-src tree that removes its dependency on the missing MappedBufferedImage.class. For some reason, I thought that you checked that change into ASLBoard.java but then as I just checked, it is still not there.
I am also attaching all the Bad Data error outputs.
I just checked in the change in ASLBoard.java to my branch that removes
its dependency on the MappedBufferedImage.class.
You also checked 7993 into the trunk. I try to review the code going
into the trunk, so I’d prefer if you’d let me merge to the trunk
instead. (The change looks ok, though.)
Sorry about that. I thought I checked it only into my branch. I have
not looked into that problem since my last post as I was waiting for
your reply.
It’s not a problem, just wanted to let you know for the future.
I wonder if the packaging of the VASL.mod needs to be done in a
different way as I don’t see how your code change affects only VASL but
not others.
VASL has numerous custom classes which extend ones in VASSAL. My guess
is that one of them is extending a class in a way which was ok in 3.1
but is not ok in 3.2.
I might see if there’s anyting I can do this evening.
I just updated the latest VASSALengine 3.2 code and noticed that the latest changes broke the ASL src code in at least six files. For example, in ASLHexGrid.java, it has:
public class ASLHexGrid extends HexGrid {
…
public ASLHexGrid(double height, boolean alt) {
super(height, alt); ---------> error now in Eclipse IDE after updating the VASSALengine code.
}
Going back to HexGrid.java, I noticed that the latest version of this file had a huge change and that constructor needed by ASLHexGrid above is no longer there. HexGridX.java also does not have it.
I guess I need to dig a bit more to see what is going on with the new VASSALengine code.
I just updated the latest VASSALengine 3.2 code and noticed that the
latest changes broke the ASL src code in at least six files. For
example, in ASLHexGrid.java, it has:
public class ASLHexGrid extends HexGrid {
…
public ASLHexGrid(double height, boolean alt) {
super(height, alt); ---------> error now in Eclipse IDE after
updating the VASSALengine code.
}
Going back to HexGrid.java, I noticed that the latest version of this
file had a huge change and that constructor needed by ASLHexGrid above
is no longer there. HexGridX.java also does not have it.
I guess I need to dig a bit more to see what is going on with the new
VASSALengine code.
Ah, right. I suspected this might be a problem. These changes come from
Pieter’s refactoring of the grid code.
Pieter, can you advise Lance on what needs changing for VASL?
Let me upload the screenshot of the errors that are left so far. I have sort of fixed up something on the ASL side. Let me know if I should post the screenshot in another thread. Thanks.
