Enigmatica 6 - E6 - 1.16.5

Enigmatica 6 - E6 - 1.16.5

1M Downloads

Race Condition Between Base Recipes and Expert Mode Recipes Causes Use of Non-Expert Mode Recipes in Random Occasions

Sparklingtips opened this issue ยท 41 comments

commented

Modpack Version

1.0.0, 1.1.2, 1.2.1

Describe your issue.

When utilizing a paid host service including the pack advertised host (Bisect) recipes for at least the pressure chamber seem to use normal mode instead of expert.

Steps to Reproduce:

  1. Install expert mode any version on a paid hosting service (May be limited to hosts running linux but unsure, this was an idea offered by Bisect)
  2. Join server
  3. Open inventory
  4. Search "Empty PCB" in JEI
  5. Left click "Empty PCB" item in JEI
  6. Click "Pressure Chamber" tab
  7. Notice recipe

Expected Result:

  • Recipe should be 1 copper plate (Emendatus Enigmatica), 6 flux dust (Flux Networks), 2 plastic (PneumaticCraft)

Actual Result:

  • Recipe is the vanilla PneumaticCraft recipe which is the expected result in normal mode - 3 nugget copper/gold, 2 redstone torch, 1 plastic (PneumaticCraft)

Attempted fixes (Tried for v1.1.2 & 1.2.1):

  1. Restart server
  2. Run /mode expert command
  3. Reinstall server using host provided install option
  4. Install server files locally, join local server, verify recipes are using the expected result, zip, FTP to Bisect, extract, Run server using the serverstarter-2.2.0.jar

According to Bisect they use the CurseForge version to create their instances so they believe this to be an issue with the modpack itself. Running a privately hosted instance on Win10 I can confirm recipes working as expected so this could really be a host/OS issue but since there's an affiliate deal between Bisect and Enigmatica and this was reproducible on two paid hosts I figured this might be worth bringing up on Github since I'm uncertain if this issue is just limited to the PneumaticCraft Pressure Chamber or includes other expert mode changes.

Crash Report

N/A

Latest Log

Unable to access due to refund request

Have you modified the modpack?

No

User Modifications

No response

Did the issue happen in singleplayer or on a server?

Server

commented

Just for clarification, the recipes show correctly in single player, correct? Then, from that same instance, you log into a bisect server, it's broken. But if you log into a locally hosted server, it's fine again?

commented

Yes, single player works fine, locally hosted server (Not single player, actually installed server files on the same PC I run my client on because I like to live dangerously) on Win10 works fine, paid hosting on Linux breaks. This can funnily enough be also seen in this video https://youtu.be/L-F7TG4Y5kQ?t=473 (also running on server) where the content creator looks at the recipe, taking a wild guess based on his affiliate message in his description he's also on Bisect.

YouTube
We continue pushing through today towards our drawer controllers as we work on expanding and advancing through some basic pneumaticcraft. Drawer controllers...
commented

Can fully confirm, despite the recipe claiming for a copper plate, the pressure chamber refuses to accept a copper plate, despite my best efforts. It does the exact same thing it does with a potato, so I assume the problem is that a copper plate is not used in any pressure chamber recipes, on my server, which supports this issue.

I use exaroton with a custom forge setup from 0.5.26, having run /mode expert. Every other recipetype works expertly

commented

Quick image, my item transporter is not bringing the copper plate from the chest into the input valve. This setup works for everything else, including autocrafting RS things, it just fails on the empty PCB recipe

image

commented

This is.. super weird. Do other expert recipes work as expected?

commented

From the random poking around that I did after noticing the initial issue at a minimum all of the components used in the Printed Circuit Board recipe that are created using the Pressure Chamber (empty PCB, Capacitor, Transistor) all used the normal recipes. I was able to see what appeared to be a few expert mode recipes working as expected (I didn't dig through the recipetypes a whole lot but at least the mekanism basic circuit used the KubeJS package recipe which appeared expert only and other items "looked" to be using the right recipe). I don't have a full list of the working/broken recipes which is why I labeled this as Pressure Chamber only with a possibility of other recipes since root cause is unknown and I didn't fully test out the expert mode recipe changes. The other user on 0.5.26 might be able to give a better list since I no longer have access to the hosted servers to hop on an test through.

commented

There is a potential issue with reloading (which switching modes would do). Since the switch is unnecessary (the server will launch in expert mode if you installed the expert pack) please try restarting the server + client and checking the recipe immediately.

commented

This is what caused us to notice the recipe was wrong in the first place:

  1. Installed server on paid host
  2. Moved world folder from self hosted onto the new paid host
  3. Launched server
  4. Pretty Pipes Retrieval Module auto requested Empty Circuit Board from Pretty Pipes
  5. Items sent to Hopper connected to pressure chamber
  6. Copper plate is unable to be input from hopper into Pressure Chamber Input

This whole setup was working (and still is) on self hosted. We ran the /mode expert command after we noticed this issue so it existed on first time startup following the steps above.

commented

I'll point back to #4543 as well.

commented

@Ommina Out of curiosity when you ran into this (Since the effects seem to match with what we were seeing when we ran into this) were you hosting this yourself or paid hosting? I'm curious to see if someone self hosting on a *nix system runs into these issues or if they're limited to something paid hosting services do (since this would kill the argument from Bisect that it might be a windows vs linux host). I can spin up an Ubuntu VM at some point if no one is running a server already but I'd figure someone probably is

commented

@Sparklingtips Self-hosted on a local PC. Ubuntu 20.04.2 LTS

Since the issue popped up again, I took the opportunity to update the pack and the issue persists. Best I can tell, it is affecting only those few pressure chamber recipes.

It's... certainly odd!

commented

@desht You got any ideas? Appears to only affect the pressure chamber. Not sure if anything in that vein has been reported.

commented

Hmm, super weird does indeed describe this. It would be very useful to see a log file from any affected instance (looking for errors from KubeJS for example)...

commented

Was just about to comment about this and saw it was already reported on here. Yeah, actually a few of the pressure chamber expert recipes aren't working. The 3 ones I have readily noticed are transistors, capacitors, and empty pcbs but there may be more. Our server is not on bisect, its actually one hosted by Sverd, one of the channel's admins and is hosted from his home. He manages all of our server related stuff since he does server stuff as his profession. But can confirm the same issue, recipes work fine in single player but server side they don't so have to be automated with the vanilla pneumaticraft recipes.

commented

It's a head-scratcher. I just tried a similar piece of config on my test server (using the same JS constructs as E6E):

onEvent('recipes', (event) => {
    const recipes = [
    {
            inputs: [
                { tag: 'forge:ingots/steel', count: 2 },
                { tag: 'pneumaticcraft:plastic_sheets', count: 2 },
                { tag: 'forge:obsidian', count: 1 }
            ],
            pressure: 4.0,
            results: [{ item: 'minecraft:netherite_ingot', count: 4 }],
            id: 'pneumaticcraft:pressure_chamber/netherite_ingot'
        }
    ];

    recipes.forEach((recipe) => {
        let ingredients = [];
        recipe.inputs.forEach((input) => {
            input.type = 'pneumaticcraft:stacked_item';
            ingredients.push(input);
        });

        event.custom({
            type: 'pneumaticcraft:pressure_chamber',
            inputs: ingredients,
            pressure: recipe.pressure,
            results: recipe.results
        }).id(recipe.id);
    });
}

and this works correctly. A Pressure Chamber recipe for (2 steel, 2 plastic, 1 obsidian) -> 4 Netherite is added on my dedicated server & shows up in JEI for clients that connect to it, and the recipe actually works in-game. So the Javascript looks good, PNC is taking the recipe OK.

commented

Just to be clear.

JEI is showing the wrong recipe. But if you look up the expert recipe in SP does that work on the server?

Also, as mentioned, a log from joining a server where this happens would potentially be useful.

commented

@Darkere Nay. While on the server, JEI shows the normal recipe, and only the normal recipe works. That is, it is not a mismatch between what JEI displays and what the pressure chamber accepts as a valid recipe. It is the normal recipe that is displayed and works.

(Qualification: in my particular case, there was a period where JEI showed the expert recipe, with the normal recipe active. Make of that what you will.)

There are no KubeJS errors in the log best I can tell. (Here is the KubeJS server.txt file. If you would like the full debug.log, I can cough it up somewhere.)

As an aside: apologies to @Sparklingtips -- it was not my intention to barge into your issue!

commented

Is there something unique to E6E, that happens after the KubeJS stuff, that could be reverting the recipes back to normal?

I'm grasping, I admit it. (Especially since I can't think of a condition where such thing would happen only on a server.)

commented

The thing that makes this so impossible is that there are plenty of servers where this is working just fine....

commented

For what it's worth, our 2 servers does not see this issue. One is self-hosted on Windows, the other is on Bisect.

commented

For me its a mix. The empty pcb for example shows the normal mode recipe and accepts the normal mode recipe for crafting in the pressure chamber at present, though at one point it did show the expert recipe but wouldnt accept it. However transistors and capacitors both atm show the expert recipes, but wont accept the majority of the items since it doesnt see valid recipes for those items (wire, processors) and will instead accept and craft with normal recipes. Single player, everything works as expected, only on a server where it doesnt

commented

Also reloading will sometimes swap what recipes are shown in jei, but doesnt allow for it to craft the expert recipes or accept the items, just plays switcheroo with jei

commented

Also there was a time when capacitors and transistors did work and display the expert recipe, but since has stopped working so it may work on short term tests or on some servers and not others, but possibly may stop working after some time. Havent noticed expert recipes that swap to normal ever swapping back though outside of just what jei displays, jei tends to act like it's confused by the whole situation and just chooses a recipe at random.

commented

And why just those particular handful of items, when the rest of the items added from the same pressure_chamber.js file work correctly?

Are the problematic recipes restricted to those that are replacements, instead of additions? (Yes, still grasping.)

commented

Yeah, from what I have seen its only replacement recipes. Additional recipes all work fine every time I craft them without issue so it hasnt been a major headache or anything. Not much different since the difference in cost between expert transistors and such and normal is basically non existent since its all automated, just thought to report it when I was swapping over automation from expert to normal when my transistors fell off the wagon :p

commented

And if you still need a log, just let me know if you want the kube logs or the client logs or server logs or whichever might be the most helpful

commented

latest.log and debug.log of the server ideally

commented

latest.log and debug.log of the server ideally
https://sverd.eu/lastest.log
https://sverd.eu/debug.log

If you need other logs from ToAsgaards server I can provide them

commented

Those links lead to nowhere

commented

Those links lead to nowhere

sorry, typo :) https://sverd.eu/latest.log
debug link works for me, I get a dialog to save them. Any other way you want them posted?

commented

This is on ToAsgaard's server? I had noticed a couple other incorrect recipes while watching, so I don't think the issue is limited to just this.

It's been a few episodes now, but one that springs to mind is the Pretty Pipes Crafting Terminal not needing Super Glue:
image

There've been a few others here and there too that I can't quite remember at the moment.

commented

Yeah, its from our server. Never knew the terminal was meant to take superglue. I just assumed it was only pressure chamber that was acting up

commented

Interesting. I just checked mine -- no super glue required. Loaded up SP, super glue and two string required.

Curiouser and curiouser.

commented

That's another replacement recipe, if memory serves. I'm wondering if maybe that aspect of kubejs (recipe override) is somehow failing...

commented

As an aside: apologies to @Sparklingtips -- it was not my intention to barge into your issue!

@Ommina All good, this was always going to need other people to chime in since we no longer had access to the log files and couldn't reproduce without buying more server time (which funnily enough my friend did last night and we got a random 3rd party linux host that appears to be working fine so .-. really weird issue).

I'll go ahead and bow out from contributing on this bug for the time being since others who have access to bugged instances are currently working to work a solution but I'll keep an eye out if I need to provide something.

commented

An update, of sorts, although I'm not sure it offers much help.

Consistent with the inconsistency noted by ToAsgaard above, my JEI is now showing the expert recipes, however, the pressure chamber (acknowledging that this has moved beyond just the pressure chamber) is using the normal. So, at the moment, there is a mismatch between JEI and the server.

Server has not been restarted since the discussion of 12h ago. I have restarted the client.

(Edit: the Pretty Pipes crafting thingie shows the normal, non super glue recipe.)

commented

And I'm just glad it wasn't a PNC issue ๐Ÿ˜‰

Nice work in tracking that down!

commented

TLDR: Base recipes are overwriting expert mode recipes based on execution order of recipe modification scripts.

This is going to be a massive wall of text but due to the fact that this has been such an odd (and frustrating) issue I figured that this level of detail would be necessary in order to document what I believe to be causing the issue so people who are more familiar than myself with KubeJS can verify and formulate a fix if accurate. At the very least this may help to narrow down a root cause.

When I last commented on this thread we had found a host that appeared to be working and all was going well, until today. After a normal restart we noticed that the recipes that were identified in this thread so far (prettypipes:crafting_terminal, pneumaticcraft:empty_pcb, pneumaticcraft:capacitor, pneumaticcraft:transistor) were all using "normal" recipes. Well after some digging, "normal" doesn't appear to be quite the right term to use here, what seems to be happening is that when KubeJS goes and modifies recipes there is some condition in which the expert/recipetypes/[mod]/[craftingtype].js file is executed and THEN the base/recipetypes/[mod]/[craftingtype].js file is executed which overrides some recipes that are set by the expert scripts. This is why some expert recipes work as normal and some do not. The exact reason why this happens is unknown to me but appears to be what's occurring after verifying the following:

On a server experiencing the bug modify:

  1. \kubejs\server_scripts\enigmatica\kubejs\base\recipetypes\pneumaticcraft\pressure_chamber.js to include console.log(`[TIPS]: Base - RecipeTypes - PneumaticCraft - Pressure Chamber - Packmode is expert: ${global.isExpertMode} - Packmode is normal: ${global.isNormalMode}`); after entry into before creation of id_prefix constant
  2. \kubejs\server_scripts\enigmatica\kubejs\expert\recipetypes\pneumaticcraft\pressure_chamber.js to include console.log(`[TIPS]: Expert - RecipeTypes - PneumaticCraft - Pressure Chamber - Packmode is expert: ${global.isExpertMode} - Packmode is normal: ${global.isNormalMode}`); after entry into onEvent and before global.isExpertMode check
  3. Comment out one of the affected recipes in the base\recipetypes path, for my test I chose to comment out \base\recipetypes\pneumaticcraft\pressure_chamber.js:5-14 (line numbers are +1 from a file that does not contain the added console.log entry from step 1) which contains the pneumaticcraft:empty_pcb recipe.

After performing the steps above and starting the server one can notice in the log that the Expert console log fires before the Base console log, overwriting any changes made by the expert script in which both files paths contain a copy of the recipe:
[01:53:27] [Worker-Main-2/INFO]: server_scripts:enigmatica/kubejs/expert/recipetypes/pneumaticcraft/pressure_chamber.js:2: [TIPS]: Expert - RecipeTypes - PneumaticCraft - Pressure Chamber - Packmode is expert: true - Packmode is normal: false
[01:53:31] [Worker-Main-2/INFO]: server_scripts:enigmatica/kubejs/base/recipetypes/pneumaticcraft/pressure_chamber.js:2: [TIPS]: Base - RecipeTypes - PneumaticCraft - Pressure Chamber - Packmode is expert: true - Packmode is normal: false

After following the above steps and joining the server all recipes that were identified at the beginning of this post use the "base" recipe EXCEPT for empty_pcb which now uses the expert mode recipe since the base recipe was manually commented out, indicating that this is what causes the recipe overwrite and also explains why the pack mode is irrelevant since the base scripts do not contain a check for what pack mode is set before recipe modification.

When following the steps above on a non-affected server the following can be seen in the log:
[03May2022 22:06:35.183] [Worker-Main-4/INFO] [KubeJS Server/]: server_scripts:enigmatica/kubejs/base/recipetypes/pneumaticcraft/pressure_chamber.js:2: [TIPS]: Base - RecipeTypes - PneumaticCraft - Pressure Chamber - Packmode is expert: true - Packmode is normal: false
[03May2022 22:06:35.787] [Worker-Main-4/INFO] [KubeJS Server/]: server_scripts:enigmatica/kubejs/expert/recipetypes/pneumaticcraft/pressure_chamber.js:2: [TIPS]: Expert - RecipeTypes - PneumaticCraft - Pressure Chamber - Packmode is expert: true - Packmode is normal: false

Here it can be seen that the base recipes are applied first and then overwritten by the expert recipes as expected.

With all of the above in consideration I would probably prefer that at least one other affected server is able to verify that they produce results similar to what is listed above in the sections regarding bugged servers just to check my work here and make sure it's not just some freak coincidence that on a bugged vs non-bugged server the order of the console.logs appearing in the log file seems to coincide with the base recipes overwriting the expert mode recipes.

If at least one other person is able to verify then I'd hazard a guess this is most likely the cause and at that point an attempted fix would probably be one of the following:

  1. Somehow enforce recipe modifications are executed in the "base" folder before executing the normal or expert mode recipes, (This could possibly be done by having one file with a function that is entered by the 'recipes' event and then having it call functions for recipe modification for the base recipes then normal recipes and finally expert recipes. I'm sure other solutions that may be easier exist however) this seems like potentially the easiest fix
  2. Move any "base" recipes that are overwritten in expert mode into the normal mode recipe modifications since these are not really "base" recipes anyways
  3. Leave the base recipes that are overwritten by expert mode in the existing base files but add checks for global.isExpertMode (probably not a good one because then as noted in point 2 you'd still have recipes that are not truly "base" left in the base folder and random checks for isExpertMode scattered around in those files)
  4. Anything not noted above that may be available that would work to enforce that base recipes do not overwrite mode specific recipes
commented

Vroom vroom race condition!! sounds like we messed up and have some recipes in base that should be in normal haha... good catch!! We should be able to just move these recipes to our normal scripts using the normal check. should fix the issue!

We should not have anything in base that we are also modifying in expert xD

commented

Nice catch!

commented

I'm just glad that we were able to finally track down this issue (hopefully for good) because trying to move from local to hosted and running into this repeatedly was making me lose my mind lol