The VASSAL Team is happy to announce the release of VASSAL 3.3.0.
[size=150]IMPORTANT[/size]
Things may be broken which worked in 3.2.17. If you find a bug introduced since 3.2.17, please report it.
If you save a module in VASSAL 3.3, you will NOT be able to open it afterwards with VASSAL 3.2. We recommend keeping a backup copy of any pre-3.3 modules you plan to modify in 3.3 until you’ve verified that everything works to your satisfaction.
Some modules containing custom drawing code may render incorrectly on HiDPI displays. If you are the maintainer of such a module, let us know and we can advise you about what needs updating for 3.3 in your code. (We are aware already that VASL has this problem and are working with its maintainers to update it.)
13103: Windows installer checks for 64-bit Windows, as bundled Java is 64-bit
12973: Unnecessary NullCommands being generated by Trigger Action
12861: Improved behavior of Zone editor
12825: Send keep-alive to prevent disconnection
12817: Right-clicking on unexpanded stacks no longer selects top piece
12816: Splitter between chat and map panes starts with map obscured
12805: Upgraded Batik from 1.12 to 1.13
12732: Use all available rendering hints for text
12731: javax.sound.samples.Clip fails to convert WAV files it can play
12724: Bundle Java 14 with Windows and Mac packages
12613: Advance maximum custom class version to Java 11
12579: Don’t bundle Java on Linux
12559: HiDPI support
12558: Bundle Java with VASSAL
12557: Compatibility with Java 9+
12556: Mass Piece Definer does not sort image names
12544: MacOS launcher not finding correct Java install
For changes prior to this release, see the change log.
[size=150]Minimum Requirements[/size]
VASSAL 3.3 requires Java 11 or later.
The Windows and Mac packages have an appropriate version of Java bundled with them, so there is no need to install Java separately on those operating systems.
[size=159]Help us test[/size]
Should you find any problems/oddities/bugs, please tell us so that we can
fix them for a future release of VASSAL.
A quick question about the bundling of Java. Will that take precedence over other Java installations? On my mac I have java 8 but I’m not sure if I need to remove that.
As always, be on the lookout for any issues and keep backups.
However Version 3.3.0 should be 100% upwardly compatible and should not cause any issues. The changes where not in the Game Engine, but in the back end support (graphics, network).
The only limitation will be that once a particular module (not individual game) has been saved using 3.3.0, that particular module will no longer be able to be opened using 3.2.17.
The bundled Java will be used for Vassal only and will be used instead of any existing Java installation. It won’t be installed as a standard Java installation (though you could do that if you know how) and will not affect other Java programs or installations on your machine.
So, if you have any other applications on your system that uses Java, you will still need to keep that Java 8 (or something more recent) installed. If Vassal is your only Java application, you don’t need to keep it.
Ah, I see. Given I have 10 different VASSAL PBEM opponents playing 8 different modules, this will be tricky. Can 3.3.0 be installed without uninstalling 3.2.17? I’m thinking I may not be able to get everyone to upgrade at the same time (though who knows, I might get lucky).
A quick question about the bundling of Java. Will that take precedence
over other Java installations? On my mac I have java 8 but I’m not sure
if I need to remove that.
The bundled Java isn’t installed at all. It’s private to VASSAL.
Removing Java 8, leaving Java 8, never having had Java 8 at all—none
of those will make a difference, because there’s no interaction at all
between whatever Java you have installed and the one bundled with VASSAL
3.3.0.
Ah, I see. Given I have 10 different VASSAL PBEM opponents playing 8
different modules, this will be tricky. Can 3.3.0 be installed without
uninstalling 3.2.17? I’m thinking I may not be able to get everyone to
upgrade at the same time (though who knows, I might get lucky).
Yes. For Windows, choose a “Custom” install in the installer. On all other
OSes, just put the two versions in different places.
I’m still running Win 7, 32-bit. I also still have Java version 8 update 251, although the Java website is unable to verify that it is installed (it certainly seems to be, according to my Control Panel).
Needles to say, version 3.3.1 for Windows will not install because it says it is for 64-bit systems.
I downloaded the “Other” zip, but it does not contain an installer, just some files.
I also don’t know where to get Java 11.
You could continue using VASSAL 3.2.17, unless you are using a module that someone has already started editing with VASSAL 3.3.x and you are being “compelled” to upgrade. Or you can try your luck with this AdoptOpenJDK site and see if 32-bit Java 11 or later from them works.
I’m still running Win 7, 32-bit. I also still have Java version 8 update
251, although the Java website is unable to verify that it is installed
(it certainly seems to be, according to my Control Panel).
Java 8 won’t do you any good, regardless, as VASSAL 3.3 requires Java 11
or later.
Needles to say, version 3.3.1 for Windows will not install because it
says it is for 64-bit systems.
That’s correct. Java is bundled with the Windows installer now, and
the Java we bundle is 64-bit.
I downloaded the “Other” zip, but it does not contain an installer, just
some files.
There is no installation with the “other” bundle. You put the contents of
the archive where you want it.
I also don’t know where to get Java 11.
Most places you can find Java 11+ for Windows don’t provide 32-bit builds
anymore. AdoptOpenJDK has them, however.
Select “Windows” for Operating System and “x86” for Architecture, and one
of the JRE builds (the .msi is probably the one with an installer, I
but I haven’t tried it).