Oredic module improvement

[Dijkstra1-zz]

If an oredic module is put into a pipe and it not configured it should try and match all of the oredic value in that inventory, or maybe be make it an upgrade from the polymorphic item sink

[hron84]

I don't think it makes sense. Oredic module is often used to sort items to ore processing setups, this means the content of the attached inventory become slowly (or faster) consumed, and this can cause a confusion - as this default behavior is not as obvious as you think. I can imagine an upgrade for polymorphic item sink module for make an oredic comparison too, not just full item matching, but making this behavior as a default for oredic module - that does not make any sense for me. Give me some examples how can it be useful and how do you want to make this behavior obvious for anyone.

For me, an unconfigured itemsink module should not route anything to itself until it become configured. Routing is a very complicated - and resource-hungry - thing and swinging a whole system with some insane behavior is definitely not an excellent idea. Adding a module to an existing system with this default behavior can cause two unneccessary routing upgrades (once when you attach it to a pipe and once when you configure it - ppl often configure modules after adding them to a chassi pipe). The current behavior is a bit more effective in resource for a price of small - but often unused thus unnoticed - comfort.

[Dijkstra1-zz]

Well, drawers and better barrels, will accept items of the same oredic value converting to the first one put it, and the drawer mods has drawer controller, which allows inserting and taking items out of all touching drawers, and depending on of ore get processed, you get diffented types of the same ingot e.g. ic2 copper ingot and TE copper ingot are the same ingot basic but using an polymorphic itemsink will only match to first one put in. So using an polymorphic oreskin would over come this (you do not need to call it polymorphic oreskin). So it would be unlikely to be used with ores but for storing ingot/blocks/nugget and other item such as sulphur in inventory that convert oredic types it would be very useful.

[hron84]

The main problem is how LP handles polymorphic sinks in this case. Even if an attached storage can do the oredic conversion, LP still not like to route items there, because it does not determine the routing based on trial-and-error, but it keeps its eye on the content and makes a simply equality check (this is what makes you feel LP system is "smart" in routing). I usually try to enforce only one type of ingots/gems as an output in my ore processing system, since it makes the routing much more easier.

The funniest part is this "dumbness" is about nothing but performance. Equality check is way cheaper than an oredic check, especially if a large inventory (like DSU-type stuffs or diamond chests) attached. Especially because polymorphic sink tries to route based on ALL content of the inventory, not just on a first stack. Imagine this on a diamond chest... or, worse, an AE2 interface. I feel the breath of a server freezes....

So, I would be very careful about it and maybe - just maybe - I would rather want to see an oredic converter block/pipe/module that converts the ingots based on the network content and very manual configuration.

[Dijkstra1-zz]

@hron84 I know what you mean about trying to processing all of the ore same way, but it is not always easy, especially when one ore give something extra of another metal and that is an different type to what you would have got from processing that ore, to tel you truth I do not care how it is implemented just as long as it does not take to much configure, and then when I upgrade, my ore processing system to an better one I do not need to change everything, because it would be a real pain change what ingots/nuggets/blocks are used in all of crafting tables.

[AEnterprise]

you have tinkers? you can always setup a large smeltery and hook that to the output of your ore processing so everything gets smelted and converted into ingots again ensuring they are all the same type when they come out

[Dijkstra1-zz]

@AEnterprise Yes would work but lava is a bit pricey at the moment, I just do not have the power gen to cope with lava gen and all that I am making, is being used to make obsidian

[hron84]

Mmmm.... smeltery.... source of nasty alloying issues. Nah. EnderIO has a config option to set ingot/dust preferences. So any dust you smelt will yield ingot from the previously selected mod, anyway. As almost all ore processing has a smelting as a last step, this is the best way to make constant yield.

[HadesDurin]

if you want to have all ingots of the same type ry the ore dictionary converter mod, route all ingots thru it and all get converted nicely, to sort it into the right barrel, chest, what ever then you can use a normal pipe and set it to accept one item type only. BTW you have only 4 or 5 types of ores to convert (Copper, Silver, Tin and Lead are mine)

[bziemons]

I think the cons beat the pros in this case.

Although the automatic detection of the ore dictionary entries would help in some cases, it could end terribly in others. Especially since no-one expects a module to configure itself. LP is not designed to be the most comfortable logistics systems out there and it never did auto-configure itself at any point. So I agree with #971 (comment).