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.

Unfortunately no, this command only allows up to 10.

The alternative would be the Symbols in Area command. It doesn't pack symbols tightly the same way, but by experimenting with the random arrangement you may be able to get close. While that command only lets you choose a single symbol, it has the advantage that you can ask it to use all the symbols in the same symbol group as the one you picked, technically allowing for using as many symbols as you want. There is a blog article dealing with setting up a custom symbol group just for this purpose.

I am not sure how images would work. The lines for the original lines are just plain simple lines. The easiest way to deal with them is to open up the symbol catalog for editing (@Symbols\Cosmographer\basesym.FSC), the from symbol manager, clone the symbols, and finally, go in and edit the two clones, using change properties on the lines to change their width. You can then save the symbol catalog with both your new modified copies and the original in them, and you should be able to easily pick from the starmap options which of the two to use.

(I normally don't recommend overwriting the original symbol catalog, but for this case, it may be the simplest, providing you do clone the symbols and don't change the originals. But if you prefer to be safe, either save your modifications under a new name, or make a backup of the original first.)

If you know the name of the fill to change to, the quickest is to use the CHANGEFS command. Type in the command (followed by enter), pick the poly when CC3+ asks for selection, hit D for Do it, and when it asks for the new fill, type in solid white 20 and hit enter. Changing it via the command line do require that you spell the new fill 100% correct though.

Of course, you can also use the more common GUI dialog through :CC2MCHANGE:. If you wish the correct fill style to be pre-filled in this dialog, first use the KEEP (:CC2KEEP:) command on another entity that has the correct fill, and when you then use change properties on the entity you want to change, the fill style you extracted from the other entity is already pre-filled, all you have to do is to check the check box in front to apply it.

You cannot use the commands like that. SELBYP doesn't return entities that can be stored in a variable, all it does is change the selection mode to be by prior instead of the normal selection procedure. Also note that GE doesn't actually store an entity, it stores a set of coordinates where the entity is located, that can be used to grab the entity but it doesn't store the entity itself.

Likewise, RANDOM doesn't have a return value. The command is used very similar to the GV and similar command, i.e. RANDOM varname will cause a random number between 0 and 1 to be stored in varname. You can then manipulate this further.

The SHADEPOLY command also need a second argument for the pitch.

Also be careful with those semi-colons. Commands in CC3+ are executed by using either a new line OR a semicolon. Using both means you are basically creating an empty line, and in CC3+ that means repeat the previous command.

You can find the correct syntax of all the commands in the table in the tome, or in the spreadsheet in @documentation\tome\commands.xlsx