Note that this PR currently contains the changes of #21700. I recommend #21700 be merged first separately, and I will then rebase.

Note that this PR currently contains the changes of #21700. I recommend #21700 be merged first separately, and I will then rebase.

Our convention is to add a "Depends on #21700" to the PR description to signal that. And then there is a label that someone with permissions can add.

In snowy maps we generate way too much snow. It's usually used quite sparingly.

I should be able to adjust that using MultiBrush weights.

I think all the details are too sparce.

Fixing this starts getting into another set of non-trivial code changes, but the extra details could equally benefit RA maps. As such, it might be better to do the detail adding in a separate PR. (I'd propose a later PR, because then you can then at least test CnC skirmishes.)

Some ideas:

• Rivers have a complete set of templates to work with, so they might not be too problematic. I could potentially use rivers in place of beaches for the otherwise waterless tilesets (or maybe also additionally for DESERT). I could filter out loops if moats-like rivers look a bit weird. Bridging over them is a non-trivial change, though.
• Another option is to add rivers in a similar way to cliffs, though I'd have to introduce tiling errors and cover them up with trees. (Though, this is a common map-making technique for CnC's tileset limitations.)
• I could add civilian buildings and civilians, perhaps biased around roads or their "junctions". Maybe using MultiBrush.
• I could try making road laying more aggressive. The path tiling algorithm is probably more capable of road laying than it was when I initially started, so I can probably tweak a few settings.

On temparate tileset generation can become very slow, something is getting bottlenecked?

Can you quantify this? (Map size?, Generator settings?, Time taken?)

I'm aware of a O(actor_count**2) slowdown after generation when it's copying actors over to the map, which can be very significant for large tree-dense maps. EditorActorLayer.NextActorName() being the relevant bottleneck.

Beach errors are quite common.

I can probably tweak some things to relax the tiling constraints here or stricten the inputs to tiling.

You can also crash the game by choosing bounds in water

I don't know what that means. Can you share with me repro steps, logs, screenshots/video perhaps?

You can also crash the game by choosing bounds in water

Wait, I'm being dumb I know what you mean!

On temparate tileset generation can become very slow, something is getting bottlenecked?

EditorActorLayer.NextActorName() being the relevant bottleneck.

Having done some recent profiling, I'm not sure if this is likely to be the bottleneck in your case. I think it only applies to very very large maps. However, EditorActorLayer.Add and EditorActorLayer.Remove are, in general, quite slow.

Here is some left-heavy profiling of a few generations of 128x128 Rocky and Overgrown maps. Note that the repeated generation during the same editor instance consumes significant time to remove actors as well as adding them.

Zoomed in on the blitting:

• The editor blitting outweighs the actual map generation.
• EditorActorLayer.UpdateNeighbours is expensive.

My understanding is that these costs are editor-specific and won't apply to any maps generated directly via some skirmish UI, so might be somewhat unimportant in future.

Beach errors are quite common.

Turns out there was a bug I introduced during one of my many refactors! I have created a PR for the fix: #21704

the current generator adds roads very sparingly

#21705 should fix that.

changelog