Test builds for 3.3.0

uckelman · October 21, 2019, 10:13pm

ClaudioC:

Joel,
I am playing an OCS Tunisia II game with 3.3.0.
One general remark, as I noticed that with other modules I opened yesterday, is that the game menu icons and the game board itself are displayed at a much higher “zoom” (not sure it is the right term here) than 3.2.17.
So for the same zoom level in the game, the hexes and counters look bigger, but also you see more the individual pixels of the images.

You notice that straight away by looking at the hex lines that look more jagged in 3.3.0.

I do not know if that change in resolution from 3.2.17 is voluntary, but it seems to have negative an impact (in my opinion) on the look of the game. On the other hand, the Vassal control box (where all available modules are listed) is also bigger, and that is a good point.

Hope this helps,
Claudio

I can’t replicate this. Can you post screenshots of both?

Malnorma · October 22, 2019, 12:07am

My original report was while using svn9280. Since your cleanup change was in rev 9258, I tried svn9251, but the same error occurred. I’ve attached a module for you that crashes, and one that doesn’t. The only difference is a third card added to the deck. That deck has its visible size limited to 2.

uckelman · October 22, 2019, 9:31pm

I haven’t been able to reproduce the problem on Linux. Does it still happen for you with svn9284?

Malnorma · October 23, 2019, 7:07am

9284 on macOS seems to have a problem with the embedded JRE and launching the Player from the module manager. Instead I tested by running the command line from the log (adding --standalone), and then by updating the shell script to run with the system JRE instead. Both methods showed no null reference failure for my Crash module, so that’s good news.

When launching the module from the manager, it reports a socket error with this trace:

java.util.concurrent.ExecutionException: java.io.IOException: Cannot run program "/Applications/VASSAL.app/Contents/MacOS/jre/bin/java": error=2, No such file or directory
	at java.base/java.util.concurrent.FutureTask.report(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.get(Unknown Source)
	at java.desktop/javax.swing.SwingWorker.get(Unknown Source)
	at VASSAL.launch.AbstractLaunchAction$LaunchTask.done(AbstractLaunchAction.java:604)
	at VASSAL.launch.Player$LaunchAction$1.done(Player.java:188)
	at java.desktop/javax.swing.SwingWorker$5.run(Unknown Source)
	at java.desktop/javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.run(Unknown Source)
	at java.desktop/sun.swing.AccumulativeRunnable.run(Unknown Source)
	at java.desktop/javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.actionPerformed(Unknown Source)
	at java.desktop/javax.swing.Timer.fireActionPerformed(Unknown Source)
	at java.desktop/javax.swing.Timer$DoPostEvent.run(Unknown Source)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
	at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
	at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.desktop/java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.io.IOException: Cannot run program "/Applications/VASSAL.app/Contents/MacOS/jre/bin/java": error=2, No such file or directory
	at java.base/java.lang.ProcessBuilder.start(Unknown Source)
	at java.base/java.lang.ProcessBuilder.start(Unknown Source)
	at VASSAL.tools.io.ProcessLauncher.launch(ProcessLauncher.java:111)
	at VASSAL.tools.io.ProcessLauncher.launch(ProcessLauncher.java:87)
	at VASSAL.tools.io.ProcessLauncher.launch(ProcessLauncher.java:65)
	at VASSAL.launch.AbstractLaunchAction$LaunchTask.doInBackground(AbstractLaunchAction.java:489)
	at VASSAL.launch.AbstractLaunchAction$LaunchTask.doInBackground(AbstractLaunchAction.java:244)
	at java.desktop/javax.swing.SwingWorker$1.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.desktop/javax.swing.SwingWorker.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: error=2, No such file or directory
	at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
	at java.base/java.lang.ProcessImpl.<init>(Unknown Source)
	at java.base/java.lang.ProcessImpl.start(Unknown Source)

The path to bin/java (as logged) does exist and is executable (after all, it runs the manager). I’m not entirely sure what this is about.

uckelman · October 23, 2019, 7:39pm

Thus spake Malnorma:

When launching the module from the manager, it reports a socket error
with this trace:

I cannot see a reason why this should happen—as you say, the Manager
would not start if that path did not exist or was not executable.

I’m not sure how to proceed from here.

–
J.

Malnorma · October 23, 2019, 10:07pm

Possibly the embedding of the JRE will need to be reversed. It’s a shame, because not having to deal with dozens of different JRE versions would be better. Roll on, Vassal 4.

uckelman · October 24, 2019, 12:08pm

The problem is not specific to launching java to kick off the tiling. I set up a Catalina VM last night so I could try this myself. I found that replacing the call to java with a shell script fails in the same way, as does invoking /bin/bash directly. It seems like java.lang.ProcessBuilder isn’t seeing the filesystem.

Malnorma · October 24, 2019, 7:11pm

It may be an auto-sandboxing thing. Is it able to launch /usr/bin/java? I had no problems when using that instead of the embedded JRE (providing java appears in the security and privacy exception list).

uckelman · October 24, 2019, 8:08pm

Thus spake Malnorma:

“uckelman” wrote:

The problem is not specific to launching java to kick off the tiling.
I set up a Catalina VM last night so I could try this myself. I found
that replacing the call to java with a shell script fails in the same
way, as does invoking /bin/bash directly. It seems like
java.lang.ProcessBuilder isn’t seeing the filesystem.

It may be an auto-sandboxing thing. Is it able to launch /usr/bin/java?

I don’t have a system Java installed on this VM.

Using the bundled Java, I get the same IOException with this trivial
program:

package VASSAL.test;

import java.lang.Process;
import java.lang.ProcessBuilder;

public class RunTest {
public static void main(String args) throws Exception {
final ProcessBuilder pb = new ProcessBuilder(“/bin/ls”);
pb.redirectOutput(ProcessBuilder.Redirect.INHERIT);
final Process proc = pb.start();
proc.waitFor();
}
}

This has no problem listing the contents of the working directory
on Linux.

I had no problems when using that instead of the embedded JRE
(providing java appears in the security and privacy exception list).

Is there anywhere one can check if you’re running into sandboxing?
Are denials logged? The error message is rubbish if that’s what’s
happening.

–
J.

uckelman · October 24, 2019, 8:20pm

If I run the Module Manager from the app bundle, VASSAL shows up as not sandboxed in the Activity Monitor.

Malnorma · October 24, 2019, 8:47pm

I found something - under jre/lib there is an executable called jspawnhelper, but it does not have execute permissions. When I chmod +x that, the problem is resolved.

uckelman · October 24, 2019, 9:24pm

I just found that very thing about an hour ago. It’s used by ProcessBuilder to handle some issues with forking. Aggravatingly, jlink strips the execute bits off that file when it produces a java bundle.

Try svn9285.

Malnorma · October 24, 2019, 10:56pm

Yep, all sorted now.

CloClooo · October 30, 2019, 4:27pm

uckelman:

ClaudioC:

Joel,
I am playing an OCS Tunisia II game with 3.3.0.
One general remark, as I noticed that with other modules I opened yesterday, is that the game menu icons and the game board itself are displayed at a much higher “zoom” (not sure it is the right term here) than 3.2.17.
So for the same zoom level in the game, the hexes and counters look bigger, but also you see more the individual pixels of the images.

You notice that straight away by looking at the hex lines that look more jagged in 3.3.0.

I do not know if that change in resolution from 3.2.17 is voluntary, but it seems to have negative an impact (in my opinion) on the look of the game. On the other hand, the Vassal control box (where all available modules are listed) is also bigger, and that is a good point.

Hope this helps,
Claudio

I can’t replicate this. Can you post screenshots of both?

Hello Joel,
I figured out why 3.3.0 seems to display everything with a kind of zoom.
I have setup my windows display properties to have a zoom of 125. (You can set that by right clicking on the desktop background and selecting Display Parameters (well in French it is “Paramètres d’Affichage”. That opens a Win 10 parameter screen where above the Display Resolution you have a Dropdown titled “Modify the size of Text, Applications and other elements” where I had set it to 125 just after installing Win 10.

THis 125% setting seems to be ignored by 3.2.17 whereas it is taken into account by 3.3.0.

So in fact it is not an issue, but a new way to react to that parameter. For the “Manager window” (where all the modules are listed) it is nice that this happens, but if it could be controlled in the code of Vassal, it would be better that the Game Maps do not react to this Windows setting, as the bitmap of the game does not seem to be magnified well by this.

Kr
Claudio

CloClooo · November 1, 2019, 6:09am

Joel, I am now trying to play all my ongoing games with the latest build.
Yesterday I opened the log of a Vietnam game and got the following module errors.

VG Vietnam version 4.3.4
Loading Claudio_vs_Petri_Vietnam_01236.vlog …
Bad Data in Module: Illegal date format 7/6/19 8:15 PM
Bad Data in Module: Illegal date format 7/24/18 12:24 PM
Bad Data in Module: Illegal date format 6/28/18 10:28 PM
Bad Data in Module: Illegal date format 6/26/18 9:42 PM
Bad Data in Module: Illegal date format 6/26/18 8:47 PM
Bad Data in Module: Illegal date format 5/31/18 10:50 PM
Bad Data in Module: Illegal date format 5/29/18 10:35 PM
Bad Data in Module: Illegal date format 5/29/18 8:54 PM
Bad Data in Module: Illegal date format 5/28/18 9:41 PM
Bad Data in Module: Illegal date format 5/28/18 7:06 PM
Bad Data in Module: Illegal date format 5/7/18 10:07 PM
Bad Data in Module: Illegal date format 5/7/18 7:51 AM
Bad Data in Module: Illegal date format 5/5/18 11:05 PM
Bad Data in Module: Illegal date format 5/4/18 10:28 PM
Bad Data in Module: Illegal date format 5/6/18 8:16 AM
Bad Data in Module: Illegal date format 5/6/18 6:43 PM
Bad Data in Module: Illegal date format 5/29/18 8:50 PM
Bad Data in Module: Illegal date format 5/29/18 8:59 PM
Bad Data in Module: Illegal date format 7/24/18 9:31 AM
Bad Data in Module: Illegal date format 7/24/18 10:37 PM
Bad Data in Module: Illegal date format 10/29/18 7:14 PM
Bad Data in Module: Illegal date format 11/4/18 9:35 PM
Bad Data in Module: Illegal date format 7/7/19 10:55 PM
Bad Data in Module: Illegal date format 10/4/19 10:27 PM
Loaded Claudio_vs_Petri_Vietnam_01236.vlog

The same module loads without problem in 3.2.17
I saw in some games in 3.1.17 “Bad Data” errors that come up the 1st time you load a module so I delete the module from the list of recent modules. Tried to do that in 3.1.17 but it did not occur.
I am in France and the french date format is more like DD/MM/YYYY. But my adversary might use
I tried to see into the vlog with Notepadd++if I could find a date that matches in palin text.

I create a new game in 3.2.17. Moved some counters, saved the logfile, then reopened it in 9287
The error does not appear.

No more ideas about how to identify the cuase of this error.
If you give me some indications, I might run further tests. Or send you the files themselves.
Used 9287

Kr
Claudio

uckelman · November 2, 2019, 7:16pm

Thus spake ClaudioC:

Joel, I am now trying to play all my ongoing games with the latest
build.
Yesterday I opened the log of a Vietnam game and got the following
module errors.

We’ve changed nothing in our own code which parses dates. This is
probably due to a change in Java between versions 6 and 13. I’ll need
a vlog file which triggers the error in order to troubleshoot the
problem.

–
J.

bola · November 3, 2019, 6:34pm

ClaudioC:

Joel,
I am playing an OCS Tunisia II game with 3.3.0.
One general remark, as I noticed that with other modules I opened yesterday, is that the game menu icons and the game board itself are displayed at a much higher “zoom” (not sure it is the right term here) than 3.2.17.
So for the same zoom level in the game, the hexes and counters look bigger, but also you see more the individual pixels of the images.

You notice that straight away by looking at the hex lines that look more jagged in 3.3.0.

I do not know if that change in resolution from 3.2.17 is voluntary, but it seems to have negative an impact (in my opinion) on the look of the game. On the other hand, the Vassal control box (where all available modules are listed) is also bigger, and that is a good point.

Hope this helps,
Claudio

Joel, are you running on Windows 10? I have noticed the same problem on 3.3.3.

I think the issue is that never versions of the JDK honors the scaling of the operating system. The means the images used both in the user interface and on the map is scaled twice (once by Vassal, and once by the JVM honoring the scale setting in the operating system). This makes the images render blurred (with jagged lines).

One easy fix that worked for me is to set the scaling in Windows 10 to 100% (this might not be the best solution if you are running a very high resolution monitor) as it affects all applications. If you are running Windows 10, just right click on the desktop, and choose Screen Settings → Scaling & Layout.

I haven’t looked in to this yet, but I think you can disable operating system scaling on the JVM during startup, or at least disable it specifically on the Vassal application.

Hope this helps.

bola · November 3, 2019, 6:43pm

bolabola:

ClaudioC:

Joel,
I am playing an OCS Tunisia II game with 3.3.0.
One general remark, as I noticed that with other modules I opened yesterday, is that the game menu icons and the game board itself are displayed at a much higher “zoom” (not sure it is the right term here) than 3.2.17.
So for the same zoom level in the game, the hexes and counters look bigger, but also you see more the individual pixels of the images.

You notice that straight away by looking at the hex lines that look more jagged in 3.3.0.

I do not know if that change in resolution from 3.2.17 is voluntary, but it seems to have negative an impact (in my opinion) on the look of the game. On the other hand, the Vassal control box (where all available modules are listed) is also bigger, and that is a good point.

Hope this helps,
Claudio

Joel, are you running on Windows 10? I have noticed the same problem on 3.3.3.

I think the issue is that never versions of the JDK honors the scaling of the operating system. The means the images used both in the user interface and on the map is scaled twice (once by Vassal, and once by the JVM honoring the scale setting in the operating system). This makes the images render blurred (with jagged lines).

One easy fix that worked for me is to set the scaling in Windows 10 to 100% (this might not be the best solution if you are running a very high resolution monitor) as it affects all applications. If you are running Windows 10, just right click on the desktop, and choose Screen Settings → Scaling & Layout.

I haven’t looked in to this yet, but I think you can disable operating system scaling on the JVM during startup, or at least disable it specifically on the Vassal application.

Hope this helps.

I did a bit more digging. Turns out you can disable the scaling subsystem in the JVM by setting the following system property on the JVM.

-Dsun.java2d.uiScale=1.0

I can’t test it, as I dont know how to set system properties on 3.3.3 beta distribution.

@Uckelman, if you can build a test distribution which sets the system property, i’ll be happy to help test it out.

bola · November 3, 2019, 7:01pm

ClaudioC:

Joel,
I am playing an OCS Tunisia II game with 3.3.0.
One general remark, as I noticed that with other modules I opened yesterday, is that the game menu icons and the game board itself are displayed at a much higher “zoom” (not sure it is the right term here) than 3.2.17.
So for the same zoom level in the game, the hexes and counters look bigger, but also you see more the individual pixels of the images.

You notice that straight away by looking at the hex lines that look more jagged in 3.3.0.

I do not know if that change in resolution from 3.2.17 is voluntary, but it seems to have negative an impact (in my opinion) on the look of the game. On the other hand, the Vassal control box (where all available modules are listed) is also bigger, and that is a good point.

Hope this helps,
Claudio

uckelman · November 3, 2019, 7:26pm

Thus spake bolabola:

I did a bit more digging. Turns out you can disable the scaling
subsystem in the JVM by setting the following system property on the
JVM.

-Dsun.java2d.uiScale=1.0

Isn’t this going to make the UI elements too small in comparison with
everything else on the system?

–
J.