[Solved] Iterate over BiomeTypes?

Plugins Plugin Development
1

Hey all,

How do I iterate over BiomeTypes? The BiomeType.class does not implement a .values() method or similar, so I can’t exactly do a routine like this:

for(BiomeType type : BiomeTypes.method()) {
       \\  do stuff in loop
}

I could just laboriously hard code this into my config setup, but I feel like this is the wrong way about it.

thoughts?

2

Look at this method from the game registry.

3

that would be perfect after a game is loaded… but I’m trying to do this loop while creating my configs. Do you think all these catalog types will be registered by then?

4

Usually they are starting to become available before load, but some mods are not able to register until the proper registration event (you shouldn’t run into that problem).

5

sweet. that was an easy fix.

6

… question. why are you trying to do this loop while creating your configs?

7

So there are world generation populators that are specific to certain biomes that sometimes interfere with the geology things I want to do. I could

  • hard code them to always not be there
  • turn them all off-on with a debug flag in the configs
  • allow populators to be turned off-on by the user for specific biomes

Since its really hard to selectively turn off say, the granite blob populators, this seemed like an alright approach that didn’t completely violate best coding practices.

8

So if you’ve got e.g. a disabled-biomes[] field, and you encode that as a List<BiomeType>, where’s the need for iteration?
Sorry for the questions, but I’m getting XY-problem vibes here.

9

Lemme pull out a concrete use case. Tell me if I can do better:

@Setting
private HashMap<String, Boolean> biomeCoverLayerSettings;

public GeneratorDefaults() { 
    biomeCoverLayerSettings = new HashMap<>();
    for(BiomeType biomeType : biomeTypes) {
			biomeCoverLayerSettings.put(biomeType.getName(), true);
    }
}

public boolean getBiomeCoverLayerSetting(BiomeType type) { 
    return biomeCoverLayerSettings.get(type.getName());
}
10

You can.
First of all I would have made getBiomeCoverLayerSetting return a Tristate and let whatever calls it figure out what to do with Tristate.UNDEFINED, which gets returned if type isn’t in the config. So that eliminates your need to iterate over all biomes.
Second, a useful feature of Configurate that you seem to be missing:

@Setting private HashMap<BiomeType, Boolean> biomeCoverLayerSettings;

And then you have full mod compatibility independent of translated names. Only difference is that it’d be e.g. minecraft:plains instead of Plains.

11

Tristate? que es esto?

Ah… yeesus. I forgot that enums are supported.

12

hmm? No, I don’t mean encode the config as tristate. Keep the Map’s value as Boolean, and then

public Tristate getBiomeCoverLayerSetting(BiomeType type) {
    Boolean bool = biomeCoverLayerSettings.get(type);
    if (bool == null) {
        return Tristate.UNDEFINED;
    } else {
        return Tristate.fromBoolean(bool);
    }
}
13

Ah i see. So one reason for this approach would be if the configs don’t explicitly set the state of a biome, hence bool here would be null. Reduces the verbocity of the configs.

I only meant I forgot you could do

@Setting
private AnArbitraryEnum anEnumState;