[1.18.2] [SOLVED] Disable crafting recipes from config files

[CrackedScreen]

I'm trying to disable crafting recipes based on config file values. Currently using datagen for crafting recipes, and ICondition seems to have changed compared to the older IConditionFactory.

Edited October 26, 2022 by CrackedScreen
Marked thread as solved.

[ChampionAsh5357]

You would need to make your own condition that checks the value. Note that when the config refreshes, you'll need to refresh the datapacks as well. You can learn how to make a custom condition on the docs.

[CrackedScreen]

Late reply, but tried implementing ICondition and copying some code over from ModLoadedCondition:

Spoiler

public class RecipeCondition implements ICondition {

    private static final ResourceLocation NAME = new ResourceLocation(MusketMod.MOD_ID, "recipe_enabled");
    private final boolean loaded;

    public RecipeCondition(Boolean loaded) {
        this.loaded = loaded;
    }

    public ResourceLocation getID() {
        return NAME;
    }

    @Override
    public boolean test(IContext context) {
        return ICondition.super.test(context);
    }

    @Override
    public boolean test() {
        return false;
    }

    public static class Serializer implements IConditionSerializer<RecipeCondition>
    {
        public static final RecipeCondition.Serializer INSTANCE = new RecipeCondition.Serializer();

        @Override
        public void write(JsonObject json, RecipeCondition value)
        {
            json.addProperty("recipe_enabled", value.loaded);
        }

        @Override
        public RecipeCondition read(JsonObject json)
        {
            return new RecipeCondition(GsonHelper.getAsBoolean(json, "recipe_enabled"));
        }

        @Override
        public ResourceLocation getID()
        {
            return RecipeCondition.NAME;
        }
    }
}

 

Getting an error for including the test() method since it is marked as deprecated, but forge still requires it to be implemented. Using Forge 1.18.2-40.1.51, if I'm missing anything let me know.

EDIT:
The mod will still compile and run fine since this isn't actually an error, but will need to know how to pass existing datagen recipes through the serializer since forge does not come with any functional examples by itself. Would still appreciate an answer on how to get rid of the deprecated method in case I am missing something obvious.

Edited October 17, 2022 by CrackedScreen
Changed post.

[ChampionAsh5357]

8 hours ago, CrackedScreen said:

The mod will still compile and run fine since this isn't actually an error, but will need to know how to pass existing datagen recipes through the serializer since forge does not come with any functional examples by itself.

I give you, a Forge provided functional example: https://github.com/MinecraftForge/MinecraftForge/blob/1.19.x/src/test/java/net/minecraftforge/debug/DataGeneratorTest.java#L165-L204

8 hours ago, CrackedScreen said:

Would still appreciate an answer on how to get rid of the deprecated method in case I am missing something obvious.

Essentially, the method is removed in 1.19 due to the context parameter addition. However, changing how the method is implemented would induce a breaking change. As such, older versions need to have it implemented until they update to the next version.

[CrackedScreen]

Used the following to create the recipe:

Spoiler

ResourceLocation ID = new ResourceLocation(MOD_ID, moddedItem.toString());

ConditionalRecipe.builder().addCondition(
	new RecipeCondition(Config.ENABLED_CRAFTING.get())
).addRecipe(
	ShapedRecipeBuilder.shaped(moddedItem, amount)
		// .define ingredients here
).build(consumer, ID);

 

Condition/Serializer class:

Spoiler

public class RecipeCondition implements ICondition {

    private static final ResourceLocation NAME = new ResourceLocation(MOD_ID, "recipe_enabled");
    private final boolean loaded;

    public RecipeCondition(Boolean loaded) {
        this.loaded = loaded;
    }

    public ResourceLocation getID() {
        return NAME;
    }

    @Override
    public boolean test(IContext context) {
        return loaded;
    }

    @Override
    public boolean test() {
        return false;
    }

    public static class Serializer implements IConditionSerializer<RecipeCondition>
    {
        public static final Serializer INSTANCE = new Serializer();

        @Override
        public void write(JsonObject json, RecipeCondition value)
        {
            json.addProperty("recipe_enabled", value.loaded);
        }

        @Override
        public RecipeCondition read(JsonObject json)
        {
            return new RecipeCondition(GsonHelper.getAsBoolean(json, "recipe_enabled"));
        }

        @Override
        public ResourceLocation getID()
        {
            return RecipeCondition.NAME;
        }
    }
}

 

Registered the serializer class in RegistryEvents class:

Spoiler

@SubscribeEvent
public void registerSerializers(RegistryEvent.Register<RecipeSerializer<?>> event) {
	CraftingHelper.register(RecipeCondition.Serializer.INSTANCE);
}

 

 

Currently getting an "Unknown condition type" error when using the runData task which likely means the condition wasn't registered correctly, but don't know how this is the case.

Spoiler

Caused by: com.google.gson.JsonSyntaxException: Unknown condition type: mod_id:recipe_enabled

 

Edited October 17, 2022 by CrackedScreen
Changed text

[ChampionAsh5357]

How are you listening to the register event? If using EventBusSubscriber, the method needs to be static.

[CrackedScreen]

The register event works fine after setting the method to static, though now it seems that changing the config file values inside of the save folder doesn't have any effect on whether the recipe is active or not. Code is still same as above.

[ChampionAsh5357]

That makes sense, you cache the static value of the boolean. You should not need any parameters and just check in test if the config value is loaded. Then, you need to resave the config and reload the datapack, because the condition won't be checked if the datapack isn't reloaded.

[CrackedScreen]

I've already tried pulling the value directly from configs, this does not change the result.

Spoiler

public class RecipeCondition implements ICondition {

    public static final RecipeCondition INSTANCE = new RecipeCondition();
    private static final ResourceLocation NAME = new ResourceLocation(MOD_ID, "recipe_enabled");

    public RecipeCondition() {
    }

    public ResourceLocation getID() {
        return NAME;
    }

    @Override
    public boolean test(IContext context) {
        return Config.ENABLED_CRAFTING.get();
    }

    @Override
    public boolean test() {
        return false;
    }

    public static class Serializer implements IConditionSerializer<RecipeCondition>
    {
        public static final Serializer INSTANCE = new Serializer();

        @Override
        public void write(JsonObject json, RecipeCondition value)
        {
            json.addProperty("recipe_enabled", Config.ENABLED_CRAFTING.get());
        }

        @Override
        public RecipeCondition read(JsonObject json)
        {
            return RecipeCondition.INSTANCE;
        }

        @Override
        public ResourceLocation getID()
        {
            return RecipeCondition.NAME;
        }
    }
}

 

The recipes aren't being loaded as the serializer is returning null after using /reload, the problem is likely the read() method but I'm not sure what it should return since the examples provided by forge return a new condition with constructor. Would also prefer to reload datapacks from code whenever the world/server is loaded, if possible.

Edited October 18, 2022 by CrackedScreen

[ChampionAsh5357]

57 minutes ago, CrackedScreen said:

The recipes aren't being loaded as the serializer is returning null after using /reload

That would mean the serializer is null.

58 minutes ago, CrackedScreen said:

the problem is likely the read() method but I'm not sure what it should return since the examples provided by forge return a new condition with constructor

Not really an issue with read, though you don't need to write anything and the single boolean test needs to return the config value as well.

58 minutes ago, CrackedScreen said:

Would also prefer to reload datapacks from code whenever the world/server is loaded, if possible.

You can look at the `ReloadCommand` to learn how to do this, but it should generally be avoided unless the cached config value changes.

[CrackedScreen]

3 hours ago, ChampionAsh5357 said:

That would mean the serializer is null.

You'll have to elaborate on why this is the case since I don't see any immediate issues. I created the condition almost the exact same way the builtin forge conditions are.

Edit: The recipes are disabled if the config value is set to false, but only after manually reloading. Will need a fix for the serializer issue and best practices for forcing a reload upon entering a world if the serializer fix doesn't correct this behavior.

Edited October 18, 2022 by CrackedScreen
Update

[ChampionAsh5357]

44 minutes ago, CrackedScreen said:

You'll have to elaborate on why this is the case since I don't see any immediate issues.

I wouldn't know the reasoning. There's no inclination in the code provided that there would be an issue. The only thing I can think of is the event listener where you register things, which you would need to show the entire class for. Anything else might result from a separate issue.

[CrackedScreen]

Registry class:

Spoiler

@Mod.EventBusSubscriber(bus=Mod.EventBusSubscriber.Bus.MOD)
    public static class RegistryEvents {
  
	@SubscribeEvent
	public static void registerSerializers(RegistryEvent.Register<RecipeSerializer<?>> event) {
		CraftingHelper.register(RecipeCondition.Serializer.INSTANCE);
	}
}

 

I could try registering this outside of event bus in a non-static context.

[ChampionAsh5357]

Ah, you need to provide your modid to the event bus subscriber.

[CrackedScreen]

Adding modid = MOD_ID to my event bus subscriber didn't have any effect. The serializer only has the null issue when the config value is set to false for some reason, if I return true/false directly in the condition class or leave the config value as true there aren't any issues with loading/blocking the recipe.

Edited October 19, 2022 by CrackedScreen

[ChampionAsh5357]

3 hours ago, CrackedScreen said:

The serializer only has the null issue when the config value is set to false for some reason, if I return true/false directly in the condition class or leave the config value as true there aren't any issues with loading/blocking the recipe.

Ah, so it's a defaulting issue. Well, the way to fix that is to either give your config a default, or to cache the value into a boolean and change the boolean when the config is loaded and reloaded using (ConfigEvent$Loading and ConfigEvent$Reloading).

[CrackedScreen]

The test value that I'm using already has a default value set:

Spoiler

public static ForgeConfigSpec.BooleanValue ENABLED_CRAFTING;

public static void registerConfig() {
	ForgeConfigSpec.Builder CONFIG_BUILDER = new ForgeConfigSpec.Builder();

	ENABLED_CRAFTING = CONFIG_BUILDER
		.define("Test value", true);

	ModLoadingContext.get().registerConfig(ModConfig.Type.COMMON, CONFIG_BUILDER.build());
}

 

Will look into using booleans, but I may have tried this + reloading before with no success using something similar:

Spoiler

@SubscribeEvent
public static void onConfigLoad(ModConfigEvent.Loading event) {
	((CommentedFileConfig)event.getConfig().getConfigData()).load();
}

 

 

Edited October 19, 2022 by CrackedScreen

[ChampionAsh5357]

On 10/19/2022 at 2:45 PM, CrackedScreen said:

	((CommentedFileConfig)event.getConfig().getConfigData()).load();

Yeah, that looks like it may cause a infinite loop. The events are called because the data has finished loading and reloading and are now within the config values. These are for if you want to know when those values are changed.

[CrackedScreen]

Managed to fix this by creating different conditions for each recipe and reusing the same serializer. Apparently it isn't possible to return different values with the same condition, and the "null issue" is forge working as intended according to here:

https://github.com/P3pp3rF1y/Reliquary/issues/529