Null keystroke for a Property Sheet trait in a piece prototype causes crash when loading for editing or running (or at least it does for me). Bug Tracker has a report for a similar bug going way back to 2004, but it’s closed, with a work-around posted in the comments.
I eventually figured out the work-around on my own. I also experimented with using null keystroke for a Dynamic Property trait and got no crash, but the Dynamic Property then no longer worked as intended. Seems keystrokes are fairly mandatory. (I’m new to VASSAL, so still figuring things out)
Crashes suck. Should this be re-opened, if not already? Running Mac OSX 10.4.11, Java version 1.5.0_16, VASSAL version 3.1.6.
The Bug Dialog said “VASSAL was unable to submit your bug report.” Here’s the error log:
01 Jul 2009 06:57:32.757 0 – Starting
01 Jul 2009 06:57:32.761 0 – OS Mac OS X
01 Jul 2009 06:57:32.761 0 – Java version 1.5.0_16
01 Jul 2009 06:57:32.761 0 – VASSAL version 3.1.7
01 Jul 2009 06:57:33.170 0 – Manager
01 Jul 2009 06:57:43.498 0 – Loading module file /Users/mluscher/Documents/Gaming/VASSAL/my module
01 Jul 2009 06:57:43.500 0 – Loading module my module
01 Jul 2009 06:57:43.505 0 /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/java -Xms256M -Xmx512M -DVASSAL.id=1 -cp /Applications/VASSAL-3.1.7.app/Contents/Resources/Java/Vengine.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/.compatibility/14compatibility.jar -Xdock:name=my module -Xdock:icon=/Applications/VASSAL-3.1.7.app/Contents/Resources/VASSAL.icns VASSAL.launch.Editor
01 Jul 2009 06:57:44.635 1 [Fatal Error] :44:118: Character reference “�” is an invalid XML character.
01 Jul 2009 06:57:44.639 1 java.lang.IllegalArgumentException: java.io.IOException
at VASSAL.launch.BasicModule.build(BasicModule.java:115)
at VASSAL.build.GameModule.init(GameModule.java:783)
at VASSAL.launch.EditModuleAction.loadModule(EditModuleAction.java:49)
at VASSAL.launch.Editor.launch(Editor.java:66)
at VASSAL.launch.Launcher$1.run(Launcher.java:161)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
Caused by: java.io.IOException
at VASSAL.build.Builder.createDocument(Builder.java:156)
at VASSAL.launch.BasicModule.build(BasicModule.java:104)
… 11 more
Caused by: org.xml.sax.SAXParseException: Character reference “�” is an invalid XML character.
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:98)
at VASSAL.build.Builder.createDocument(Builder.java:144)
… 12 more
It finally dawned on me what this error message means: The XML entity �
is the null character, which I think we must be getting when some value
which is null is written out to the buildFile.
I thought of that too, but I’ve never seen it happen. How do you get 0x0 into one of the fields? Is it possible that a field is actually null when not initialised and if you don’t put anything in it gets written out? Take a look at one of the bad buildFiles. Which field is it?
It’s the Keystroke property of a Property Sheet trait. For clarity, I’ve attached a jpg showing the Property Sheet editor window with the troublesome field circled. For a newly created Property Sheet component, the Keystroke value is ‘P’. Deleting the Keystroke value - leaving the field blank - produces the offending null when I save the module.
From the buildFile, this is the XML element for a game piece with the offending “”
<VASSAL>+/null/propertysheet;0myProperty1~0myProperty2;Properties;;0;;; delete;Delete;68,130\ piece;;;red counter;my piece/~~~ \ null;5;0;0</VASSAL>
And this is what it normally looks like with a non-null Keystroke (“” replaced with “P”):
<VASSAL>+/null/propertysheet;0myProperty1~0myProperty2;Properties;P;0;;; delete;Delete;68,130\ piece;;;red counter;my piece/~~~ \ null;0;0;0</VASSAL>
Hand-editing the bad buildFile to replace “” with a valid character fixes the problem.
EDIT: That’s weird: the forum software seems to truncate those XML tags to just . Should be {VASSAL.build.widget.PieceSlot entryName=“my piece” gpid=“0” height=“54” width=“54”} and {/VASSAL.build.widget.PieceSlot} but with <> instead of {}.
This particular Keystroke field has some other unusual charactersistics. It only accepts a single character - no modifiers like CTRL or ALT. Yet the resulting key-stroke to open the Property Sheet DOES require the CTRL key. i.e. if the Keystroke value is “P”, the actual key-command is CTRL-P. Also, whatever letter I use for the Keystroke value must be entered as uppercase. Lowercase doesn’t work. Keystroke fields for all other components accept modifier keys, or the value can be deleted with no ill effects.
While I fixed the PropertySheet from writing out any more � entities to the buildfile, I didn’t do anything about dealing with the issue if the buildfile is already corrupted.
I’ve just tried it out and the illegal entity prevents you from editing the module, so the only way to fix an existing problem module is to manually editing the buildfile.
Better. The keystroke window now behaves more like those in other components: the keystroke value can be changed to single keys or key+modifier combos, with CTRL P as the initial/default value.
A couple of issues tho:
(note: so far, I’ve only checked a Property Sheet that’s part of a Game Piece defined in a Game Piece Palette)
In the VASSAL editor, if you change the keystroke for a Property Sheet, it’s not immediately reflected in the example piece that’s displayed in the editor window, or in the piece as displayed in the Game Piece Palette. For most other components I’ve tried, changes are immediately reflected. Once I did any of the following, the change was correctly reflected:
a. closed and saved the module, then re-opened it (for editing or playing).
b. re-opened the game piece editor and then pushed the “Cancel” button.
c. started a new game from within the VASSAL editor, then instantiated a new piece by dragging it from the palette onto the map. In this case, only the newly instantiated piece had the changed Property Sheet keystroke.
2. Deleting the keystroke for a Property Sheet isn’t possible. It just reverts to the default CTRL P. Well, that’s one way to solve the original problem. All other game piece components I’ve used seem to allow you to delete the key-command (although the behavior if you do so varies a bit depending on the component). IMO, it should be permissible to not provide a key-command for a component - in which case it could only be accessed via the pop-up menu.
This is a bug. Joel, I have fixed this in swampwallaby-3.1@5857
In Vassal 3.1 and earlier, the ‘command’ to initiate any trait is transferred via the KeyStroke not the Menu Command. Therefore, any trait that allows you to remove the KeyStroke cannot be activated via any means whatsoever. So it makes no sense to allow the Property Sheet to have no KeyStroke, you will not be able to invoke it. (Some traits have multiple commands and it makes sense to allow the KeyStroke on a command to be cleared to disable the command).
Vassal 3.2 will use a new scheme for specifying KeyStrokes that allows you to have Menu-only commands.
The fundamental problem here is that reading a bad character entity is
considered fatal by the default XML parser. You can install a custom
error handler and you can use it to ignore errors which the parser
considers recoverable, but after ErrorHandler.fatalError() is called,
the parser is done—there’s no obvious way to get it to continue on,
because it thinks its in an unrecoverable state.
So, unless we want to write our own XML parser to handle this, the only
thing we can do is offer advice to people for how to fix buildFiles
to which this has happened.
All other game piece components I’ve used seem to allow you to delete the key-command (although the behavior if you do so varies a bit depending on the component). IMO, it should be permissible to not provide a key-command for a component - in which case it could only be accessed via the pop-up menu.