Not for lines. Polygons gets a hollow middle whenever the line width is greater than 0, but lines will be solid all the way, unless you use the "hollow" fill style (You're not, since your rivers are using a bitmap fill) OR you have an Edge, fade inner effect on the rivers, where the inner opacity is set to be lower than the outer one.

Looking at your drawing, you do have an edge fade inner which is way wider than your rivers which is also the partial cause of your rivers being very difficult to see. I didn't notice that immediately when I looked at the map earlier because I worked with effects off to see it without the glow. You can try changing the width of this effect to something like 0.2 and see if that works for you.

That's generally a good approach. The most important for people reading your story is to identify the places they read about on the map. Then you can expand on it later with more names if you write more stories set in that location.

Try this workaround:

Also note that both CONTOURSM and TRACED are commands that does this automatically, none of them require tracing by hand. You probably do want to use TRACED (after applying the fix from above)

Thanks @Wyvern . It is now in the atlas.

The error stems from that map not having a background color.

This might immediately sound a bit weird, but in CC3+, a bacground color is associated with an actual entity on the BACKGROUND layer, while the color you see in the map isn't the background color, but the view window color. One way you can see a difference between the two is that a background color is only behind your map, while if there is a different view-window color, you'll see it behind the symbols in the symbol catalog window as well.

In short, you don't want to use the Change Background color on that map. You'll want to use change properties to change the color of the coastline, and View -> View-Window Color to change that dark "background" color.

Last's years annual may be of interest as a starting point. It contained two issues dedicated to graveyards and crypts.

This is a dungeon style though, but if you are going to a zoom level where you can actually see such details, you kind of end up there. For larger scales, city, and especially overland, such details tend to disappear.

As far as I know, there aren't any necropolis styles for overland or city, but perhaps some of the darker styles may be appropriate to provide the right mood, like Darklands and Darklands City.

I prefer Maptools myself, but I have a weird setup as we do our gaming face to face, but uses Maptools for a digital battle mat instead of physical miniatures, but everything else (rules, dice rolls) are handled the traditional way.

Personally, I do enjoy the fact that it is NOT an online application, so we can run everything locally. No subscription fees, no limits to map sizes, full control. Bit more work to get started than just going to a webpage obviously, but for my use, it is great.

I run the server (in player mode) on the machine connected to the projector so it only displays what the players see (I use combined vision from all the player tokens, no individual view) and then run a client on my laptop in GM mode to control it. Players can connect to the server if they want to, or just use laser pointer to point on the screen to tell me to move their token. This is a great setup since I can update things secretly using the GM client (like adding enemies, or even add a completely new map) without any disruption to the player view while I work.

Talking a bit with Joe here, it turns out that the problem is with the api from travellermap that we use with the importer.

If you look at the metadata for your sector, you see that travellermap simply do not give us a color for the sectors at all:

# Other
#
border 0107 0207 0307 0406 0506 0605 0606 0507 0407 0308 0208 0109 0108 0107

# Other
#
border 1821 1921 1920 1919 2019 2119 2219 2319 2418 2419 2420 2521 2522 2421 2322 2222 2123 2122 2021 1922 1821

# Other
#
border 1201 1302 1401 1501 1601 1701 1601 1502 1402 1303 1203 1202 1201

Normally, the color should be last on the the line for every border entry, and this is where the importer finds the color to use. And without travellermap providing us with a color, CC3+ defaults to white.

Here's an example of another sector which do provide colors correctly, notice the color names at the end of the border statements, after the coordinates:

# Plavian League
#
label 1814 Plavian League
border 1412 1512 1612 1712 1811 1911 2010 2011 2012 2113 2013 2014 2015 2016 2017 1918 1818 1718 1617 1616 1615 1614 1514 1413 1412 hotpink

# Renkard Union
#
label 3033 Renkard Union
border 3029 3129 3128 3227 3226 3227 3328 3329 3330 3331 3332 3333 3334 3335 3235 3135 3034 3033 3032 3031 3030 3029 red

# Swanfei Free Worlds
#
label 2721 Swanfei Free Worlds
border 2520 2619 2618 2718 2817 2918 2919 2920 2921 2821 2722 2621 2521 2520 white

I have no idea why travellermap doesn't give us the color for your sector, as there are clearly colors on the visible map.

Each sector is a polygon though, so it shouldn't be too time consuming to just change colors in CC3+ after the import.

Have you considered using a different style of roads? Those dashed lines works on overland maps because they're only representative of the feature, but on close-up maps like these, they come out looking a bit out of place. Maybe a dirt brown fill with a small edge fade instead?

When you say "hide all your layers...", do you actually mean layers, or are you talking about the sheets?

Also, hiding the map border (The map border is on the MAP BORDER layer, and the BACKGROUND sheet) can in some cases have unforeseen consequences, because CC3+ uses the map border to calculate the extent of the export. I have seen cases where that resulted in a temporary image ImageMagick couldn't convert in the final step, so please try as roflo1 suggested and do a rectangular section export instead, and see if that gives different results.