Module saved into "images" folder of the module

Technical Support & Bugs
,
1

Hello everyone.

First of all, i’m not really looking for help, just bringing back a weird information/bug. Maybe if you know more about it, i’m interested on understanding how it could have happened.

I was working on editing a module (around 2Go). After some time (didn’t really checked when, found out when i tried to convert into zip) i realised the size of the module had doubled, being more than 4Go. I searched a bit and found out very fast that there was an complete vassal module saved into the “images” folder of the initial module.

I have no idea of how this can be possible. But wait, there’s more ! If i delete this extra complete module inside the “images” folder and compress back the initial module to zip/vmod, it weights less than 2Go and is “incompatible” with vassal, can’t be launched.

So i extracted this module locked into the “images” folder, started it, and found out that it was the one i was finally working on, with the last saves i made.

How did my module ended up saved into the “images” folder of itself, and edited/saved into it after that, i do not have any idea. Very weird indeed. I’m just happy i found out my modified module at the end, because i was depressed thinking i would have to do it everything from scratch !

2

At some point you either added the module file as an image, or you added a copy of the module file when you recompressed the ZIP archive.

3

First one certainly, as i didn’t do the zip conversion before realising my module was too big.

But how is it possible then that all later saves went into the one added as an image, and not into the initial one which i believed i was editing ? I’m surprised by this.

4

I think it’s not. Careful examination of file timestamps would reveal that the module file in the images directory is not the current one.

5

well, as i said, if i remove this module inside the other, i can’t play the initial module anymore, while i can execute/edit/play the one inside. But i’m probably doing sthg wrong, i guess.

6

It’s not possible to troubleshoot this further without seeing the file. Where can we get it?

7

Well, as i said, i kind of resolved it by myself, and deleted the “corrupted”/unusefull files. Just wanted to know if this already happen and if there was any explanation. Sorry for not being of any help.

8

You may wish to review this item in Tips and Tricks to have a better understanding of what a properly-constructed module’s ZIP archive looks like. It sounds very likely to me that you were recompressing things incorrectly, since you encountered the “this isn’t a module” error at one point.

9

as for this part, i’m pretty sure i did basic things right, i verified the archive had exact same structure compared to a working one. Maybe i missed an advanced thing like compressing options, but i didn’t read anywhere that some advanced compressing options were needed

10

No, compression options are not relevant. But if at any point you saw the “not a valid module” message, the only possibilities are that you either told VASSAL to try to open the wrong file or it looked like it was a module but had been recompressed incorrectly and so it wasn’t (by virtue of wrong organization of the ZIP archive’s internals).

1 Like
11

Okay, thx for this information. I don’t really remember the exact error message. I’m doing a poor job at getting relevant feed back on this strange error.

12

It’s typically hard to troubleshoot module problems without having access to the module.

13

Just to re-cap: A .vmod file is a simple ZIP archive with the following structure

<VMOD>:
  +- buildFile.xml
  +- moduleData
  +- <saves>
  +- <logs>
  +- <help files>
  `- images -+- <images>

where <VMOD> is the .vmod file, <images> are images used in the module, <saves> are any Predefined setup files, <logs> are any log files (tutorials), and <help files> are any help files defined in the module (HTML, PDF, text, …).

Let’s take something concrete - First Blood

FirstBlood.vmod:
  +- buildFile.xml
  +- moduledata
  +- Example.vsav
  +- tutorial.vlog
  +- rules.pdf
  +- help
  |  +- keys.html
  |  +- more.html
  `- images
     +- 1d6-1.png
     +- 1d6-2.png
     +- 1d6-3.png
     +- 1d6-4.png
     +- 1d6-5.png
     +- 1d6-6.png
     +- All.png
     +- Board.png
     +- ...
     +- victory-icon.png
     `- wg_hidden_unit.png

Note how buildFile.xml, moduledata, and images are in the root of the ZIP archive. Saves and logs should also be there. Any other data can be in some sub-directory if needed.

In some sense, you should never really need to unpack the archive to work on it. A sensible ZIP file manager can update, add, or removes files directly in a ZIP archive. Heck, the old zip DOS program could do that. That some “modern” Operating Systems seems to mess this up is beyond me.

It is very unlikely that the VASSAL editor would add anything into the archive that you didn’t ask it to put in.

Yours,
Christian

1 Like
14

‘River of Death’ module version 2.0 posted on this site has the same issue.

Reg

15

So this file. Note that there are two versions of that file both uploaded on 15th of May 2021: One from 20:38 and one from 23:01. Its the latter (and larger) that has the issue.

Looking at the most recent additions to the archive

$ unzip -l River_of_Death_2.0.vmod | tail -f 
    16661  2021-05-15 13:29   images/Fatigue_2_60px.jpg
    17094  2021-05-15 13:28   images/FatigueOK_60px.jpg
    16927  2021-05-15 13:29   images/Fatigue_1_60px.jpg
     8107  2021-05-15 13:29   images/Fatigue_3_60px.png
 52331799  2021-05-15 15:54   images/River_of_Death_2.0.vmod
     6234  2021-05-15 15:55   images/Law_AM_front.png
   355969  2021-05-15 15:55   buildFile.xml
      294  2021-05-15 15:55   moduledata
---------                     -------
105984776                     1555 files

we see the internal archive images/Law_AM_front.png was added at 15:54, and then some other files where modified a minute later. Now, let’s look at images/Law_AM_front.png

$ unzip River_of_Death_2.0.vmod images/River_of_Death_2.0.vmod
$ $ unzip -l images/River_of_Death_2.0.vmod | tail 
    17065  2021-05-15 13:28   images/Fatigue.jpg
    15554  2021-05-15 13:32   images/Fatigue_0_60px.jpg
    16661  2021-05-15 13:29   images/Fatigue_2_60px.jpg
   355966  2021-05-15 13:32   buildFile.xml
      294  2021-05-15 13:32   moduledata
    17094  2021-05-15 13:28   images/FatigueOK_60px.jpg
    16927  2021-05-15 13:29   images/Fatigue_1_60px.jpg
     8107  2021-05-15 13:29   images/Fatigue_3_60px.png
---------                     -------
 53652974                     1554 files

We see the last change was at 13:29 - which corresponds to the last file edit (images/Fatigue_3_60px.png) to River_of_Death_2.0.vmod before the addition of images/River_of_Death_2.0.vmod.

There really are no significant changes between the two .vmod, except

diff -xRiver_of_Death_2.0.vmod -r -u rod-old/moduledata rod/moduledata
--- rod-old/moduledata	2021-05-15 13:32:36.000000000 +0200
+++ rod/moduledata	2021-05-15 15:55:18.000000000 +0200
@@ -2,7 +2,7 @@
 <data version="1">
   <version>2.0</version>
   <VassalVersion>3.5.5</VassalVersion>
-  <dateSaved>1621110757804</dateSaved>
+  <dateSaved>1621119319095</dateSaved>
   <description>Battle of Chickamauga  {c} GMT Games 1999</description>
   <name>River of Death</name>
 </data>

I.e., the two timestamps

$ python 
>>> from datetime import datetime 
>>> str(datetime.fromtimestamp(1621110757804))
... '2021-05-15 22:32:37.804000'
>>> str(datetime.fromtimestamp(1621119319095))
... '2021-05-16 00:55:19.095000'

Note, the above times are in UTC, so assuming the author is on the west-coast of the US (UTC-9), then the times match up.

So what happened? Well, not too easy to tell. But note, VASSAL can open the module just fine.

Yours,
Christian