Ben, I know what the problem is now with rotation and layers. FreeRotator
works by capturing an image of the GamePiece it wraps, and then rotates
that image. In order for this to work properly, FreeRotator needs to check
whenever it repaints whether the underlying GamePiece has changed,
and if so paint an updated version instead of the cached version. I broke
this sometime ago on my branch but didn’t catch it because in all of the
modules I tested with, every rotating piece had no other traits—and hence
the cached versions could never become stale.
I haven’t solved this problem yet—I want to sleep on it, since this
is related to some other structural problems I see with FreeRotator.
So, here’s another build, containing a few more bug fixes, but not a
fix for your bug yet:
The last (new) bug I see is that I’m interpreting the zoom levels stored
in modules backwards (i.e., old zoom level n comes out as (max - n + 1)
instead of n).
I’ve now fixed the zooming bug mentioned in the previous post.
With that, I believe that all of the bugs mentioned so far on this thread
are fixed, namely:
Temporary files are removed on shutdown on all platforms I’ve tested
(Linux, Windows), except perhaps if VASSAL is kill-9’ed, in which case
the temporary files will be cleaned up on the next run.
Memory-mapped files are only created so long as there is still sufficient
address space; otherwise, large images are loaded into RAM as before.
Piece rotation works properly.
Classpath problems are gone.
I played part of a game of Twilight Struggle this afternoon with svn2801
without encountering any problems.
There are two things which I’m still working on, which are:
How to indicate that images are loading, and
Adjustable settings for image processing. (I’m not sure what options
there should be. I could use some suggestions here.)
What I’d like from anyone who has time is to try this build and report
back as to whether/how it works for them. If no one finds any problems,
I’d like to promote this build to be the first beta release for 3.1.0.
Just an option to skip the tiling and memory map files and load the full images into memory as before. Default to the new behavior, and we can reserve the right to remove the option in the future once we know that it works for everybody. The preferences setting shouldn’t be over-technical, something like “Faster map loading” or “Use tiling to speed up map drawing”
Is there any way to use these recent builds without them reporting to an opponent that they’re using an earlier version of Vassal? It would be nice to test these builds properly without burdening my opponents.
I loaded the Europe Engulfed module (v1.54), selected the 1941 Campaign setup then opened the “Axis Force Pool” window.
First thing I noticed was the default zoom level on some Maps seems to be 160%.
Will that be worth the effort without some evidence that anyone would
want to turn it off? I’d perfer to gather evidence for or against
from the betas, if we could.
Why do you want them not to report to your opponents that they’re using
an earlier version of VASSAL? It’s true that you’re using a later version
of VASSAL than they are. How it is a burden on you opponents?
The burden I think Ben mentions is that his opponents see the message and
assume that his test build is out somewhere and they should go d/l load it
and he has to explain it is a beta being tested and not to worry
The old Zoomer had FACTOR and MAX attributes, which held the scaling
factor and the maximum zoom level, respectively. Zoom levels were
exponents while FACTOR was the base: FACTOR^(l-1) would give you the
scale, if l was the zoom level.
The new Zoomer has an array ZOOM_LEVELS, which holds the scale factors
directly. This is why it’s possible with the new zoomer to zoom in
beyond 100%, and to have scales which are not all powers of the
same base.
Both Zoomers have ZOOM_START in common, which stores the initial zoom
level.
The default value for ZOOM_LEVELS is the sequence 1.6^(-2), 1.6^(-1),
1.6^0, 1.6^1. This is the same as the old default, since FACTOR defaulted
to 1.6, with the exception that it also makes it possible to zoom in to
160%. When loading modules which do not specify ZOOM_LEVELS, this default
is used.
ZOOM_START is treated as in index into ZOOM_LEVELS, one-based instead of
zero-based, and counting from the zoomed-in end. Adding another zoom level
to the high end changes the meaning of ZOOM_START—what would have refered
to 1 with the old Zoomer now refers to 1.6.
So, that’s the cause of the problem.
I don’t have a good solution yet. I could remove 1.6 from the default
ZOOM_LEVELS. That would give the old behavior, but then 160% wouldn’t
show up in the list of zoom levels by default for new modules. I could
set ZOOM_LEVELS to have 1.0 as the maximum whenever FACTOR or MAX is
defined, because in that case it’s an old module. I could set ZOOM_LEVELS
based on FACTOR and MAX when they’re defined, add FACTOR to the list of
zoom options, and increment ZOOM_START.
I guess what it comes down to is what the value is of providing scaling
greater than unity as an option in modules which were designed prior to
3.1.0.
For a start, I reenabled reading of the FACTOR and MAX attributes, so
that if they’re both present you get zoom levels scaling by 1 on the low
end and decreasing by 1/FACTOR, up to 1/(FACTOR^MAX), as before. You
can find this in svn2809:
Ben, this should give you the proper zoom levels in the Europe Engulfed
module again.
Does anyone think it would be useful to throw in FACTOR^1 as an additional
zoom level by default for old modules, or should it be left as-is? (Either
way, it’s still possible to zoom arbitrarily from the zoom dialog.)
I would say that’s an excellent idea Joel, there is many an aging grog out there who would really appreciate the extra zoom! And it works so damn well too.
So the card bug already existed in 3.0.15? In that case, it should
be looked at, but it might be better handled by Rodney or Brent.
So the issue is with the dialog text, not with the ordering of the version
numbers, right?
I don’t know what to do about this.
The code which displays the warning is in other people’s copies of VASSAL.
In the long run, we could prevent this dialog from being shown by removing
it now, and eventually copies of VASSAL with it would fall out of use. But
it presents an important warning, so I don’t like this solution.
We could have svn builds report their version number as the last released
version, but that’s bad for several reasons, among them that it hinders
error reporting and could result in modules being produced with version X
claiming they were produced with version Y and being quite broken if
run on version Y. This is even more worrying for betas and release
candidates, which might be run by a wider audience.
We could alter the version test to check whether the version number denotes
a full release, and only warn when it does, but that fails in the case
where there is a full release between the user’s version and the version
of the module creator…
