Test builds for 3.3.0

[Malnorma]

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 had no problems when using that instead of the embedded JRE (providing java appears in the security and privacy exception list).

[uckelman]

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]

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

[Malnorma]

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]

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]

Yep, all sorted now.

[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

[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.

















- 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]

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.

[bolabola]

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.

[bolabola]

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.

[bolabola]

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]

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.

[bolabola]

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.

No, I don't think so. It will simply revert the JVM back to working the way it did before HDPI support was added in Java 9.

For reference, the issue is known by the JRE developers, see here: https://bugs.openjdk.java.net/browse/JD ... 22image%22

I think the reason you can't reproduce the issue on your development setup must likely is that your have your operating system scaling set to 100%, which doesn't cause any issues.

I'll create a couple of screenshots, so you can see how the issue manifests itself.

[bolabola]

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.

No, I don't think so. It will simply revert the JVM back to working the way it did before HDPI support was added in Java 9.

For reference, the issue is known by the JRE developers, see here: https://bugs.openjdk.java.net/browse/JD ... 22image%22

I think the reason you can't reproduce the issue on your development setup must likely is that your have your operating system scaling set to 100%, which doesn't cause any issues.

I'll create a couple of screenshots, so you can see how the issue manifests itself.

I have added a couple of screenshots so you can see the issue.

As you can see, when I set my operating system scaling to 100%, everything looks fine, but on 150% scaling all images becomes blurred.