Range Calculation Weird Behavior

I am experiencing some weird results with the Range formula. Works just fine for the 1st map of a series, but goes haywire for any of the maps to the right. See included pics. That small white band is where the maps change. For this example I’ve used what I’ve called the WEURO and EEURO maps. I added a couple of text boxes to the counter on the map. The 1st pic shows which value displayed for each position. Obviously I’ve no idea what is going on here. Is this a bug with the Range calculator or something else?
1stpic
2ndpic
3rdpic
4thpic

However, this behaviour could be due to actions I took. Specifically, modifying the map zones that are actually nested. Previous module versions did not have overlapping zones. But I wanted to have hex numbering and movement reporting capability, that actually meant something, so I changed it all.
Referring to the pic.
The red bar includes all the zones for the various sea box areas. They also include a hex grid.
The yellow bar is for the actual main map board area that has terrain and seas (including the sea box areas). This also includes a hex grid with numbering.
The green bar is for all the terrain and seas (including the sea box areas) that are specified as a particular weather effect type. These zones use the ‘highlight property’ that will superimpose a graphic signifying what the weather is in each zone.
The purple bar is for the zone that covers the whole map, top left corner to the bottom right corner. This prevents error messages for the mouse over stack viewer when used on a counter not actually on the terrain/sea area parts of the whole map.
The blue bar is for when the upper and lower ‘Off Map’ parts are not being used for the game (players use the optional Scandinavian and/or African mini maps). These superimpose a diagonal cross hatch highlight over the off map sections.
Everything seems to work OK, bar, of course, the desired AoE effect. But why does it work properly for the left most main map board, but not any other main map board to the right? From the pics in the original post the OldX, OldY, CurrentX and CurrentY do appear to be giving the correct values for the Range equation to use, but the calculation comes out to 207 not 1.

Just realised something. That value, 207, is equal to CurrentX - OldX. Is the range equation acting like a simple subtraction and ignoring the Y parameters?

1 Like

Hello? A Vassal issue and no reaction? Really!

Can you create a minimal test module which shows the problem?

My priority until it’s finished is converting the module library from old to new. We could use help with that.

1 Like

Joel, I will not commit to making a minimal test module for you to test. That would take a lot of my time - a lot. Please just use the world in flames module as is and go with it from there. WiF CE Maps and Units Combo Ver 1_42.vmod - Google Drive
Just download and add to Vassal. Use freeform and load 2 maps. Place an aircraft on one, activate AoE and move. Anything else refer to the pngs I have already provided.

And yes I would like to help with the conversion project, but I am not sure how I can contribute.

It’s a very complex module. You’re familiar with the module. I’m not. It’s not an efficient use of my time to dig into the module before you’ve tried isolating the problem in a test module.

The first post in the linked thread contains instructions.

2 Likes

Yes it is a complex module. But easily usable.
It is not a lot of time to download a module, add it to your vassal master and run it. Yes a big file, but all you need to do is access the module and then use free form setup for at least 2 maps. I suggest WEURO and EEURO (same scale hex wise). Using the ‘Counters Repository’ ‘air’ tab, any country, select an aircraft. Drag 1 to the maps displayed. Start with the left map. Right click select rebase. Right click select toggle AoE. Click and drag the unit. The AoE should decrease as you move the aircraft. This happens only on the left most board. Any other board the range calculator equation reverts to pixel mode, not hex mode - hence the 207 (px) not 1 hex.
Appreciate that you have many other time consuming stuff to do, but that also applies to me. I would like to resolve this dilemma. Your time to download the module and use it is far less time than it would take me to make a cut down version.
At days end, I’m somewhat disappointed that the pics did not provide sufficient detail that did not entail even loading the module.
Lets see. Move 1 hex map 1, result 1 hex. Move 1 hex map 2, result 207 hex. Last bad, should be 1 hex not 207 px.
While I think that my zone changes contributed to this problem, I do think that the actual problem is within Vassal. Else why does my AoE work on 1 map but not the others.

BTW, you could reduce the size of the module by about 60MB by running a PNG optimizer (such as optipng) over the images contained in it.

I have run an optimiser (several times), albeit a while ago now. The thing is that some images actually get bigger - those that have less than 10 colours. Also, 60MB is miniscule compared to the rest of the module 900+MB, most of which is taken up by the map pngs. I try to keep it as small as possible. Each map is converted from RGB to indexed prior to saving

Apologies Joel.
Yes 60MB is a good gain.
But how did you ascertain that without going through each png?
I’ve found that some pngs get worse, file size - as in the 2 basic colour ones.
Does optipng do this as a matter of course? As in, it leaves those are optimised and only optimises those that can be optimised!
If so then bring it on.

Yes, optipng by default modifies PNGs only when it finds a way to decrease their size.

Cool. Thank you.
Regardless, file size is a side issue.
Still need to address why the range formula reverts to px mode for any other map bar the 1st.

Optipng (used by pnggautlet, but replacing the really old optipng with the latest version) also removes any transparency areas in the images. I use quite a few of those, so looks like I’ll just stick with the excess size.

The version of optipng I currently have (0.7.8) removes the alpha channel only when there are no transparent pixels.

Back to the main question. The Range formula.

Just ran optipng (0.7.8), transparent pixels are now not transparent. Usage was optipng *.png. Folder size went from 596MB (disk 619MB) to 542MB (disk 562MB). Saved 54MB but at the expense of transparency.
PS Not all images with transparencies were affected. Weird.

Would you provide an example of an image where this happens?

Pre and post optipng images just look the same after posting to here. However if I use GIMP to look at both pngs, the transparent areas are still there. Could be that the more simpler graphics software (photofiltre 7) I also use is ‘confused’ with the post optipng file.

Hard to tell when I don’t have the images. Would you upload the original somewhere I can get it?