In addition to what Joe said, also note that your line width (LWIDTH) is set to greater than zero. Drawing tools from DRAWTOOLSP handles all that by themselves, but if you want to draw a filled poly and not just a hollow outline using the basic tools like SPOLY2, you need to manually set it to 0 first.

If you don't see any options at all for map type in the new map wizard, then either CC3+ can't find it's data directory at all, or somehow the template sub-directory have been wiped out.

For the latter, just look into your CC3+ data directory and look for a Templates directory at the root of it, with subdirectories for each map type. If the templates directory is actually missing or empty, there isn't any approach but reinstall since you would be missing important files

As for CC3+ potentially not finding the data directory, that will also be accompanied with things like CC3+ having no menu bars and complaining about an invalid license, so it doesn't sound like this is the case based on your description.

I did try a test install+uninstall of SS5, but I couldn't find any problems with the installer. SS5 works after installing it, and uninstalling it doesn't break my installation, so I can't say exactly what might have happened for you unfortunately.

I would like to note one thing though, you say you don't use the documents directory to avoid filling up Onedrive with CC3+ files. But CC3+ doesn't use the documents directory by default anyway, the default installation location for the CC3+ data directory is c:\ProgramData\ProFantasy\CC3Plus which is not related to your documents directory. The only things CC3+ and addons will offer to install into the documents directory is a separate stand-alone copy of the artwork for use with other software (The "install a separate artwork folder" checkbox), this is NOT intended to be installed into your CC3+ data directory as these files are NOT for use with CC3+.

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.

Links spread everywhere, including in search engines. It is usually better to set up some server-side redirect to either redirect people to the new location for the exact page they were looking for, or if that isn't available due to reorganization, at least the correct section.

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.