[2.0.42]Possible oversight in noise definitions?

[Schmendrick]

Not a bug so much as a possible oversight, and so not really consistent with the preferred "What did you do / what happened" template.

The noise expression resource_autoplace_all_patches uses spot_favorability_expression in its spot noise for starting resources, I assume to avoid having the player get their starting resources drowned in the starting lake. But it uses elevation_lakes to do this, not elevation, making it inconsistent with any other elevation setting (such as vanilla Islands).

I would expect (and assume the intent was) for it to simply use the elevation property, so its behavior remains consistent regardless of the expression being used for that.

[Genhis]

Thanks for the report. We wanted to keep old resource generation in the starting area because it makes resources more spread out, so I used the lakes elevation. I think it's fine to keep it as-is. If you are making a mod and this causes issues, I can consider making adjustments.

[Schmendrick]

I started moving some map generation stuff from 1.x to 2.0, and some of it can be kind of extreme with water in areas, so it had a setting to "concentrate" resources and/or enemy bases on land to try to mitigate the effect on resources (or bases). The setting just added an elevation based expression in spot_favoribility_expression for all the relevant spot noise(s). I only noticed vanilla was now doing this (for starting spots at least) when I started looking into migrating this. Since I still intend on keeping this overwrite as a mod setting it doesn't affect me immediately, it's just something I noticed that seemed like a "not as intended" inconsistency.

Even absent crazy terrain shenanigans, if somebody creates a new resource to appear on a new planet using the provided resource_autoplace_settings and sets has_starting_area_placement to true (instead of a custom or copied expression), noise will try to secure starting resources based on elevation_lakes regardless of what the planet is using, which sort of defeats the purpose. Just using elevation instead should solve this without affecting normal Nauvis behavior at all, unless I'm misunderstanding something about name collision priority.