Reasoning: no reason to hard-code Heightmap.Type in ground finder to WORLD_SURFACE or WORLD_SURFACE_WG. For example, generating trees on terralith's skylands biomes requires "OCEAN_FLOOR", but this is not the only application - what if someone wants to generate trees on the ocean floor?
1) adds an entry in BiomePopulatorsResourceLoader and BiomeDatabase for a string "heightmap" to be used in apply section of default.json (defaults to "WORLD_SURFACE_WG", consistent with current behavior)
2) edits findGround in interface GroundFinder to have an additional parameter "Heightmap.Types heightmap"
3) updates the groundfinders (overworld, subterranean) to include this parameter in their calls
4) updates the classes that call findGround to include this parameter in their calls (luckily, Heightmap.Types has a function .valueOf() which takes the string and returns the corresponding Heightmap.Types or null if no match (so can easily call with null if not using)
…json
Reasoning: no reason to hard-code Heightmap.Type in ground finder to WORLD_SURFACE or WORLD_SURFACE_WG. For example, generating trees on terralith's skylands biomes requires "OCEAN_FLOOR", but this is not the only application - what if someone wants to generate trees on the ocean floor?
1) adds an entry in BiomePopulatorsResourceLoader and BiomeDatabase for a string "heightmap" to be used in apply section of default.json (defaults to "WORLD_SURFACE_WG", consistent with current behavior) 2) edits findGround in interface GroundFinder to have an additional parameter "Heightmap.Types heightmap" 3) updates the groundfinders (overworld, subterranean) to include this parameter in their calls 4) updates the classes that call findGround to include this parameter in their calls (luckily, Heightmap.Types has a function .valueOf() which takes the string and returns the corresponding Heightmap.Types or null if no match (so can easily call with null if not using)