java.io.IOException: Unable to overwrite /Users/herwin/VASSAL/Preferences
Data stored in /Users/herwin/VASSAL/temp2.zip
at VASSAL.tools.ArchiveWriter.write(ArchiveWriter.java:475)
at VASSAL.tools.ArchiveWriter.write(ArchiveWriter.java:266)
at VASSAL.preferences.PrefsEditor.write(PrefsEditor.java:235)
at VASSAL.preferences.Prefs.write(Prefs.java:206)
at VASSAL.preferences.Prefs.getGlobalPrefs(Prefs.java:232)
at VASSAL.i18n.Resources.(Resources.java:90)
at VASSAL.launch.ModuleManagerWindow.(ModuleManagerWindow.java:198)
at VASSAL.launch.ModuleManagerWindow.(ModuleManagerWindow.java:168)
at VASSAL.launch.ModuleManager.launch(ModuleManager.java:386)
at VASSAL.launch.ModuleManager$2.run(ModuleManager.java:281)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:633)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Second, the replay function only replays the first six moves of:
Peter O’Kane> AF2 moves K32.09 → K32.09 *
My configuration is a MacBook Pro running Mac OS X 10.6.2 and the latest Java. The second problem also occurs when I run under Windows XP in Bootcamp:
Model Name: MacBook Pro
Model Identifier: MacBookPro2,2
Processor Name: Intel Core 2 Duo
Processor Speed: 2.33 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 4 MB
Memory: 2 GB
Bus Speed: 667 MHz
Boot ROM Version: MBP22.00A5.B07
SMC Version (system): 1.12f5
Serial Number (system): W86430PMW0L
Hardware UUID: 00000000-0000-1000-8000-0017F2C4A132
Sudden Motion Sensor:
State: Enabled
I was clicking on ‘step forward through logfile’. My Java configuration is
java -version
java version “1.6.0_17”
Java™ SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
Java HotSpot™ 64-Bit Server VM (build 14.3-b01-101, mixed mode)
I tried stepping further, assuming that some moves were not being displayed, and got this (note I undid and redid some early moves):
OCS - Case Blue & GBII version 2.5
Loading CaseBlue.vsav …
Loaded CaseBlue.vsav
Peter O’Kane> AF2 moves K32.09 → K32.09 *
Peter O’Kane> AF1 moves K20.05 → K20.05 *
Peter O’Kane> AF1 moves K20.05 → K20.05 *
Peter O’Kane> S3 created in K21.20
Peter O’Kane> S2T moves K21.20 → offboard *
Peter O’Kane> S3 created in K31.01
UNDO: * Peter O’Kane> S3 created in K31.01
UNDO: * Peter O’Kane> S2T moves K21.20 → offboard *
I’m confused—I thought you said that you had stepped all the way to the
end of the log, but only got the first six moves. What you posted this
time is all of the moves I saw, which is way more than the first six.
Could you try again with stating what exactly the problem is?
The problem actually seems to be that for some of my clicks on the step forward button, nothing shows up on the display, and I get the strong impression that nothing happened. There is an interval after the sixth or so move displayed when nothing is displayed in response to clicks for quite some time, and I assumed that nothing was being displayed or would be displayed from that point on in the replay. Sorry for reporting the wrong bug, but most programmes reliably provide feedback to user commands. If you read any GUI design text, that’s a basic rule. Otherwise you get loud user complaints about it–like this one.
This is actually caused by the problem where one single ‘user action’ can generate multiple commands that require multiple ‘step’ or ‘undo’ clicks. This is one of the issues I have been working on resolving for 3.2.
I see this quite a bit when your opponent changes the stacking in a hex. In this case if you look close at the highlighted stack you can see units moving in it.
Another improvement here would be to center the map on the location in question, rather than move the map so the location appearing ‘somewhere’ on the map.
There’s already an option for doing that, with the restriction that anything
which is too close to an edge cannot be centered. Once we’ve switched to
JOGL for display, it will be possible to center any location on any map.
The plan is to fix it properly in 3.2, so that if you hit a button or command, it generates one command only that replays or undos as one single command.
Of course, it is still up to the module designer to actually make each set of actions actually generate a report.
In version 3.1.13, running the Case Blue and GBII module (v2.5) it doesn’t center the location on the screen. Instead, it moves the screen so the location is visible, usually on one edge. At least that’s what I’m seeing.
If every move is centred, then if you step through a log file quickly, the map madly flicks all over the place and it is impossible to get an idea of what is going on.
The current scheme means that if a bunch of moves happen in the same section of map, then then the map does NOT move and you get to see the units moving around the current view in a coherent fashion.
Sometimes you want exact map centering, but just as often, you do not. How do we neatly handle both requirements?
Maybe if the location of movement if off-screen then center it instead of scrolling just to have it in the visible area on the edge of screen.
If the location fits on current screen then don’t scroll, except if the boundaries of the piece might cross the visible area (part of piece hidden), then adjust so entire piece will fit (but don’t scroll it to center).
This is perhaps one area where it may be impossible to come up with
the right answer, since what one wants is likely to be different
depending on the context.
On Jan 14, 2010, at 2:25 PM, morvael wrote:
Nevertheless, this sounds like it might be a good heuristic. It
means that if things really are spatially close by, it will minimize
the number of times the screen scrolls. But I would keep the
behavior simple and consistent. So, I would suggest doing only one
kind of screen readjustment (centering) anytime any part of the piece
is off-screen. *
(In the worst case, imagine moving down a line of units, moving them
one-by-one. Without centering, you would eventually shift the view
slightly each time the next item comes up. With centering, the
movement would be larger, but less frequent)
Now, if the view actually scrolls rather than jumps, this will be
nicer. I can’t recall what actually happens in Vassal now. Maybe
that would have to wait for JOGL?
Is there potentially a problem if someone is moving a large terrain
“piece” that is larger than the viewport?