Mod "Ferraris Map" for JTS Nap

[Aoi99]

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.

[phoenix]

Cool workaround, Juan Carlos! Thanks.

[Compass Rose]

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

Greatly appreciate your effort for the fix.


Which link on the first page did you update? 1,2 or both?

Thanks

[-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.

[Aoi99]

Which link on the first page did you update? 1,2 or both?

To avoid doubts I have added all the improvements in a single link.

[NicolasBourbaki]

Absolutely gorgeous 2D map ! Thank you !

[phoenix]

Hey Juan Carlos. I'm presently playing 2 PBEM games using your map mod and the immersion difference is outstanding, as is the clarity of what is going on .....mainly....I have one reservation, one suggestion for you to consider, if you would be so very kind!! I have noticed that it's harder to tell what terrain units are occupying, when using the mod. This is because the stock graphics use square counters, leaving room for quite a bit of the underlying hex to be visible, but you have moved to hex counters, which obscure nearly the entire underlying hex. It means there has to be some clicking to find out what exactly the terrain is beneath the counter. I understand the need to make the units visible against the background, and I understand that you have added letter codes to the side of the unit graphic, but I wonder if you would be so very kind as to consider creating an alternative counter set with smaller unit graphics and everything fitted into a square, roughly, so that some more of the terrain would be visible beneath? I realise this might be a lot of work..... Understand if you haven't time, obviously.

Thanks! Peter

[Aoi99]

Added a new version of the mod for Napoleonic games, with correction of several errors, some improvements and, above all, the reduction of the size of the counters in the magnified view so that the terrain is better appreciated and the division colors are better seen. The map with the variation of heights marked different shades of the base color is included in the compressed file.

In the other views, a reduction of the counters is more complicated since it can compromise the good visualization of the same, but I will consider it.

[phoenix]

Looks perfect! Many thanks!

[phoenix]

Juan Carlos. The counters, I notice, have a kind of edging (like a depth effect? - as if they were actual counters?) plus a colour coded bar. Do these both serve the same purpose - to indicate the height of a stack?

I think if there is only 1 unit in a hex then we don't see the edging, no - just the colour coded bar?

I was wondering if you would need both and whether having both was confusing? But you've probably experimented already with various combinations.

Just thinking aloud.

It's fantastic work.