Please use the search functionality before reporting an issue. Also take a look at the closed issues!

Issue description:

pretty much the title, im pretty sure its the logistical transporters fault because, any other item transportation (non-mek) seems to work flawlessly. i have to mention im using RS to autocraft items, so the input to buffer chest is not instant. im wondering if that is the issue and the pipe is unsure when the pressure chamber interface is closed for input and its then voiding the stuff

Steps to reproduce:

1.form a pressure chamber from PNC
2.try to input items into it with a buffer chest and logistical transporters
3.it will most likely void items when transferring bulk at a time,

Version (make sure you are on the latest version before reporting):

**Forge:32.0.108
**Mekanism:10.0.9
Other relevant version:
**Pneumaticraft:Repressurized : 2.2.0-29

If a (crash)log is relevant for this issue, link it here: (It's almost always relevant)

N/A

additional comments:

also, could this issue refinedmods/refinedstorage#2640 be anywhere related? feel like mekanism is to blame here as well, this is a case of stuff getting voided as well
P.S. idk how to link issues properly, my bad[ edit: nvm it linked properly]

this is my setup, and it definitely voids items

im sorry, it cant be set to the other mode, it will automatically go to the other mode after an item is put into it, thus its animation of closing gates, its supposedly to prevent air pressure leak, and works like an air lock

Could you maybe upload your setup somewhere? I tried reproducing it and it seems to move a stack of iron into the interface and then stop but I haven't really ever actually used PNC so I am not sure if I am maybe just missing a step. One thing that I did notice is that right clicking the pressure chamber doesn't show the items but viewing the interface's inventory with TOP's extended mode showed the items in there is it maybe that this is what is happening that made you think it is being voided?

so, ill try explaining. the pressure chamber interface has two modes, 1. it is open for input from outside 2. it closes input and pushes its buffer to the chamber. my issue happens when logistical transporters try to push different items at once into the interface and the interface closes for input to push its buffer to the chamber. hope its clear

TL;DR try pushing different items into the interface at once

in my case, ive tried this recipe through an RS autocrafting network, and it voids some items 100% of the time

I will try experimenting some then after setting it to the other mode.

So I managed to reproduce this but I don't think it has anything to do with Mekanism and is a bug in PNC. I stepped through a debugger and they are returning that they can accept the items and when I am looking at the GUI the items are arriving and then just vanishing once inside the pressure chamber interface.

ok ill relay it to PNC then :)

Think I'm going to have to throw this one back at Mekanism...

I put 2 redstone in a chest, basic logistical transporter from the chest to an input interface, and set it to pull. I also stuck an IDE watchpoint on the interface's insert() method, and I see this when the transporter inserts to the interface:

simulate=true, ticks = 2653935 open = 1.0
simulate=true, ticks = 2653944 open = 1.0
simulate=true, ticks = 2653946 open = 1.0
simulate=false, ticks = 2653954 open = 1.0
simulate=true, ticks = 2653955 open = 1.0
simulate=false, ticks = 2653965 open = 0.8734375

The last two lines there are critical: you test insertion (simulate=true) at tick 2653955 (which I verified allowed insertion), and then 10 ticks later actually perform the insertion. However, at that point the interface door has started to close (open=0.8734375) so the item is rejected by the interface.

If you're testing insertability with simulate=true, it's not valid to then perform the insertion 10 ticks later, since you cannot rely on insertability persisting across multiple ticks like that. The way the pressure interface works is that if no items have been inserted for 10 ticks, the input will start to close, and the output will start to open, releasing the items into the chamber (as @KrAzYGEEK32 pointed out, it's basically an airlock).

Bit of an update: I did manage to find the bug on our end (and locally have it fixed). I haven't committed it yet though as fixing it revealed an edge case that we don't handle as gracefully as I think we should and I want to try to come up with a more graceful solution to that edge case. I will make sure to include the fix for voiding in 10.0.10 even if I don't manage to come up with as graceful of a solution for pathing the failed items as I am going to try.

I am testing insertion with simulate true, and then inserting later with simulate false. The inserting with simulate false is still supposed to be able to gracefully say "no I am not able to have items get inserted" so we are not relying on if the simulation is still valid we only use the simulation to check if we should start sending in the first place. If our pipes then have inserting fail with simulate false they attempt to send the item back to the start.

But it does do that. My overridden insert() method is:

@Nonnull
@Override
public ItemStack insertItem(int slot, @Nonnull ItemStack stack, boolean simulate) {
       return inputProgress == MAX_PROGRESS && isValidItem(stack) ? super.insertItem(slot, stack, simulate) : stack;
}

i.e. if the interface door is fully open and the item is one that the interface will accept (based on known recipes), then carry out the superclass insertion method (which will go ahead and try to insert the item, simulated or otherwise), otherwise it will return the stack unchanged since nothing is inserted, as the contract for insert() states.

I augmented the previous debug output to show the stack being passed and returned:

stack=1 redstone, simulate=true, ticks = 2657968 open = 1.0
- return: 1 air
stack=1 redstone, simulate=true, ticks = 2657968 open = 1.0
- return: 1 air
stack=1 redstone, simulate=true, ticks = 2657977 open = 1.0
- return: 1 air
stack=1 redstone, simulate=true, ticks = 2657979 open = 1.0
- return: 1 air
stack=1 redstone, simulate=false, ticks = 2657987 open = 1.0
- return: 1 air
stack=1 redstone, simulate=true, ticks = 2657988 open = 1.0
- return: 1 air
stack=1 redstone, simulate=false, ticks = 2657998 open = 0.8734375
- return: 1 redstone

As you can see, on the final (non-simulated) insertion, I am indeed returning "1 redstone", because it cannot be inserted due to the closing door.

I will try to look into it a bit more again then, though that still doesn't quite explain why when I look at the interface it has redstone in it and then the redstone just disappears (and doesn't show up in the inventory of the pressure chamber when I interact with the pressure chamber directly instead of the interface). Unless it isn't meant to show up in that inventory? (I haven't really ever used PNC before)

the GUI of pressure chamber itself doesnt show anything in its inventory, but if you use the wall's glass variant the items should render inside the pressure chamber. (atleast thats what i think your question was :P), laso if items are inside the pressure chamber, the output interface can to toggled to output all items inside the chamber into an adjacent inventory

Items briefly stay in the interface's item handler, until (as mentioned earlier) the interface's inner door fully opens, at which point the items are pushed into the main chamber, which is an item handler in a separate tile entity. At that point, they're rendered in the chamber itself. The sequence of events is (where 2 redstone is being transferred from a chest via logistical transporter to the interface):

• Interface outer door 100% open, inner door 0% open
• First redstone is inserted from the logistical transporter, interface starts a countdown from 10 ticks since there is something in the inventory (adding another item within 10 ticks would reset the countdown)
• 11 ticks later, the second redstone is attempted to be inserted, but now the outer door is already closing, and the inner door is opening, so that item is rejected. The puzzle here is why it's vanishing and the logistical transporter doesn't get it back.
• Once inner door is fully open (time taken depends on speed upgrades in the interface), the interface's contents are moved into the pressure chamber proper, to be potentially crafted.

Items sitting in the interface are also rendered via a TER, but they don't stay there for very long.

I stepped through the Mek code a bit further after returning from the interface insert(), and I can see that TransitRequest#addToInventory() returns a TransitRequest.EMPTY response, presumably because nothing could be inserted - right?

Following that (at LogisticalTransporterBase:174) I can see rejected is an empty itemstack (because that's what TransitRequest.EMPTY.getRejected() returns) - shouldn't it contain "1 redstone" at this point? It could well be that I don't understand the code properly, but it looks like this code here:

if (rejected.isEmpty()) {
  TransporterManager.remove(getTileWorld(), stack);
  deletes.add(stackId);
  continue;
}

is setting the item up to be voided?

By the way @KrAzYGEEK32 an easy short term workaround is to use Elite or Ultimate tier logistical transporters, both of which can move a whole stack at a time, avoiding items arriving spread out. If everything arrives at once, there's no problem.

Ya I am currently looking at/trying to debug TransitRequest#addToInventory as it is possible at some point during one of the rewrites it stopped properly handling when nothing could be accepted. I just need to remind myself how TransitResponses actually work/what exactly they represent, given most of the response code was written by aidan.

By the way @KrAzYGEEK32 an easy short term workaround is to use Elite or Ultimate tier logistical transporters, both of which can move a whole stack at a time, avoiding items arriving spread out. If everything arrives at once, there's no problem.

For most of the crafts it is a solution, but crafts involving multiple items, like the rotor or transistors etc, it is unavoidable. Luckily other item transportations exist :p