Refer to the attached pics. Both used the same module but different versions of Vassal. The one with the vertical white line used version 3.7 Beta 4. The other, without the vertical white line, used version 3.6.19. Now, before we go to say that it is an artefact from using a version 3.6.19 module with 3.7 Beta 4, that is not the case. The same line appears in modules that have been ‘ported’ across the 3.7 Beta 4. I’ve just spent several hours reviewing the maps to try and find which one had suddenly grown in width by a few pixels, said growth being white.
So is there a ‘magical’ number for a map size that obviates this anomaly?
Also, why is it so important for piece locations been ‘true’? Is this an X,Y coordinate problem or more plainly a sense of trying to be more correct when what existed worked, albeit not that ‘accurately’ and we are willing to inflict on Vassal users a vertical white band separating their adjoining maps?
Me, I have not seen any problems or issues with piece locations not been true, regardless of their position on a map. In fact, I have absolutely no interest in that most irrelevant piece of data.
Does the game "piece’ still snap to the grid centre? Yes, so who gives a? Does the ‘report opposition/other player moves’ give a bad position report, but still manages to centre on that game piece?
This is finessing to a degree that, to me, seems immaterial and caters only to a perfectionist that the numbers must equate well. To hell with the aesthetics of what Vassal players see on their screens. Then also, this a change that caters for, what, maybe less than 5% of a map! Can reality get a chance here?
The users of Vassal also need to be considered here. What is the effect on them of this discrepancy in piece locations versus a definitive gap between their maps when there was none?
Really, I mean really, think about that.
Yes I vent my spleen at times. Particularly when I do not feel that a change is for the best, for the user. Not all change is good.
The problem occurs when a particular zoom level causes a map image to be zoomed to a non-integer number of pixels. The right-hand and bottom maps are not affected. Theoretically, if your affected map size scales to an integer size at each zoom level, the problem won’t appear. For example, a map that is a power of 2 in pixels will not show the issue at any power of 2 zoom. A map that is a multiple of 200 pixels in size, should be right at 50%, 40%, 20%, 10% and 5%.
For Strategic level games with very large map pieces, probably no one. For tactical level games involving LOS on smaller maps, people do care passionately that things line up.
This is where politely asking whether this change might be implemented with a Global Option to disable it might have been a better approach that turning back into the user from hell. Personally, I’m going back to ignoring all your posts, I just don’t need the aggro in my life.
Appreciate your inputs. I do have a need to know more than just ‘it’s a consequence of this’. The engineer in me admires perfection. But I have learned over time that the pareto principle also applies, particularly wrt to real world outcome versus the theoretical premise.
The WiF maps are 6779 x X. The X depends on what variant maps are being used. But thank you very much Brent, I believe I can work out how to reduce/eliminate this problem. Just need to do the math and then enable only relevant zoom factors. That is what I needed.
How would I know, however, that the change might be implemented with a global option to disable? I’m not a programmer, and would never, ever, have thought of that approach. Does anyone else out there have enough programming nous with Vassal to suggest that approach?
I also just have to ask. I sincerely hope that is not another leading zero fiasco.
One module, in particular the VASL one, which has a lot of extra java coding in its build, is having a problem with the display of counters/game pieces. Do any other Vassal modules have the same issue? I’m talking about 1 module versus the multitude. Yes, you ‘fix’ that 1 module, but adversely affect every other module (100s of them). Think about that one. I have never seen nor experienced the issue described in that link. OK my experience is also, essentially, 1 module orientated.
Input from other module developers, players would seem to be appropriate about now.
I’ve done some what iffing. As you may be aware I have 3 World in Flames Modules. One is with the maps as issued. One is with the maps as issued but with an additional top and bottom add on that caters for the, normally, ‘off map’ maps for Africa and Scandinavia, and one the is a single scale version based on the NASA Blue Marble images. In the same order, map image (png) sizes are 6779x17269, 6779x10039 and 12052x18846 pixels.
I’ve placed a unit/counter/piece at the bottom right hand side of one map from each variant. Using 3.6.19 and 3.7 Beta 4. I ‘took’ a print screen image of this unit for standard zoom (0.3) and min zoom (0.1).
The difference is - what? So this guy has a problem with a Vassal moule, where he uses an insane small zoom level and then complains about the visual image of units being offset from center? Who the hell can actually play a game using that miniscule zoom level? If you want an overall ‘picture’ of the area of interest, simply use the ‘overview window’. I’m fairly sure that players would agree that using those low level zoom factor(s) is not worth their while, except for getting an ‘overall’ strategic and/or tactical view point. Again, reference the overview window.
At days end, I fail to see how one guy, using one module, at an insane low zoom level - where it would be almost impossible to play at and displays something that is, basically indecipherable at that level of zoom, drives a change in Vassal that adversely affects every other Vassal module.
Just another leading zero fiasco. Failure to take cognisance of the ramifications to every other developer and player of Vassal modules.
While you guys are great, you do really need to think about what a change to the code will have on all the other users and module developers. Yes you solve 1 guys issue, but what are the ramifications of that change to everybody else?
If you want to see the screen images, ask and you shall receive. I just felt as there was little if any change they are irrelevant.
