3.2.17 Modules not compatible with 3.4.12 + Programs

Gentlemen,

Up front, I am operating two systems 3.4.12 and 3.2.17. I haven’t updated beyond 3.4.12 … because I am afraid to.

That said, I am having enormous problems with 3.4.12 and old 3.2.17 modules.

Any time I open a 3.2.17 module with 3.4.12, the 3.4.12 automatically updates the module and changes it. This makes it unreadable in BOTH 3.4.12 AND 3.2.17. There are multiple Bad Data Image problems and this appears without regard to which original 3.2.17 built module I open. Yes, I have cleared the cache … same result. clear it each and every time between opening modules … same result.

I am forced to maintain 3.2.17 modules opening them ONLY with 3.2.17 Vassal.

And now I have entirely lost confidence in the new builds of Vassal. This problem with new Vassal is MASSIVE.

  1. 3.4.13 is the current 3.4 release. If you’re using 3.4, have you checked that?

  2. For troubleshooting a problem like this, we need the module.

I have had problems with the following:

Princeton - War Diary
Shipetaukin - War Diary
Trenton - War Diary
Prairie Aflame V2
ElGranCapitan

Something I came across was that current versions of Vassal appear to validate images when they load rather than when the image is required. The only evidence I have for this is my experience with the Wellington module, which I investigated and fixed, by resolving what turned out to be a misnamed image. I stress, under v3.2.17 the module did not give an error message until one accessed the piece that had the bad image, whereas v3.5 (in my case) gave the error as soon as the module loaded.

In the case of Wellington, the piece concerned would not be seen in all games and was not critical, so it may have gone unnoticed under v3.2.17. Perhaps this doesn’t apply in the case of the above 5 modules, but I thought I would mention it.

Mark

Where are those modules hosted? I don’t see them on the Vassal site.

The difference is that 3.5 reports the failure at the first attempt when an image can’t be loaded, which will often be when the image is read to get its pixel dimensions, rather than to display it, whereas 3.2.17 would not do so until later the point at which the image was to be drawn. The cause of the problem—a misnamed image—is the same in both cases, but 3.5 tells you about the problem as soon as we discover it. This should make such problems easier to spot and rectify, which your experience with Wellington bears out.

Well done on fixing that problem. Little contributions like that add up and benefit everyone.

As for the 5 modules Cundiff mentions, I’m happy to investigate once I have access to them.

Prairie Aflame v2 is here: limeyyankgames.co.uk/node/3443

You will need to contact me via e-mail so I can post the download links for the other four.

The War Diary modules are for games that have yet to be published, but that are completed. I built them for War Diary and for the game designers. There are other such games for War Diary I have not yet tested and which have not seen publication as yet.

El Gran Capitan is a Playtest module for Europa Simulazioni. They’ve just released the game. I do not know if the module I provided them will be used as a publication module or not; I rather think it needs work for a publication module. If you wish, you might contact them and see if they would like YOU or one of the other Gurus to polish the basic module I built for their testing.

Send me your e-mail address and I’ll provide you my DropBox links, OR, contact me first at tdchistorian@gmail.com

My email address is available to the right of every post of mine: uckelman@nomic.net.

I opened the “Prairie Aflame V2 (1).vmod” in 3.2.17, 3.4.13, and the current development version (3.3.5-SNAPSHOT-658cfb0fe) and had no errors at all.

I need more detailed instructions to replicate what you’re seeing, or at least to know what precisely the error messages are that you’re seeing.

I’ve dropped you an e-mail with DropBox links.

And this is the error I got tonight while I attempted to go back and work on a module I began in 3.4.12:

Bad Data in Module: Unrecognized image type GradiscaMappa2.jpg

BUT this map I’ve been working on for over a week, and NOW SUDDENLY it decides not to work? I’ve drawn 66 distinctly different Zones on that board and now it decides not to work. That map file has been just fine for 2 weeks. This isn’t some mis-naming of a file. For my money there’s something distinctly wrong with this program.

Tom

Hi Tom,

I opened the Prairie Aflame v2 module for edit in v3.4.12 and v3.4.13 and saved it back before opening again. Both times without error.

Focussing on Prairie Aflame v2; please could you post a copy of the onscreen error messages that you are seeing when you try to edit the module in Vassal v3.4.12 and the exact sequence you follow to replicate the error. Also, once you see the errors, go to your Vassal Module Library window, find Help…Show Error Log and post a copy of the error log that you find there.

Maybe it is a difference in our platforms, I am running on MacOS Big Sur. It would be helpful to know what platform you are using and, if Linux, what version of Java you are using for Vassal.

If your latest issue is something different, I’d be happy to try and replicate that problem too. Share a module link on this thread or via PM.

Mark

Received.

I opened El Gran Capitan, Princeton - War Diary, and Shipetaukin - War Diary in 3.2.17, 3.4.13, and the current development build (3.5.5-SNAPSHOT-62123c22b). I opened Trenton - War Diary in 3.4.13 an the current development build—but not 3.2.17, as the Trenton module was saved under 3.4.

In all cases, I saw no Bad Image messages.

You mentioned in your email that you converted all of the PNGs to JPEGs, which will result in lower quality images and is usually the wrong approach. Did you see any errors after doing that? Before doing that?

Have you given me the modules after you’ve corrected the problems you were seeing? If so, they’re of no use for tracking down the problems. What we need are modules which are actually exhibiting the problems now.

I converted only those images that were not showing up in png. These I converted to jpg and they worked. Most of these showed no “bad image” error message, they simply failed to show in the module after it was saved. However, when bad image messages Did show up, I then converted those to jpg and that solved the problems. So, yes, those modules I’ve repaired using this process, replacing the bad image pngs with jpgs. So the images in these modules are a mix of good pngs and jpgs.

However, last night’s problem couldn’t be solved that way as the image was already a jpg. Worse, the map image was one I had already seen work because I’d drawn zones on it to the tune of over 60 of them until last night. So I knew the image was not the problem. So, I uninstalled 3.4.12 and then reinstalled it. That solved the problem.

In answer to a previous question, I’m running this on a Win7 Laptop with Java 8 Update 281 (64 bit).

In the case of Prairie Aflame, Both my opponent and the game’s designer were unable to get the game to run until I explained how to get around the problem. In fact the designer Still is unable to get it to run. In both cases they were running far more advanced versions of Vassal and the game simply wouldn’t open.

I told them to uninstall their new versions. Install 3.2.17. and Download a new copy of the Prairie Aflame module and open it only with 3.2.17. After that they could re-install their newer versions of Vassal, only make sure they didn’t open Prairie Aflame with the new versions of Vassal because it seems they convert the old module to the new standard and then you get problems.

So, to be clear: You don’t have any module which is exhibiting any of these problems right now?

That’s what we need in order to investigate further.

Can we get errorLogs from those failed runs?

I will make inquiries of my opponent and the game’s designer.

Do I have any current modules with problems? I haven’t tried to open any of my older modules with the newer vassal. I’ve been afraid to do so.

Have you considered making a copy of one of these modules and trying to trigger the problem on the copy?

Yes, I’ve thought of that. Haven’t done it yet, but I’ve thought of it.