Does it look like this inside CC3+, or only on the exported image.

If the latter, try this

I also noticed that there doesn't seem to be a light source located in the torch in question, while the torch north for it, as well as the one on the south wall both have 2 light sources in each. (Use Dungeon - Lights -> Show light symbols to visually see their location)

Finally got these atlasified. Thanks for the contribution @JimP

Are all the folders in the proper locations? Those blank entries in the latest screenshot of yours is typical indication of symbol catalogs not being where they are supposed to be. Basically, the config in CC3 says that a catalog should exist, but the actual catalog file is not found.

For example, that top catalog file in the screenshot is expected to be found at

@Symbols\Medieval Symbols\Artisan Buildings Wooden Shingle.FSC

(Remember that @ represents the location of your CC3+ data directory, so with a default CC3+ install, this would be c:\ProgramData\ProFantasy\CC3Plus\Symbols\Medieval Symbols\Artisan Buildings Wooden Shingle.FSC)

If there are any differences at all here (such as an extra folder in the middle or that path, or a missing folder) it indicates that things are not where they are supposed to be, and something has gone wrong at some point.

@ is the standard CC3+ reference to the CC3+ data directory, the default location unless you changed it during installation is c:\ProgramData\ProFantasy\CC3Plus

System is a folder within the data directory.

Just changing the number on the top doesn't work unfortunately, as the code that created the import explicitly sets a color for every border, and it uses 15 if it gets (what it considers) an invalid color from travellermap.

What you need to change are the color values:

#COLORS
#======
color names = red:2|blue:9|olivedrab:12|orange:8|yellow:4|purple:7|green:13|lightgreen:1|lightblue:9|pink:187|brown:11|cyan:5|hotpink:6|lime:118|darkred:165|darkkhaki:130|gray:14|slategray:67|darkslategray:66|white:15|indigo:58

This section is also what makes Darian and Sword Worlds the same color. Travellermap sends color blue for one of them and lightblue for the other, and if you look at the config, those are both set to be color 9.

You can also get it to use those html colors just by inserting them into the list, like I did here, this should cause the white sections on Spineward Marches to come out as yellow:

color names = red:2|#e32736:135|blue:9|olivedrab:12|orange:8|yellow:4|purple:7|green:13|lightgreen:1|lightblue:9|pink:187|brown:11|cyan:5|hotpink:6|lime:118|darkred:165|darkkhaki:130|gray:14|slategray:67|darkslategray:66|white:15|indigo:58

The way we handle these colors was written before travellermap started putting those html color codes in there, so I am afraid this is a manual process for now to identify and insert appropriate replacement, the importer would need an update to be able to parse those automatically. Personally, I would probably just do some quick manual color changes on those entities after loading the map. While having everything correct out of the gate is obviously preferable, the main work is in drawing the sectors after all.

Also note one thing about the import dialog. It caches the setting sin memory when you load the file, so if you make tweaks to the config file with CC3+ open and want to test the new settings, you need to click the change export settings button and browse for the file again, even if the dialog indicates it is already the right file.

Yes. I just looked at the api data to see what travellermap actually sent.

This entity is the color palette the drawing is using. A custom color palette is one of the hidden entities that are possible in a map. You could detach it from the drawing presets dialog, but this will have your map revert to using the default palette.

Resolution of 5000x5000 with an antialias of 75 is not going to work for most people. That high of an antialiasing setting is generating a work image of over 11000x11000. Pushing it that high can work if the stars are aligned just right, but is not recommended.

For the sake of testing the script, try something more reasonable, such as a resolution of 2500x2500 and antialias of 20%. You can try to increase it when you know things work at that level.

When I test the scripts, I usually just set the res to 1000x1000 without antialias. The final result won't be great, but it runs through things that much faster.

Yea. The tools are only a quick way top draw polygons using the fill, but they are just the same as regular polygons and affected by changes in the fill setting the same way.

Note that by turning OFF scaling, it means CC3+ won't keep a consistent scale between zoom levels, and screen and export. With scaling off, what looks nice on screen may not look as nice on export.

I did some testing here, and I found I can replicate the issue. It is a problem that happens when you run CC3+ on top of an arm-based version of Windows (Which you do, since your new Mac is using one of the new M-chips, which are arm-chips).

Technically, CC3+ cannot run on arm-based computers at all, but Windows (and Macs) comes with a translation layer that allows the software to run, even if it was made for a different processor architecture.

However, there seem to be some kind of glitch that occur in certain situations (those particular symbols for example) that probably is due to this translation layer.

In other words, yes, it is probably something with your setup that causes this, but it is not the CC3+ installation itself that is the problem, and probably nothing you can do about this right now. This is unlikely to be some quick fix.