The exact issue here is basically one of calculation when things get small. At the scale those maps above are exported, there isn't enough pixels in your map to make those "cover walls" in your map a full pixel wide. Unfortunately, pixels cannot be partial things, they either contain one color or another, they cannot be split, as they are the smallest unit in an image. So, when that happens, the rasterization process needs to decide, that line is less than a pixel, should I round it up to 1 or down to 0? One might thing rounding it up to 1 is the good thing since you do want them visible, but for every time you do that, you steal pixels from something else in the map. So when something is less than a pixel, it will sometimes be 1 pixel, sometimes 0. So in short, some of those cover walls just disappears because there isn't room to show them.

But where really makes your problem here is that outline of the shaded area of yours is outlined in a 0-width line. Those lines are special in that they are always drawn as thin as possible, but they are always visible. So they are always one pixel no matter the zoom level. So when that wall hiding line disappears because it is too small... Well, that outline below it won't, because it is always that small.

So, how to deal with this?

One way is to simply export the image much larger and then reduce it afterwards. As long as the covering lines had enough space on the export to appear all of them, they won't magically disappear when you resize the image afterwards, it is just a case of making sure they are given room during rendering. This can be done by exporting a higher version and resizing in an image editor, or you should be able to do the same by setting the expected size in CC3+ and use a really high anti-aliasing value (probably need 100% if you really want your results as small as in this post) as this will export a much larger image and then scale it down to compute AA.

You can also try covering them up with other 0-width lines instead of wider lines. I am fairly certain that would work fine. As long as things are placed using snaps, you can easily place another 0-width line exactly on top of it. And that zero-width line should have the same behaviour as the line below and allways show, and allways be exactly large enough.

Let us have a look what hides beneath the surface of our neighbor, shall we?

As always, you can see the time in your timezone in the left sidebar. You can visit the stream over at YouTube if you wish to participate in the chat.

In this session, I'll play with trains. We'll lock at creating the track, as well as create a nice railroad car suitable for a battlemap.

As usual, you can find the time in your local timezone in the left sidebar. Visit the stream over at YouTube to join in on the chat.

Both of those are normal, if not immediately intuitive behavior.

For the top one, notice those three are not symbols, they are drawing tools. Now, drawing tools only work properly in a map of the style they were designed for, and you seem to have a Mike Schley symbol catalog open, but your map is a CC3 Standard Overland. Since the appropriate fill styles (Mike Schley in this case) , the tools default to showing the currently selected FS instead of their configured one, since it can't display something that doesn't exist. If you want to use those tools in that map style, you must first import the appropriate fill styles.

The second is down to how CC3+ identifies symbols in a map. Basically, it uses the name as a unique identifier, and if you place a symbol that already exists in a map, it will use the existing symbol. In this case, a compass rose with that name already exists in the map, so it uses the current one instead of the one from the symbol catalog (This is again down to using the wrong symbol style for the style of your map). You can fix this by either deleting the old compass rose from the map first using symbol manager to remove the definition, or you can rename it, also in the symbol manager, and then the names won't conflict, and attempting to insert the new one will work. Of course, this is only needed for symbols where the names collide.

Of course, considering your map isn't a Mike Schley one, my guess is that you just opened up the wrong catalog? You'll probably be wanting to use those that match the style of your map.

To start with the basics, you're probably not wanting to use the Symbol fill at all. It is a very ancient way of filling with symbols, and only gives a very regular pattern. You're probably want to use Draw -> Symbols in Area instead.

Not sure about the crashing, but I am able to reproduce it, so I'll bring it to the attention of the developer. But this fill type is likely to go away in the future, so a fix is likely to be lower priority.