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.

No, opening and saving doesn't matter. CC3+ doesn't care if you work on a map with a font that currently isn't installed. The text entity will still remember what font it was defined with originally (or changed to if you use change properties on the entity, obviously). But the visual replacement font is just a visual thing when it can't find the font, and it will display the text using Arial instead of the actual font.

Are you sure that that Calligraphic font isn't what you are after? If you don't have it installed, maps will show using Arial, like in my screenshot above, but CC3+ will still list it as the actual font. (Just as in my example above, the text is clearly plain arial, but listed as XXII Arabian-Onenightstand, a font I don't currently have installed, which makes it look very plain indeed until you consider that isn't the font used in the display because I don't have it)

Those "C:\CC2\" missing files are unlikely to be an issue, they're probably just some remnant definitions from old times that still is defined, but not used. I doubt Steven would have those either. Same with those "E:\FCW32" references. Sometimes some of those old references decides to hide out in the list of fill style, but it doesn't matter if nothing in the map actually references them.

If you see a red X in the map, use List on it. If it is a symbol reference, it doesn't matter what fill style it has, as you are dealing with missing art for the symbol itself, which should then be checked by opening up the symbol manager, finding the missing symbol in the list there, and hit the list button to get info on the paths of the symbol artwork files, while on the other hand if it is some kind of filled polygon, then the fill style matters, and you can look up the name in the fill style dialog and check the path.

It works fine for me, so it doesn't seem to be a general problem. But of course, that doesn't help you.

Let's start with the blank preview. Make sure the sample width is set to something sensible. Often it defaults to something so small that it only shows a tiny section of your pattern, which may be a blank area. Since your pattern is 20x20, try something like 100. Not that this is really important, it is just a preview after all, what matters is if it works when you try to use it in the map, which you didn't mention at all if that was a problem or not.

Now, as for the crashing. That dialog can sometimes be a bit fickle when you add/remove styles. My general recommendation is always make everything ready, which in your case includes defining the symbol, then save the map. This gives you a read to use starting point in case of a crash. It is also possible to do the fill definition in steps, i.e. go in first, create a new symbol fill, then immediately close the dialog and save. Then go back in, and change the symbol for your new style to the one you made. This makes it easier to track down exactly what causes the crash if it is repeatable.

If you attach your map here with the symbol to use for the fill already defined I can also try to define it, see if everything works fine for me with your map and symbol, or if there is an issue with either.

I am not familiar with that tool, but looking at it, it doesn't seem to be able to export maps in a format CC3+ can use. Which gives you two options:

• Use their svg export, find an online svg to dwg/dxf converter online, and then import the result from that into CC3+. That preserves the vector maps, but you're probably going to end up with a pretty bare version that needs lots of work before it is back in a state similar to what you have online.
• Use their image export, import the image into CC3+ and trace it. This has two downsides. First of all, tracing is quite a bit of work for a large map like the one created there, and secondly, their image export is a bit limited. If you export it as a single image you're not really get much detail, while the highest scale export is a nice high quality, it still isn't close to getting all the detail you can get by zooming in, and while their tiling function can be used to get a much higher detailed result, dealing with a huge number of tiles that needs to be assembled has it's own challenges.

Not sure why that happens. Use :CC2BREAK: instead, that should allow you to take out a controlled chunk and not have the arc disappear.