Mekanism/XU Compatibility Issue

[Former user]

Firstly, Mekanism machine output to a storage will insert whatever the output is and change the item inside to whatever that output is.

Here's a relevant Imgur album of me discovering this with a Crusher that I usually have tasked to produce Bio Fuel but wanted to quickly grab some gravel from. Luckily I could change it right back, but that was quite the WTF moment. I tried inserting via ExU transport, but couldn't do it that way. I also put a 1x1 storage drawer in the same position without this being an issue, hence my confidence in narrowing it down to the RR storage.

...and while testing that I found that the ExtraUtils node with a stack upgrade will just infinitely grab and send stuff from a Router Reborn storage if you have a locked storage at 1 quantity and you then increment it, but only to <64, then it'll pull that quantity -1 infinitely without decrementing. Once you pop it above 64 it clears properly, though.

[Tom Erik Voll]

this i belive is already fixed in 1.2.0.20-BETA-2 I will do some extra testing on that to make sure, but i changed some code in the units to prevent that in the beta

[Tom Erik Voll]

k, looked at the code, extra utilities grabbing infinite items could be caused by me allowing extraction when stack size is 1 and it is locked, i will change that, also a small error in the code when a block ask if a item is valid for the slot causing a convertion when it should not, i will get those fixed and release a update in the beta build, It will stay beta for now until i know all bugs are cleaned out, or until no bugs have surfaced for a while i will include these fixes in 1.2.0.20-Beta-3.

[Tom Erik Voll]

Fix #24

→ <<cset 0d0520de7fda>>

[Tom Erik Voll]

keeping it open in case there is still a issue

[Tom Erik Voll]

"I found that the ExtraUtils node with a stack upgrade will just infinitely grab and send stuff from a Router Reborn storage if you have a locked storage at 1 quantity and you then increment it, but only to <64, then it'll pull that quantity -1 infinitely without decrementing. Once you pop it above 64 it clears properly, though."

Im not able to duplicate this, i added a transfer node locked a unit ,extracted all but 1 item ,added 32 items, it extract 32 and leave 1 item.

[Tom Erik Voll]

and im a idiot cause i tested that after i fixed the code, if youcan comfirm the duplication is fixed in beta-3 i will close the thread

[Vauthil]

Hi there, the above report was a copy-paste of a message I'd sent to the FTB team on this so I figured I'd just respond directly here rather than force them to play telephone. =)

I've updated my instance with the new beta (which is a Horizons: Daybreaker pack, pack version 1.0.2, with the BETA-3 pulled from CurseForge for the test) and still appear to have both issues.

The XU issue only occurs with the Stack Upgrade in use on the transfer node. It empties down to 1 once the upgrade is removed.

The item change issue also still persists, and to really hammer into it I tested with a couple other Mekanism factories doing Auto-Eject into the barrel and the products of all of them made the contents change.

Also, maybe not relevant, but this is tested in SMP.

[Vauthil]

Also, since I had a bit of time and to try and limit the possibility of interaction errors from non-related mods, I just did an SSP test of the setup using an extremely pruned mod list (RR, Mekanism's three mods, ExU, CCC, NEI, InvTweaks, Mantle). Still happening for me.

[Vauthil]

A few more things that may be overkill of me to report, but I figured may narrow things down a bit more:

On the item conversion thing:

• In my test instance I threw in EnderIO and Thermal Expansion and tried both of their side ejection methods from their machines. Neither one of them has this issue, so there's perhaps something going on with Mekanism's eject method?

• Just to be thorough, I updated Mekanism to the latest on the jenkins (246; Horizons ships with 231). It still does it.

On the ExU node thing:

• The node will keep pulling as long as there's a valid destination for the item to end up at. Otherwise it'll pull twice and stop at that (so if I have 2 of something in the barrel it'll pull 1 item twice and have 2 in the node's buffer and then stop).

• The destination isn't picky as long as there is one accepting; it did this behavior with the other machines and even from one storage unit to another.

• Once it starts pulling like this, you can throw in more stuff and it'll pull up to a full stack and just keep going.

• This seems to only trigger if there's a valid single-hop destination for the node, but it will carry over to other further destinations once it has begun if the original single-hop destination fills up.

This may just be annoying trivia, but that's the info I have from the past half hour of poking at permutations, in case any of it is helpful.

[Tom Erik Voll]

Think i got it sorted now, Beta-4, i had a typy in a if statement single '=' instead of '==' setting it to approved instead of checking it lol, seems to be fixed for me now,

[Tom Erik Voll]

shuld be up on curse as soon as it get approved

[Vauthil]

Tested BETA-4, looks like it checks out against all of my test scenarios. Huzzah! Thank you very much for the quick turnaround on this! =)

[Tom Erik Voll]

np :)

[Tom Erik Voll]

Fixed in 1.2.0.20-Beta-4