Repeated Graphics Tiling - New Java Update?

Any update on this?

I have been able to get around the issue by copying all the files in the image directory to a temporary one, and then overwriting the original files with the copied ones, but obviously I would like to avoid this annoyance.

Thanks

Isn’t there already a solution, namely to fix the image file modification times?

I’d call that a workaround, not a solution.

Thus spake wargamerx:

namely to fix the image file modification times?

I’d call that a workaround, not a solution.

Maybe I don’t understand what you want, then. What would a solution
look like for you?


J.

To be able to save a module in the module editor with images files with correct dates, so that tiling doesn’t occur every time the module is opened.

As it is now, you need to unzip the completed module, manually copy the image files to another directory, copy them back and rezip the file.

Thus spake wargamerx:

To be able to save a module in the module editor with images files with
correct dates, so that tiling doesn’t occur every time the module is
opened.

As it is now, you need to unzip the completed module, manually copy the
image files to another directory, copy them back and rezip the file.

How did they get incorrect dates in the first place?


J.

Apparently something in the editor is changing the dates. I changed the image modified date from 31-Dec-1969 to the present then re-zipped the module. The graphics only tile the first time the module is opened. However, If I open the module with the editor, change nothing, save it, then un-zip it, the image modified dates are back to 31-Dec-1969. Then it’s back to tiling every time.

No idea how or why the editor would change the dates, but that’s seems to be what’s happening.

Thus spake rbrook1:

Apparently something in the editor is changing the dates. I changed the
image modified date from 31-Dec-1969 to the present then re-zipped the
module. The graphics only tile the first time the module is opened.
However, If I open the module with the editor, change nothing, save it,
then un-zip it, the image modified dates are back to 31-Dec-1969. Then
it’s back to tiling every time.

No idea how or why the editor would change the dates, but that’s seems
to be what’s happening.

I created a new module just now, added, one image, and saved it. This
was with my development version, which has no modifications to the
ZIP handling code over 3.2.15, so should not differ from it in behavior,
and the JRE from OpenJDK 1.8.0_71.

  • What are the minimal steps to take for recreating the problem?

  • What version of Java are you using?


J.

For me, the minimal steps are to create or modify any module with my existing configuration.

I can take an existing module that was working fine, load it in Edit Mode, press save without making any changes, and the tiling problem will occur whenever I load it after that.

My Java version is 1.8.0_73-b02. I’m on Windows 10, VASSAL 3.2.15.

Thanks,
Jeff

I’m using VASSAL 3.2.15 on a 32-bit Windows 10 Pro computer with Java Version 8 Update 73 (build 1.8.0_73-b02).

Thus spake wargamerx:

For me, the minimal steps are to create or modify any module with my
existing configuration.

I can take an existing module that was working fine, load it in Edit
Mode, press save without making any changes, and the tiling problem will
occur whenever I load it after that.

Does doing that reset all the file timestamps, or only some?


J.

After checking further, not all images change modified dates after editing. I’m working with the module for ‘The Kaiser’s Pirates’. All images are png files.

Images that changed dates are:
Card faces - But only one of the three backs (???)
Card mask
Charts
Player Hand board images
Private Window board image

Images that didn’t change dates are:
About Module
Main Board
Symbolic Dice
Various toolbar images
Markers

Hope this helps.

It depends. In the module where I just saved without making modifications, 70% of the files had the incorrect date. For recent modules that I have created or heavily modified, 100% of the image files have changed.

Thus spake wargamerx:

Does doing that reset all the file timestamps, or only some?

It depends. In the module where I just saved without making
modifications, 70% of the files had the incorrect date. For recent
modules that I have created or heavily modified, 100% of the image files
have changed.

When did this start? Was it after a Java version change? After a VASSAL
version change? After an OS change?


J.

For me, the problem only happens when editing a module with Java 8. Editing with Java 7 or earlier is fine, and the OS seems to be irrelevant. I’m guessing there’s some kind of incompatibility regarding timestamps in the java.util.zip library between versions 7 and 8 (assuming that’s what you use to compress the module).

Thus spake Foobarius:

For me, the problem only happens when editing a module with Java 8.
Editing with Java 7 or earlier is fine, and the OS seems to be
irrelevant. I’m guessing there’s some kind of incompatibility regarding
timestamps in the java.util.zip library between versions 7 and 8
(assuming that’s what you use to compress the module).

My guess is that something changed in Java as well, though whatever it
was isn’t affecting me with an OpenJDK Java 8 on Linux.


J.

Try the 3.2.16-svn9208 build, available here: vassalengine.sourceforge.net/builds/

Does this make any difference?

Doesn’t seem to have fixed it, I’m afraid. I’m running

java version "1.8.0_72"
Java(TM) SE Runtime Environment (build 1.8.0_72-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode)

on

Linux samsung-pc 3.13.0-79-generic #123-Ubuntu SMP Fri Feb 19 14:27:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I am also having this problem with my desktop running Windows 7 64-bit, with Java version 1.8.0_65 and with Vassal version 3.2.14. When I rename the extension of the module I am working on to .zip and then open the file with Windows Explorer, all of the image files have a Modified Date of 12/29/1899 6:00 PM. Being a programmer and knowing how dates are saved, this would equal 0 (or maybe blank) if converted to an integer.

I am NOT having this problem with my laptop running Windows 7 64-bit, with Java version 1.8.0_65 and with Vassal version 3.1.20. When I rename the extension of the module I am working on to .zip and then open the file with Windows Explorer, all of the image files have a Modified Date equal to the date I saved the file after I had made some changes.

I believe the problem is caused by some type of issue between Java version 8 and Vassal version 3.2. I hope this additional information will help get this problem corrected. It is a pain to have to wait for the graphics to tile every time I want to edit or test the module.

I have the same problem. Running MacOS X 10.11.3.

java version "1.7.0_45" Java(TM) SE Runtime Environment (build 1.7.0_45-b18) Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)

Just tried with VASSAL 3.2.16-9208 (after having the problem with 3.2.15) and same problem. I think this is related to Java update.

To reproduce I take the Combat Commander: Europe 2.3 module (http://www.vassalengine.org/wiki/Module:Combat_Commander:_Europe), make some changes to the MainMap > [Mouse-over Stack Viewer], save, and all images, vsav files, class files, txt files, wav files, htm files get reset to 0 date – my viewer shows as 1 Jan 1980 00:00. Only not the buildfile and moduledata files.

OR

The same problem happens when creating a new module. On the initial save the image date will be correct. But if I re-open the vmod file, do an edit (like the Mouse-over thing), then save, the previously correctly saved image will reset to 0 date. Tried in 3.2.16-9208.