Mod "Ferraris Map" for JTS Nap

[-72-]

Fwiw: I noticed that your field hexes are 63 px in height, but almost all of your other full hex features on your 2D Features file are 61 px ... was looking at the 200 size (although I think I found one that was 60 px).

100 size is 32 px and 30 px respectively.

50 size is 16 px and 14 px respectively as well.

The files themselves double in size from 50 to 100 to 200 - so in theory, the maths with the individual graphics should also be made to double - otherwise, in effect you are allowing the program to calculate the rounding however it wants to -and it doesn't always do it correctly.

However, it really does seem like it probably is not a drawing layers thing, but rather the system not being able to handle with different sizes being used ... sounds more like size and alignment (just based on working with that type of file for these products).

The difference in size is mainly due to my attempts to fix the problem. I have increased the size of the tile, changed the alignment several times and still the program ignores the changes and continues to show a strip of the base terrain.

Fair being fair, I don't think this is not a genuine 'bug'; as described it was sounding like it was about the order of layers something was being drawn, but if that were the case it would be happening with the other terrain being shown on that file (swamps, marshes, woods, orchards, etc...) and there wasn't any mention of that.

As you say, it is not a problem of the order in which the layers are drawn. The different terrains are drawn in different order, for example, the field layer is drawn first, then the relief, collected in a different file, and above it the forest and the orchard. The problem is that it is a part of the base terrain tile that is mounted on top of the field tile, how it looks in the posted image, which leads me to think of a bug in the program.

As a practical solution, I have modified the field tiles so that this failure is not appreciated.

I just edited the link from the first post to add the corrected file.

I don't know - I need to load up your file into a title with full water hexes, but I suspect that since no one commented on that being a problem that there is no border issue with that - then that is probably the true hex dimension.  In this case 'hex' only enters into things as your style is using graphics to cover the entire hex (that's the main reason for hex dimensions being relevant).

Ok - now if that is the case --- on Features50 - your water hex is a different height from your fields.

If the water hex is the true dimension - and that is 15 px high ... then on Features100 - a true dimension is 30px, and in Features200 then it is 60px.

Right now - that isn't the case - so in effect, I am 99.99% certain that is what is causing that. And by extension it would have to be alignment (And not using the actual size of the hex).  There is no way that is a bug in the program unless you are showing all constant sized hexes.

What I'd do to test alignment is grab a row of hex graphics that are not causing an overlap (like your water if it isn't_ 0 change the colour to something solid- and add a different colour border to the top and bottom most row of the graphic... then overlay that onto any causing a problem ... keep it as a layer - as it might take a few rounds of nudge, save, test ... and then once that is established (showing without overlap) -that then is the defined amount of space that a field graphic can use and cover that space. Just my two cents, and how I would nail it using Fireworks... I have run into similar issues before (I think probably when using some cobblestone effects in 3d work... same thing though, the idea was to have it fit in the space of a hex (and I had to get it into hex shape first ... same basic idea - only for 2D.