Storage Drawers: Forestry Pack

Storage Drawers: Forestry Pack

6M Downloads

Compacting drawer issues with some mod blocks/ingots/nuggets.

MoxieGrrl opened this issue ยท 22 comments

commented

Certain metals are not showing their nuggets in Storage Drawers' compacting drawers when Project Red is installed.

2015-08-05_16 10 35

Copper, tin, and silver. I've been pulling my hair out for two days tracking this down. xD It also seems to be an ore dictionary issue as some mods' metals work and some do not.

2015-08-05_16 21 06

The Tinkers copper (first on the bottom left) works, but the TE copper (third on the bottom left) does not. Here's a link to a debug crash for modlist purposes.

(Also posted at Project Red tracker first and here for good measure.)

commented

Without ProjectRed : Without
With ProjectRed : With

Both Forestry ( if the signs werent clear enough )

REFERENCING : MrTJP/ProjectRed#908

commented

I don't think it's a ProjectRed issue, unless MrTJP finds something worth pointing out in my short description of the problem. It's happening with a variety of mods; not really sure why, or if any specific mod is responsible for how the recipe registry ends up.

I'm just going to need to reimplement some of the Forge stuff I'm using for this. Might be able to get to it next week; I'll be traveling for the rest of this week.

commented

Does anyone know an existing mod pack that demonstrates this issue? I gave Infinity a try without success, and I've never encountered it in other mod sets I've used. I'd like to get to the bottom of this without building a 100+ modpack by hand.

commented

Related: #123

In that instance, it's the top-tier blocks which are absent, which is interesting.

commented

If you need a modpack for testing that I'd advertise mine xD FTB Modpack code: SITL (271 mods)
You'd have to add storage drawers manually though. it is inlcuded in my dev-Version but I haven't uploaded the update yet and there the problem goes so far that actually NO conversion at all happens to ingots and blocks :D

commented

To be clear, you mean that the different tiers of nuggets/ingots/blocks don't appear? If it's ore dictionary equivalence not working, I have a pretty good understanding of that process.

commented

Yes I mean that if, for example I put Copper ingots into the compacting drawers neither copper blocks nor copper nuggets appear. The ingot is just hadled like I put in bedrock-the ingots are just placed in the upper middle. Vanilla stuff (iron etc.) and even the compacted cobblestone from Extra Utilities is working. It seems like the error happens when too many different types of one material (here: copper) are registered in the oreDictionary (I have 11 types of copper registered in the modpack :D )
(Info: one mod (Tubestuff) hasn't registered his copper blocks in the oreDict all else have)

commented

I thought Infinity was heavyweight but .. damn. I was eventually able to run it and see the issue, but it will probably be too unwieldy to work with. I wasn't able to get a successful recipe dump from minetweaker either.

commented

Wouldn't it be possible to, if ~ingot is put into a compacting drawer, search for ~block and ~nugget, localize everything that has that ~block or ~nugget oreDict entry and then search every version of that (every single item with that entry) for a recipe that allows a conversion. Then the mod uses the conversion that fits the most entries. (If its a 1:1 ratio between conversion and no conversion the mod takes conversion and if it's a 1:1 ratio between two different conversions it takes the conversion it first found)
(I hope it's understandable what I wrote)

Otherwise maybe something like a force-conversion config?
In the sheme: block-ingot;[number of ingots per block]-nugget;[number of nuggets per ingot]
That would at least allow modpack makers to fix non-existent conversions.

Or you could "hardcode" some conversions of more common materials (copper, tin, silver, platin, lead, ferrus/nickel etc. ) (can be disabled via config)

[Just some ideas I had]

For testing-it seems to happen once too many variants of one material are avaible...combining Thermal Foundation, Immersive Engineering, IC2, Tubestuff and AnotherOneBitesTheDust should be sufficient to reproduce the problem...

commented

The drawer already tries to find all valid candidates for an upper or lower tier and then picking one. What's not entirely clear to me yet is whether the Forge API for the recipe registry properly deals with ore dictionary components. It looks like it should, but I'm not certain.

I do support MineTweaker scripts to add the compacting tiers yourself. If you click the linked issue above, you'll see some example scripts. It's intended for pack makers to work around limitations within their own ore dictionaries and recipe registries.

commented

This is formally fixed in 1.5.13. If a given ore dictionary key was blacklisted, then associated recipes based on the ore dictionary key would fail. Since some mods register explicit recipes with their own items, some register with ore keys, and some don't register at all, it led to very unpredictable behavior.

Ore dictionary keys are more likely to become blacklisted as you add more mods, because they can create ambiguous conversion graphs or break some of the other rules that are meant to avoid accidental exploits.

The compacting drawers will no longer use strict matching for purposes of finding tiers, so it won't matter if those entries end up blacklisted. I've also whitelisted several common metals in nugget/ingot/block/ore form.

commented

This problem still exists as of 1.5.14.

commented

Got to the bottom of it. This is one of those bugs that falls into the "why did this ever work so well in the first place" bins. But surprisingly difficult to isolate.

Compacting drawers do a reverse recipe lookup to make sure objects will convert both ways, and that lookup was only checking the first recipe returned by the forge recipe registry, rather than considering all possible reverse recipes.

ProjectRed's block->ingot recipe must be registered very early, as it took precedence over everything, when a nuggets->ingot recipe was expected. Likely explains the similar issue raised specifically with ProjectRed, though it's not a PR issue.

The 1.5.13 fixes concentrated on ascending lookups, deriving blocks from ingots and ingots from nuggets, and in that case I did properly check all reverse recipes. Populating a drawer from a nugget thus did work correctly.

I'm not sure why your explicit compacting drawer registrations didn't work -- they should have. I didn't really prod the issue, but if you post your MT lines, it might be apparent why they failed.

Build 1.5.15 is published with the fix.

commented

(Before I go any further, I just want to state that I'm a novice modder but an experienced Java developer...as such, my usage of Forge may not be the best and it may even be the reason it didn't work for me)

My last attempt, and the one I honestly thought would work the best, is here: CandiceJoy@4f3a982

(I tried without the if statements to register ALL ingots of those types to nuggets, and that didn't do anything different than it did with the if statements; I should also note that there's a couple of very small artifacts from other attempts, unused imports and the like XD)

commented

That will give you a single arbitrary nugget recipe specifically against the projectRed objects, which is why it worked for projectRed and nothing else. The comp registry is strict in that sense.

The registry would normally be updated via MineTweaker scripts, and you can see some examples here: #123
But you'd need a registration for every kind of block and ingot that was not working.

Anyway, it should be unnecessary with the latest build.

commented

Can confirm this is fixed :)

http://screenshots.candicejoy.com/JMma

commented

At this point, I pretty much need your mod pack to investigate further.

commented

For the Love of Adventure on Curse.

commented

I played around with the code (registering the ingot -> nugget relationships to the Compaction Registry) and was able to get the ProjectRed versions of the ingots to work properly, but I never could get the others to work, even if I added them all to the registry. I also had to run the registration in post because ProjectRed adds their ores in init instead of preinit.

commented

The tier lookups are a very complex area and certain mods or interactions still throw me curve balls. I'm a little surprised the registration failed, and I guess that explains why the prior fix would do nothing.

commented

Yeah. I even tried disabling the unregister() calls in the register() method, tried doing the other ingots at preinit and projectred at post, both at post, etc...I really played around with it a lot. I got extremely frustrated and gave up :P

commented

I just came to this post via Google search, and I must say I'm having this issue in "Modern Skyblock 3: Departed" modpack, with Awakened Draconium nuggets. They keep just as nuggets, which is annoying because they take so much space in any logistical system... 8^/