Milling Balls are not outputed by ME export bus or storage bus

[Ngar1]

Your GTNH Discord Username

Ngar

Your Pack Version

2.3.

Your Server

myFTB

Java Version

Java 9

Type of Server

Thermos

Your Expectation

Export of alumina milling ball via ME into chest

The Reality

no balls will be put into chest (tested with mini chest, chest chestbuffer), enought available in ME. Export bus (export bus and Storage bus tested) was acive. Tested with and without crafting card.

Your Proposal

may be a NTB problem

Final Checklist

• [X] I have searched this issue tracker and there is nothing similar already. Posting on a closed issue saying the bug still exists will prompt us to investigate and reopen it once we confirm your report.
• [X] I can reproduce this problem consistently by follow the exact steps I described above, or this does not need reproducing, e.g. recipe loophole.
• [ ] I have asked other people and they confirm they also have this problem by follow the exact steps I described above, or this does not need reproducing, e.g. recipe loophole.

[repo-alt]

Can't reproduce in 2.3.3

[Tommeh1]

I can't get ME to handle them either, we're forced to use an assembler attached directly to the ball housings to push straight into the mills. It is possible to get ME to handle already crafted ones, but crafting on demand refuses to work.

[chochem]

can reproduce. it only works with milling balls from nei which have some nbt. freshly crafted once dont get exported unless you add a fuzzy card, dont know why ngar isnt doing that but still should be fixed.

self crafted:

NEI:

no matter which one I use to set the filter, only the nei variant gets exported. But yea the workaround is also very simple.

[Tommeh1]

Unless it has been fixed a fuzzy card still won't allow it to be made and exported by a crafting card.

[chochem]

a fuzzy card works. I tested it.

well for export bus, crafting card I dont know, maybe try yourself instead of guessing. Crafting cards arent really recommended in general I would say.

[Tommeh1]

a fuzzy card works. I tested it.

well for export bus, crafting card I dont know, maybe try yourself instead of guessing. Crafting cards arent really recommended in general I would say.

Given that all other Isamill related bugs i'm aware of still exist aside from it ignoring armor i don't expect that to have been fixed, and a crafting card makes a lot of sense here as you only want to keep the ball housing filled.

[repo-alt]

crafting card is ok exactly in the scenarios like this, when it is not called very often

[repo-alt]

All in all this is more like a GT++ bug, balls should probably be crafted with an NBT tag (but crafting+fuzzy card should still work, so maybe worth checking in AE2 too)

[repo-alt]

Just tested, fuzzy card + crafting card work fine. Perhaps you should set the pattern output not from NEI so that the assembler output would actually correspond to the pattern output, but anyway, it is not an AE problem.

[chochem]

so AE just adding nbt to it for the filtering is normal and intended?

[repo-alt]

AE does not add NBT, why? I mean, if the assembler does not produce the expected recipe output, the export bus may not "notice" that the ball is actually crafted, but it will probably "find" the ball the next time it will wake up, unless there is a flag set "export only crafted"

[chochem]

no. I tested it with the correct items (no nbt) already in the system. no crafting card or any of that.

[repo-alt]

Eh, not sure I understand

[chochem]

freshly crafted no nbt items in the system, use one of them to set the export filter: Does not export.

[chochem]

or (again) in more detail: have both the freshly crafted and the NEI cheated item in the system, use either(!) to set the filter: Will always only export the NEI cheated one. (meaning the filter added nbt to it or something like that when using the freshly crafted to set the filter)

[repo-alt]

It is not AE, it is GT unification. Assemnbler produces an item w/o nbt, but as soon as it gets in your inventory after a very short period it will get "unified" to the corresponding oredict item (if the unification is registered that is). This is usually done for all sorts of copper nuggets from all kind of mods but not only for them. Not sure why these balls are unified (to themselves?)

[chochem]

keeping them in my inventory for a longer time or throwing them on the ground and picking up again or similar stuff does absolutely nothing here. Also there is no difference between assembler->interface directly, or taking it out myself and then putting in the ae system.

This really seems to be an AE problem.

[repo-alt]

do "/mt hand" on a ball taken from the assembler, then wait a bit and do /mt hand again AE just cannot add nbt to some random items, there may be bugs in comparison, and that I did check for, but not like "import an item and change it", it's not really possible (or at least I'll be very surprized if it is).

[chochem]

As I already said: that does nothing.

[chochem]

If you continuously dont believe me or dont understand me for whatever reason, then you should really just test it yourself. its really simple.

[repo-alt]

I really tested that and I think I undersand all that is going on. I may be mistaken, but I don't see what I else I can do.

[chochem]

I guess nobody understands AE code at this point anymore. which is fair., I cant say I do.

[repo-alt]

Ok I tested it again and reproduced "something". It may be a bug in setting the filter but more probably it is a bug in a millig ball container item. Notice how when you have in you inventory the balls with and w/o NBT, when they stack - they stack to the item with an NBT. The same happens when you assign a filter. I guess I can add an additional check that the item container does not do weird shit when copying an item, but I think that the item container just should not do that.

[repo-alt]

Btw, EnderIO filter does the same as AE filter, which is another argument to not add the check to AE filter creation

[Ngar1]

Problem with fuzzy card solved