Minecraft Version 1.12.2

Forge Version 14.23.5.2768

Mod Version 0.8.2-288

Describe your problem, including steps to reproduce it

So while in my case it's GregTech CE's machines, I'm sure there are some other mods' machines that this happens with. The Omnidirectional Hopper doesn't start exporting immediately. Sometimes it starts exporting once the machine's output is full (which isn't practical in many cases), but sometimes it never does. Seeing that this does not happen with vanilla Hoppers or TE's Servos, I believe it's safe to say it's related to the Omnidirectional Hopper itself. (It also doesn't happen when exporting fluids with the Fluid Hopper, but that's different).

Any extra comments

This issue TheLimePixel/GregBlock#58 has some more information about it. (yes, I did replace the vanilla Hopper with the PnC:R one)

I can't reproduce this with vanilla or any other mods right now, and while I'd love to test GTCE with my dev instance, it just crashes it, which is a bit of a problem...

java.lang.NoSuchFieldError: block
	at gregtech.common.CommonProxy.modifyFuelBurnTime(CommonProxy.java:185)
	at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_357_CommonProxy_modifyFuelBurnTime_FurnaceFuelBurnTimeEvent.invoke(.dynamic)
	at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90)
	at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:182)
	at net.minecraftforge.event.ForgeEventFactory.getItemBurnTime(ForgeEventFactory.java:270)
	at net.minecraft.tileentity.TileEntityFurnace.getItemBurnTime(TileEntityFurnace.java:404)
	at crazypants.enderio.machines.machine.generator.stirling.TileStirlingGenerator.getBurnTimeGeneric(TileStirlingGenerator.java:130)
	at crazypants.enderio.machines.machine.generator.stirling.BlockStirlingGenerator$2.getBurnTime(BlockStirlingGenerator.java:114)
...

Works fine with (tested so far):

• Vanilla
• AE2 interfaces
• IC2 machines
• EnderIO machines
• Industrial Foregoing machines
• Storage Drawers

I actually did test the exact same mods. That's why I said "Certain Mods' Machines", as it's GTCE and surely some other mod that we wouldn't think about testing. Anyways, it's interesting that it crashes with EIO in the dev environment, but it doesn't crash in a Twitch instance.

I've seen problems like this before, some kind of obfuscation issue. Can be difficult to track down, but I can probably test with another world without EIO.

I got GTCE working with a test instance I use, but I have no clue how these machines are supposed to work. I thought a Basic Furnace beside a Diesel Generator would get powered, but no. Tried various GT cables too, no dice.

I did test with a GT Stainless Steel chest and the Omnihopper had no problem pulling from that.

OK, figured it out. Yeah, the omnihopper isn't pulling from below the Basic Furnace. I'll see if I can make this work in my dev instance so I can debug.

Oh, it does work, you just need to place it so the white dot is facing the machine. The generators output from only one side.

OK, got working in dev instance (disabled EIO for now). I can see what the problem is; GT presents the machine's whole inventory in the item handler object returned; both the input and output slot. The hopper tried to pull from the first slot of the item handler (the input slot), failed and gave up. This also explains why it sometimes worked - "sometimes" meaning "when the input slot was empty".

I've reworked the pulling algorithm a bit to fix that little problem, and the hopper now seems to be pulling reliably. Tested a couple of other scenarios too (including that one you mentioned on Discord a couple of weeks back) and all seems well. Would appreciate some more testing from you :) I'll be pushing this change in a moment, will be a new Jenkins build soon.

Build 297 will contain this fix (as well as a fix for a dumb Amadron GUI crash I introduced in 0.8.2).

Fixed in 0.8.3 release