Eio intergration broken
tyler489 opened this issue · 21 comments
Description
You diable applied energistics wooden gear but leave the ability for thYou diable applied energistics wooden gear but leave the ability for the "disabled" item to be crafted causing a regipy conflict. https://gyazo.com/da50ad9b5bdefd268b7bb9185ab80f00
Environment
Mp "vanilla forge"
Minecraft 1.12
| UCHIJA | FML | 8.0.99.99 | forge-1.12.2-14.23.2.2615-universal.jar | e3c3d50c7c986df74c645c0ac54639741c90a557 |
| UCHIJA | forge | 14.23.2.2615 | forge-1.12.2-14.23.2.2615-universal.jar | e3c3d50c7c986df74c645c0ac54639741c90a557 |
| UCHIJA | openmodscore | 0.11.5 | minecraft.jar | None |
| UCHIJA | actuallyadditions | 1.12.2-r130 | ActuallyAdditions-r130.jar | None |
| UCHIJA | appliedenergistics2 | rv5-stable-10 | appliedenergistics2-rv5-stable-10.jar | None |
| UCHIJA | bdlib | 1.14.3.12 | bdlib-1.14.3.12.jar | None |
| UCHIJA | ae2stuff | 0.7.0.4 | ae2stuff-0.7.0.4.jar | None |
| UCHIJA | baubles | 1.5.2 | Baubles-1.5.2.jar | None |
| UCHIJA | betterbuilderswands | 0.11.1 | BetterBuildersWands-1.12-0.11.1.245.jar | None |
| UCHIJA | chameleon | 1.12-4.1.3 | Chameleon-4.1.3.jar | None |
| UCHIJA | ctm | MC1.12-0.2.3.12 | CTM-MC-0.2.3.12.jar | None |
| UCHIJA | chisel | MC1.12-0.1.1.26 | Chisel-MC-0.1.1.26.jar | None |
| UCHIJA | chiselsandbits | 14.13 | chiselsandbits-14.13.jar | None |
| UCHIJA | codechickenlib | 3.1.5.331 | CodeChickenLib-3.1.5.331.jar | f1850c39b2516232a2108a7bd84d1cb5df93b261 |
| UCHIJA | redstoneflux | 2.0.1 | RedstoneFlux-2.0.1.2.jar | d4f1503fbacd9b9fb767720420c5395104239ec9 |
| UCHIJA | cofhcore | 4.3.10 | CoFHCore-4.3.10.5.jar | None |
| UCHIJA | cofhworld | 1.1.1 | CoFHWorld-1.1.1.12.jar | None |
| UCHIJA | cucumber | 1.0.4 | cucumber-1.0.4.jar | None |
| UCHIJA | endercore | 1.12.2-0.5.16 | EnderCore-0.5.16.jar | None |
| UCHIJA | jei | 4.8.5.147 | JEI-4.8.5.147.jar | None |
| UCHIJA | enderio | 5.0.244-nightly | EnderIO-5.0.244.jar | None |
| UCHIJA | enderiointegrationtic | 5.0.244-nightly | EnderIO-5.0.244.jar | None |
| UCHIJA | enderiobase | 5.0.244-nightly | EnderIO-5.0.244.jar | None |
| UCHIJA | enderiointegrationforestry | 5.0.244-nightly | EnderIO-5.0.244.jar | None |
| UCHIJA | mantle | 1.12-1.3.1.21 | Mantle-1.3.1.21.jar | None |
| UCHIJA | tconstruct | 1.12.2-2.9.0.55 | TConstruct-2.9.0.55.jar | None |
| UCHIJA | enderiointegrationticlate | 5.0.244-nightly | EnderIO-5.0.244.jar | None |
| UCHIJA | enderiomachines | 5.0.244-nightly | EnderIO-5.0.244.jar | None |
| UCHIJA | enderioconduits | 5.0.244-nightly | EnderIO-conduits-5.0.244.jar | None |
| UCHIJA | enderiopowertools | 5.0.244-nightly | EnderIO-conduits-5.0.244.jar | None |
| UCHIJA | enderzoo | 1.12.1-1.4.0.49 | EnderZoo-1.4.0.49.jar | None |
| UCHIJA | exnihilocreatio | 1.12-0.1.7 | exnihilocreatio-0.1.7.jar | None |
| UCHIJA | excompressum | 3.0.17 | ExCompressum-3.0.17.jar | None |
| UCHIJA | zerocore | 1.12-0.1.1.0 | zerocore-0.1.1.0.jar | None |
| UCHIJA | bigreactors | 1.12.2-0.4.5.46 | ExtremeReactors-0.4.5.46.jar | None |
| UCHIJA | ftblib | 5.0.0.13 | FTBLib-5.0.0.13.jar | None |
| UCHIJA | ftbutilities | 5.0.0.10 | FTBUtilities-5.0.0.10.jar | None |
| UCHIJA | theoneprobe | 1.4.19 | theoneprobe-1.4.19.jar | None |
| UCHIJA | immersiveengineering | 0.12-76 | ImmersiveEngineering-0.12-76.jar | 4cb49fcde3b43048c9889e0a3d083225da926334 |
| UCHIJA | inventorytweaks | 1.63+release.109.220f184 | InventoryTweaks-1.63.jar | 55d2cd4f5f0961410bf7b91ef6c6bf00a766dcbe |
| UCHIJA | ironchest | 1.12.2-7.0.40.824 | ironchests-7.0.40.824.jar | None |
| UCHIJA | journeymap | 1.12.2-5.5.2 | JourneyMap-5.5.2.jar | None |
| UCHIJA | mysticalagriculture | 1.6.8 | mysticalagricultur-1.6.8.jar | None |
| UCHIJA | recipehandler | 0.10 | NoMoreRecipeConflict-0.10.jar | None |
| UCHIJA | openmods | 0.11.5 | OpenModsLib-0.11.5.jar | d2a9a8e8440196e26a268d1f3ddc01b2e9c572a5 |
| UCHIJA | openblocks | 1.7.5 | OpenBlocks-1.7.5.jar | d2a9a8e8440196e26a268d1f3ddc01b2e9c572a5 |
| UCHIJA | rftools | 7.30 | rftools-7.30.jar | None |
| UCHIJA | storagedrawers | 1.12-5.2.5 | StorageDrawers-1.12.2-5.3.4.jar | None |
| UCHIJA | thatsagoodmap | 1.12.2-63981.13729.42779.00000002 | ThatsAGoodMap-63981.13729.42779.00000002.jar | None |
| UCHIJA | middletorch | 6.0.1 | the-middle-torch-6.0.1.jar | None |
| UCHIJA | tinker_io | release 2.6.0a | tinker_io-2.6.0a.jar | None |
| UCHIJA | tinkertoolleveling | 1.12-1.0.3.DEV.56fac4f | TinkerToolLeveling-1.0.3.jar | None |
| UCHIJA | tp | 1.12 | tinyprogressions-3.2.10.jar | None |
| UCHIJA | travelhut | 3.0.1 | Travel-Huts-3.0.1.jar | None |
| UCHIJA | ts2k16 | 1.2.8 | TS2K16-1.2.8.jar | None |```
Our own recipes are automatically disabled once certain items are missing. But due to how minecraft handles items, there is no guaranteed way to disabled them completely, so if another mod forcefully adds a new recipe using our items and ignores that they are disabled, there is nothing we can do about it.
Ender io adds a wooden gear for enderio:wooden_gear it has the same recipy as appliedenergistics:wooden_gear enderio is not assigning its recipy to your gear... but your gear is still craftable
If you're not interested in issue reports, just disable the tracker. Trying to chase off people by giving nonsensical answers won't work.
i agree i dont even report bugs or suggestions anymore because im afraid im going to get talked down to or thrown under the rug if i do after all the bugs ive read here.
Our own recipe is directly tied to the state of our gear. If it is disabled, there is no recipe. Simple as that.
And when I did try it with a couple of other mods adding their own version (including EiO), it was always disabled correctly. Usually even a bit too strict and just leaving something like forestry treated gears.
But seeing a mod listed, which aims to modify recipe conflicts, it raises some questions. But an issue tracker is simply the wrong place to debug a random modpack. Once the modpack author has identified whatever mod combination is responsible, then the issue should be created.
@zerotheliger Feel free to post bugs/ideas. I just expect that people have some common sense and can read stuff like the issue template or readme. They exist for a reason. So the common questions are covered and we don't have to ask them again and again and waste time with it. Or blatantly ignoring it, like not using the search when the basic keywords they use as title find it. Yes, I know the github search is not the best, so it is really just for extreme cases. Or stuff like a modpack author not willingly to debug their own pack, because it would waste some of their time, but then except that is fine for us to waste it.
But seeing a mod listed, which aims to modify recipe conflicts
so just because i worked around it you can magically ignore the issue? is that how this works? does every pack dev want to add a mod just so they can work around a broken recipy?
@yueh this is a big enough issue that it was a major problem in the ftb pack for 1.12 when it first came out as binnies registers its gears as wooden however they are fermented and thus not exactly the same. This meant that there was no way to craft wooden gears in the pack. Perhaps just keep the item and the recipe, since disabling both doesn't do anything and the gear uses ore dictionary anyway
@EpicSquid It can be explicitly enabled when necessary. If the mod pack maker does not want it, then it is not really our problem. The goal is simply to avoid as many duplicates as possible without requiring any manual intervention. But you will most likely enjoy 1.13 as it probably makes it impossible and you have to manually resolve all recipe conflicts and deal with dozens of the same item type. And when really lucky without anything like minetweaker/crafttweaker. As recipes have to be defined as json files with optionally something like the current factories. But they might be immutable afterwards. Also transfer from server to client each join, so something like CT/MT could easily trigger timeouts again. Maybe even JEI when really unlucky.
@tyler489 Yes, because it claims to be an AE2/EnderIO issue, which I cannot reproduce and basically brings us back to the first comment. If it would just be limited to both mods, I would handle it differently. But with the whole modpack it basically falls into the "Please fix my modpack" category. Which is simply out of scope for the tracker.
I understand there is a config option, however perhaps this should be enabled by default? It's needlessly confusing and functions contrary to most mods. Also plenty of mods exist for unification, so ae probably doesn't need its own method.
I'm looking at this right now. Looks like the material is still being registered and tagged as "A-OK" which shouldn't happen.
This is causing the recipe json constraints to also just go "this item is loaded and being used, load the recipe up as normal".
I haven't found the root cause yet but I'm looking for which part of our code is failing.
EDIT: Found the root cause, now I'm looking at how I can fix this without breaking too much else.
Long story short the part of the code that is in charge of removing the "duplicate" stuff from AE2 gets ran after the recipe (and its lookup) code. So for all intents and purposes the codebase thinks every item is "in the game", because it still is.
This issue is a much bigger deal with Silicon also being disabled automatically and EIO's version unusable with AE2's press. Adjusting the AE2 orecamo config options does help, but things playing nicely together would be awesome. I appreciate your work yueh, and the EIO teams.
@yueh just resolve this but not disabling your items by default. It's a dumb thing to do, they are oredicted anyway so who cares if they use your gear instead of another mods? Wouldn't this be less effort for you and for everyone else?
Also it did not work fine until now, see the binnies issue that occurred when FTB Revelation came out. There are just so few mods that add wooden gears it "appeared" to not be an issue.
Basically I cannot debug it in a dev environment as EnderIO refuses to work inside one.
Also it registers its recipes in a completely wrong phase, which might conflict with our ore camouflage as until now it worked fine with other mods. But that is the reason why there is a config option. To have a fallback for the 1% case, where it does not work.
Ultimately it is a forge issue. Their init system is a piece of shit and that is already the nice way of putting it. It is simply designed to prevent any sorts of playing nicely together and preferes offloading all issues on the user in certain unpreventable cases. Be it manual interventions in terms of playing with config values until it somehow works, having to deal with dozens of duplicate item types and no way to unify them without breaking other stuff, or similar. Convince them to use a system, which allows us to proactively handle it. (I know, bullshit bingo). Instead of trying to solve the mess it produces retroactively, as there are always some cases which are impossible to solve after they have happened.
BTW: We register our recipes in that weird IMC phase because that is the first phase where all mods we have integrations for have registered their oredicts. Any earlier and some recipes would fail. Any later and we'd be too late to relay our alloying recipes to TiC.
Using rv5-stable-11, default configs no longer seem to include the Ore Camouflage section. If I copy the Ore Camouflage section from an older config, it has no effect. Has the ore camo config been removed?
