feat: add a proper SPS recipe type by Satherov · Pull Request #8404 · mekanism/Mekanism

Satherov · 2025-05-18T17:46:17Z

Adds a proper recipe type to the sps allowing for custom recipes and data generation

thiakil · 2025-07-19T09:10:22Z

        MekanismConfigTranslations.GENERAL_SPS.applyToBuilder(builder).push("sps");
-        spsInputPerAntimatter = CachedIntValue.wrap(this, MekanismConfigTranslations.GENERAL_SPS_ANTIMATTER_COST.applyToBuilder(builder)
-              .defineInRange("inputPerAntimatter", FluidType.BUCKET_VOLUME, 1, Integer.MAX_VALUE));
+        spsInputTankCapacity = CachedLongValue.wrap(this, MekanismConfigTranslations.GENERAL_SPS_CAPACITY_OUTPUT.applyToBuilder(builder)


forgotten translation? output != input

Yeah, added an input translation, my bad 😅

thiakil · 2025-07-19T09:12:58Z

+import net.minecraft.world.item.crafting.RecipeHolder;

-public class SPSRecipeCategory extends BaseRecipeCategory<SPSRecipeViewerRecipe> {
+public class PhaseShiftingRecipeCategory extends HolderRecipeCategory<PhaseShiftingRecipe> {


I'd prefer if this (and similar) wasn't renamed

Renamed all occurrences of PhaseShifting to SPS

thiakil · 2025-07-19T09:15:53Z

            list.add(MekanismLang.STATUS.translate(MekanismLang.ACTIVE));
-            list.add(MekanismLang.SPS_ENERGY_INPUT.translate(EnergyDisplay.of(
-                  MathUtils.multiplyClamped(MekanismConfig.general.spsEnergyPerInput.get(), MekanismConfig.general.spsInputPerAntimatter.get()))));
+            list.add(MekanismLang.SPS_ENERGY_USAGE.translate(EnergyDisplay.of(recipe.getEnergyUsage() * 1000)));


why's there * 1000 here?

The reason this is there is because otherwise the JEI gui is off by a magnitude of 1000. I'm not sure what's the reason for that, the sps gui lines up with the actual consumption, but JEI doesnt

Energy Consumption

SPS GUI

JEI GUI with the * 1000

JEI GUI without the * 1000

Then there's a bug elsewhere which needs to be solved. Why does the display differ?

Also you should have it display Joules so that you get it matching exactly what the code says

thiakil · 2025-07-19T09:17:16Z

            list.add(MekanismLang.STATUS.translate(MekanismLang.ACTIVE));
-            list.add(MekanismLang.SPS_ENERGY_INPUT.translate(EnergyDisplay.of(
-                  MathUtils.multiplyClamped(MekanismConfig.general.spsEnergyPerInput.get(), MekanismConfig.general.spsInputPerAntimatter.get()))));
+            list.add(MekanismLang.SPS_ENERGY_USAGE.translate(EnergyDisplay.of(energy_usage * 1000)));


* 1000 (see other comment)

thiakil · 2025-07-19T09:27:48Z

-            final int inputPerAntimatter = MekanismConfig.general.spsInputPerAntimatter.get();
-            long inputNeeded = (inputPerAntimatter - inputProcessed) + inputPerAntimatter * (outputTank.getNeeded() - 1);
-            double processable = (double) receivedEnergy / MekanismConfig.general.spsEnergyPerInput.get();
+            lastReceivedRecipeAmount = cachedRecipe.getInput().amount();


this variable name doesn't seem to match what it's used for - I only see it being set with the recipe's required amount (which should be updated in the cached recipe check)

thiakil · 2025-07-19T09:48:00Z

        ));
    }
+
+    public static MekanismRecipeSerializer<BasicPhaseShiftingRecipe> phaseShifting(Function3<ChemicalStackIngredient, ChemicalStack, Long, BasicPhaseShiftingRecipe> factory) {


This factory and return generic is wrong - it should follow the others and have a RECIPE extends generic

Like this? I was following the other "Basic" recipes above which didn't have a generic return either. The non basic version of the sps recipe won't work there because it doesnt have access to the proper output. My example to compare was the NucleosynthesizingRecipe and BasicNucleosynthesizingRecipe which doesn't have a generic return in the MekanismRecipeSerializer

that's why they have, for example, RECIPE extends ChemicalChemicalToChemicalRecipe & IBasicChemicalOutput

thiakil · 2025-07-19T09:49:13Z

-            ChemicalStack toAdd = MekanismChemicals.ANTIMATTER.asStack(inputProcessed / inputPerAntimatter);
-            outputTank.insert(toAdd, Action.EXECUTE, AutomationType.INTERNAL);
-            inputProcessed %= inputPerAntimatter;
+        if (inputProcessed >= lastReceivedRecipeAmount) {


should be inputProcessed >= recipe.amount

inputProcessed >= recipe.getInput().amount() ? recipe.amount doesn't exist

yeah unclear that it was pseudocode sorry

thiakil · 2025-07-19T09:50:14Z


    public static final RVRecipeTypeWrapper<?, ItemStackChemicalToItemStackRecipe, ?> PAINTING = new RVRecipeTypeWrapper<>(MekanismRecipeType.PAINTING, ItemStackChemicalToItemStackRecipe.class, -25, -13, 146, 60, MekanismBlocks.PAINTING_MACHINE);

+    //TODO This needs a better icon [sps_icon.png]


remove todo from code, put in PR description if still needed

removed the todo

thiakil · 2025-07-19T09:58:10Z

+    public @NotNull CachedRecipe<PhaseShiftingRecipe> createNewCachedRecipe(@NotNull PhaseShiftingRecipe recipe, int cacheIndex) {
+        // This is unused since the SPS uses a special way of handling recipes, but we still have to add the function due to the
+        // implementation of the LookupHandler. You could probably make a custom variation of the CachedRecipe and the
+        // RecipeCacheLookupMonitor, but that seems incredibly annoying for a single use case.


we already have a couple of custom ones ;)

From what I could tell not for this use case tho and looking into it doesnt seem like a super simple task to make one either. I can make one if that's required for this to be merged, but what I have works and is fairly performant so I was hoping to get around that 😓

Since the existing functionality already operated on an operations basis, it should be fairly easy to copy paste it into the process part of the RCLM?

At the very least, I'd like to see the recipe cache part use the RCLM like other machines (which means that any tank change and probably energy change causes a recipe check). Currently what you've written doesn't properly handle input change - e.g. output has antimatter, but next input is another recipe with different output

thiakil · 2025-07-21T03:18:53Z

+
+    protected final ChemicalStackIngredient input;
+    protected final ChemicalStack output;
+    private final long energy_usage;


variable naming wrong - use camelCase

feat: add a proper SPS recipe type

78ad1d1

thiakil requested changes Jul 19, 2025

View reviewed changes

thiakil reviewed Jul 21, 2025

View reviewed changes


		public static final RVRecipeTypeWrapper<?, ItemStackChemicalToItemStackRecipe, ?> PAINTING = new RVRecipeTypeWrapper<>(MekanismRecipeType.PAINTING, ItemStackChemicalToItemStackRecipe.class, -25, -13, 146, 60, MekanismBlocks.PAINTING_MACHINE);

		//TODO This needs a better icon [sps_icon.png]

Uh oh!

Uh oh!

Conversation

Satherov commented May 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants