On subworlds and the features.yaml file...

[The Plum Gate]

Currently the features.yaml file is a strange instance of circular dependency when biome features otherwise specify their makeup internally in their current state. I have taken note that this method is somewhat future proof for features which have yet to be implemented and also provides a failsafe when unknown cells may remain present during world generation. Or whatever the case may be for using it.

After modding world gen I may have found a more direct method of controlling features themselves, as well as a tie-in with the central features, including controlling feature-internal mob spawning - the idea is inheritance and granularity on sub-biome features rather than sub-world global features ( in combination would be possible the same way that duplicate feature entries are already used ).

Here is an original, but simplified version of existing subworld YAML code at the heart of the suggestion for others reading along:

names: [name]
zone:
# ...
  centralFeature:
    type: [path]/[filename] # no yaml extension needed
    #(ex: type: features/jungle/SmallRoom )
  features:
    type: [path]/[filename] # no yaml extension needed
    #(ex: type: features/jungle/SmallRoom )
  biomes:
    - name: [path]/[filename]/[header] # inner file header_id reference(Wet, Dry, Humid, etc)]
      #(ex: biomes/Jungle/Toxic)
      weight: [number] # (- strength relative to other biome entries)
      tags:
        - [mob_id]
    - name: [path]/[filename]/[header] # inner file header_id reference(Wet, Dry, Humid, etc)]
      weight: [number] # (- strength relative to other biome entries)
      tags:
        - [mob_id] # creatures or spawnable objects from mobs.yaml
  #...

Here is an example using inheritance - simply a matter of moving where a feature is called from. There are comments in the code itself explaining the rationale for the idea. But the general idea is that a features.yaml lookup would not be needed if the feature inherits the biome terrain data it's already being called from. Please note that this is not currently the case nor how it works.

names: [name]
zone:
# ... 
biomes:
    - name: [path]/[filename]/[header] # inner file header_id reference(Wet, Dry, Humid, etc)]
      #(ex: biomes/Jungle/Toxic)
      weight: [number] # (- strength relative to other biome entries)
      features:
        type: [path]/[filename]
        # impled tags:
          - frequency: [number]
          - [other tags]
        type: [path]/[filename]
        # since most, if not all, current features specify their internal structure and make up,
        # refenceing them here would rememdy any need for referencing features.yaml as a defualt -
        # the feature inherits the sub biome from which it was called into existance.
        # implied tags:
          - frequency: [number]
          # [ 0, null, or not set ] would imply random distribution.
          # [ 1 would imply a single instance, and replace the centralFeature instance ]
          # [ greater than 1 would enumerate the features of this particular type per sub biome instance ]
          # this would also allow more granularity on the frequency of feature-internal spawning while...
          - [other tags]
      tags: # ...global spawns for the sub biome are controlled here.
        - [mob_id]
      # this would also allow more than one central feature per subworld. Or multiple single instances of features.
      # therefore there could be both primary and generic features for each subworld - this allows distinct placement within sub biomes.
 # ...
        - name: [path]/[filename]/[header] # inner file header_id reference(Wet, Dry, Humid, etc)]
      weight: [number] # (- strength relative to other biome entries)
      features:
        type: [path]/[filename] # ex:
        type: [path]/[filename] # ex:
          - frequency: 1
        type: [path]/[filename] # ex:
          - frequency: 3
          - SpawnOnce
          # This feature only appear three times in the world, and only in this sub biome of this subworld.
      tags:
        - [mob_id] # creatures or spawnable objects from mobs.yaml
  #...

I added "tags:" to features such that the central feature could be wrapped into the same type of feature instantiation and thus not be at issue - this would allow fine tuned spawning of features and thus internal spawns would be easier to predict. [other tags] on features could simply be activated inside the features files themselves, or switches could be thrown such that they act like a point of interest. For example -SpawnOnce, where a single instance of the feature exists in the whole of the world generated - a rare feature which isn't a template/point of interest and thus retains elements of randomness.

[The Plum Gate]

Bumping for the sake of mentioning that the geyser feature that creates random geysers uses a single template - I'm hoping that we could specify this template in temperature relevant manner.

Ie, template inherits biome temperature would fall into the idea above.