CC3+ looks for a hex grid on the HEX/SQUARE GRID layer. Only the grid on that layer will affect the scaling/rotation/snapping of the hex symbols, and if you have more than one grid on that layer, CC3+ will pick one of them (Probably the first it encounters in the internal drawing list)

What you need to do is a little manual manipulation. Make one layer for each of the hex grids, and place the one you actually want snapping to occur for on the HEX/SQUARE grid layer.

If you ever want to place hexes on the other grids, then you need to go do a little layer renaming, renaming the current HEX/SQUARE GRID to something else, and the other layer to HEX/SQUARE GRID.

Thanks, that should work fine.

The reason is that the file you imported isn't a proper CC3+ prepared resource. If you look at the path of the file, "C:\Program Files (x86)\ProFantasy\Symbol Set 4 - Dungeons of Schley\Textures\Inks\Stone Paving.PNG", there are two major indicators here.

First, the file is stored under the "c:\Program Files (x86)\..." folder on your computer. CC3+ only store the files needed for running the program here, art files and more are stored in the data directory which is located in "C:\ProgramData\ProFantasy\CC3Plus", notice the difference there? Nobody else is ever going to have an art file under "c:\Program Files (x86)\...", so any file you might find there would be something unique to your computer, and basically guaranteed not to work on anyone else.

The second part is the file name itself. All art files supplied with CC3+ and it's addons (with the exception of some more special files) are always distributed in four resolutions, meaning that if the base file is "stone", the four art files for it would be stone_VH.png, stone_HI.png, stone_LO.png and stone_VL.png. As you can see from the file name of your fill, "stone Paving.PNG" it does not have any one of these four suffixes, indicating it wasn't prepared for mapping with CC3+.

Now, the question is of course why you ended up with those erroneous files in there in the first place. My theory here is that you have enabled the "Install a separate Artwork folder" option during the installation of SS4, and told the installer to put that into the CC3+ installation directory. Most of our installers contain such an option, to allow users to install a standalone copy of the artwork for use with other software, be it mapping programs or image editors. This allows the use of the artwork even if they don't have CC3+ at all. But, the artwork in this folder is structured quite differently, because the CC3+ organization doesn't make sense for using the art with other programs, and nor does it contain the image files in four resolutions, because that is an optimization only available in CC3+ itself, image editors wouldn't understand that, so it only contain one file per fill and symbol. So this folder is intended ONLY for other programs, and not CC3+ itself (And normally should be installed somewhere else, like in your documents directory or something,, not inside the CC3+ installation directory)

Now, you can of course use files from this artwork folder inside CC3+, but it isn't recommended. Since it doesn't have the four resolution system it will make the map less performant, and as you also discovered here, you will end up with a .fcw that can't be shared, you would run into the same issues if you just tried to copy it over to another computer in your own home as well (Unless you painstakingly manually set up that artwork folder in the same location on each computer). Instead, when manually importing artwork from other add-ons you have installed, you should always make sure to source them from the CC3+ data directory ("c:\ProgramData\ProFantasy\CC3Plus+" by default) since this is where the stuff intended for use within CC3+ lives.

Hope this explanation made sense :)

Now, there's a familiar name. I've never seen her Middle Earth atlas, but I do have her Forgotten Realms atlas on my bookshelf, full of lovely hand-drawn maps.

Contrary to many of you, I had an upbringing where fantasy was simply not on the menu. I don't think my family had anything against it, it was simply not something they had heard about either. It was never a topic among the kids at school either. Tolkien was something I only learned of as an adult, after I learned about role-playing games which happened in my mid-teens. First as computer games (Eye of the Beholder anyone?), then the real deal.

I guess the closest I got to fantasy was the Narnia books, which I guess by one definition clearly fits the genre, but on the other hand doesn't really match up with the common fantasy archetypes, and I don't think there was any maps in any of the books I had.

Part of your problem at least is all those contours.

The Mike Schley style isn't a style that relies on height contours, it uses symbols. So there wouldn't be appropriate fills for those contours which probably leads to all those solid filled areas.

I've attached my Mike Schley export settings to this post. I don't remember if I have modified it or not, but it seems to export an appropriate result for the Schley style anyway. Just unzip the archive and put the file inside in C:\ProgramData\Profantasy\FT35\Export overwriting the one there already

What the dpi tells is the size it will be in a document. For example, if I have a symbol of 1000x1000 pixels set as 100dpi and add it to a document (in a dpi-aware application), it will show up as 10 by 10 inches. If the exact same image was instead set to 250 dpi, it would be added to the document as a 4 by 4 inch image instead. That is the only thing it determines, how large should it be printed. It does not change the quality in any way whatsoever. Think of it as a hint for recommended print size, not a quality thing.

But when used in a program like CC3+ that doesn't operate with print sizing at all (as symbols are scaled to be the correct size you set them in your map, not to the real-world size of the paper), there will be no quality difference. A 1000x1000 image at 10 dpi is of no better quality than a 1000x1000 image at 4800 dpi.

(Of course, that applies to the image side of things, for the hardware side of things, a printer capable of printing 1200 dpi is better quality than one that prints at 300 dpi)