Which installer did you use when installing this? I noticed yesterday night that I had the same issues as you on my main computer where I had only ran the individual issue installers as they arrived, but the complete 2020 installer set up the template properly on both my regular system and my test system when I installed that.

Best way to transfer effects and sheets over is to save the preset from a working map. Load up the @annual\Issue165 Smaple cliff.fcw file, go to the effects dialog, and save the current setup as a preset. Now, in your own map, load the preset. Do notice that new sheets added WILL be added to the bottom of the list, you must rearrange them yourself.

This is a precision error caused by the fact that computer numbers have a limited amount of precision (number of decimals). Lines are defined by their coordinates, and when you rotate things by an arbitrary angle, those coordinates won't be pretty whole integer numbers any more (assuming they started out as such), and they become subject to tiny precision errors because the number have more decimals than the computer can handle.

Length and Bearing are values calculated from the coordinates, so when the coordinates have precision errors, so will these values.

Yes. It's never going to matter on normal-sized map. This is an issue for all computer programs that deals with numbers. It is possible for a program to use higher precision than CC3+ uses when higher precicion is needed, but the current use is plenty good enough for CC3+ use, and was picked with performance in mind.

The issues with the footprints is that every pixel are semi-transparent. The effects system doesn't like that too well. I initially tried to use them in my ice cave live stream as well, but got the same issue when adding effects. I think symbols like these is why DELAYDRAWSYM is enabled by default and you have to explicitly turn it off, because this causes them to be restored after the effects system have "lost" them.

I assume you mean "programdata" here and not "programfiles", as I can clearly see references to c:\programdata in your original screenshots.

You can't split your data directory like that. If you picked d:\ProFantasy as your directory during install, that's fine, but then you'll need to stick to it and keep putting everything there. CC3+ won't recognice the programdata directory in that case (it can only have one data directory), so anything you put there will be guaranteed to make red X'es, because all the templates and symbol catalogs refer to your data directory (which is d:\ProFantasy for you)

It depends.

But TRACED can be an excellent option here. You're probably ending up with a polygon that is easier to edit if using the "old way", since traced will need to place more nodes to approximate that rounding, and because TRACED runs on an image rendered from the entity, there can be artifacts like pixel steps. But you also often end up with a result that looks nicer.

CMB makes things into a single polygon, which cannot contain both smooth and straight elements, it has to be either a straight poly or a smooth one (I don't remember if CMB can work with smooth lines or not at all, but you can in any case convert the poly to smooth after finishing combining it.)

And no, you can't change the number of segments LTP creates unfortunately.

Yea, basically the same as I foun, just about any solid entity will work, but the entity have to be within view, so since exports are done in multiple passes, you won't necessarily need one line per symbol, but there must be one within view for each segment of the export.

One thing I didn't try yet, but which may work is just making that part of the symbol. A symbol can contain entities in addition to the image. Of course, those entities would be part of the symbol and get the same effects.

I've notified the developer, maybe he can give some more insight in exactly what is happening here.

The scale symbols are always made to be placed with scale factor 1.0, because it is important to get those absolutely correct, and using a factor of 1.0 makes the precision perfect.

Most other symbols are designed for an imperial scale, and are then simply scaled down when used in metric maps through the default symbol scale for the map.

Did you add that line of yours near those lights too? When exporting, CC3+ exports the map in sections, and it can't "see" what's outside the current section. I am guessing it is the same strange issue as above, and there isn't a "fix" in the section those lights happen to lie in.