I need to access my configuration inside my IConditionSerializer. My current solution is very ugly, as it relies on reflection. How would I do this correctly?

Current code:

@Mod.EventBusSubscriber(
        modid = "hadron",
        bus = Mod.EventBusSubscriber.Bus.MOD
)
public class HadronConfigConditionFactory implements IConditionSerializer {
    @Override
    public BooleanSupplier parse(JsonObject json) {
        String setting = JSONUtils.getString(json, "config", null);
        if (setting != null) {
            return new BooleanSupplier() {
                @Override
                public boolean getAsBoolean() {
                    try {
                        Field f = ForgeConfigSpec.class.getDeclaredField("childConfig");
                        f.setAccessible(true);
                        Config config = (Config) f.get(HadronConfigHolder.config);
                        return config.getOrElse(setting, true);
                    } catch(Exception e) {
                        return true;
                    }
                }
            };
        } else {
            return () -> true;
        }
    }

    @SubscribeEvent
    public static void setup(FMLCommonSetupEvent e) {
        CraftingHelper.register(new ResourceLocation("hadron", "config"), new HadronConfigConditionFactory());
    }
}

1 hour ago, F43nd1r said:

How would I do this correctly?

Store your configuration when you create it in your setup method in a static field.

I have my configuration, it is

HadronConfigHolder.config

The problem is I need to access a value by name, which usually is done by ConfigValue. But I don't have those in a IConditionSerializer, because it reads from json.

ForgeConfigSpec implements UnmodifiableConfig, have you tried calling UnmodifiableConfig#getOrElse on your ForgeConfigSpec instance?

 

Note that if you've followed Forge's example and made your ForgeConfigSpec fields private, you'll need to create a public method in your config class that calls UnmodifiableConfig#get(String) on the appropriate ForgeConfigSpec instance.

Edited August 2, 20196 yr by Choonster

16 minutes ago, Choonster said:

ForgeConfigSpec implements UnmodifiableConfig, have you tried calling UnmodifiableConfig#getOrElse on your ForgeConfigSpec instance?

I've tried that. Problem is, that calls to

ForgeConfigSpec.config

, while the real values are in

ForgeConficSpec.childConfig

. Hence the dirty workaround to access childConfig.

Edited August 2, 20196 yr by F43nd1r

why have this a config condition? If they are changing the config then they can change the loot table

3 minutes ago, LexManos said:

why have this a config condition? If they are changing the config then they can change the loot table

Here is an example using this condition: magma_bricks.json

{
    "result":{"item":"hadron:magma_bricks","count":4},
    "conditions":[{"config":"Building.MagmaBricks","type":"hadron:config"}],
    "ingredients":[
        {"item":"minecraft:stone_bricks"},
        {"item":"minecraft:stone_bricks"},
        {"item":"minecraft:magma_block"},
        {"item":"minecraft:magma_block"}],
    "type":"minecraft:crafting_shapeless"
}

I'm not aware of any solutions outside of conditions to disable multiple recipes based on settings. Aren't loot tables for item drops?

Then they can change the recipes.

The issue is dependant recipes is advancements and other things.

You're just moving the config from one file to another.

I can see your usecasse, but it has downsides of just missing recipes.

6 hours ago, LexManos said:

Then they can change the recipes.

The issue is dependant recipes is advancements and other things.

You're just moving the config from one file to another.

I can see your usecasse, but it has downsides of just missing recipes.

Lets assume a mod like quark, which is registering lots of blocks. IMO such a mod should provide a userfriendly way to enable/disable groups of these blocks. Overwriting all recipes of blocks in this group is not user friendly, because a group can have like 50 recipes (Do you disagree?). This also doesn't consider creative tabs.

My current solution registers all blocks (according to you "always register everything"), and then disables recipes of disabled blocks and removes them from creative tabs based on a configuration file. Would you say this approach is valid? Is there a better approach?

@LexManos if you can see the usecase, but my solution has downsides, maybe we could build a new solution in forge without these downsides?