Pretty simple- the liquid unloader is setting the gates.trigger.work trigger as true, even when the cart above doesn't have a tank at all. I've applied filters (both the bucket filter and the cart filter) to the liquid unloader, but the trigger remains active. The cart above is an anchor cart by the way..

I suspect that the item unloader might have a similar issue with a tank cart as well, but I haven't tested it.. Does it require an advanced BC gate and a parameter to actually tell it not to set?

In the current implementation, hasWork() simple returns hasMinecart(). This is true for all loaders.

I'm open to alternative implementations.

hasMinecart() && minecart.canFillMe()?

Basically, I think it should behave like the Empty selection in the GUI itself.. maybe add a new action "canEmpty"?

Hmm...I just discovered that the Fluid Loader/Unloader actually override hasWork() to be:

    public boolean hasWork() {
        return flow > 0 && hasMinecart();
    }

Which I would think not result in the behavior you have described if it was working properly.

scratches head

Looks like maybe flow isn't being reset soon enough, so it only resets if there is cart that can actually be loaded sitting on top.

My expectation is that the "work" condition would actually indicate both: there is work to be done with the cart above, and that this work can actually complete. For example, I wouldn't expect it to be true if the cart doesn't match the filters on the unloader..

Filters are easy, "this work can actually complete" is hard.

Does hasWork() need to be true even before filling begins? For example while the pipe is extending?

Related to #466 ?
Source here:
https://github.com/CovertJaguar/Railcraft/blob/master/src/main/java/mods/railcraft/common/blocks/machine/gamma/TileLoaderFluidBase.java#L73-76

No, I'm pretty sure that was caused by a RemoteIO core mod breaking Redstone.

Part of the problem is that 'flow' is only reset when another fill operation is performed. It will retain the last value indefinitely otherwise. But even if I fix that, I'm not sure it would have the behavior you need. For example 'filling' can't actually start until the pipe is extended.

My expectation is that it would behave like the "Empty" or "Fill" tasks from the UI

I would expect the haswork action (or some bc action) to follow the redstone signal (in reverse) generated by the "Empty" or "Fill completely (?)" action.

I think the code in
https://github.com/CovertJaguar/Railcraft/blob/2b29dde6878d5f038950f77e6e10c6a7c61a165c/src/main/java/mods/railcraft/common/blocks/machine/gamma/TileFluidUnloader.java#L158
should be moved to around Line 100. Because the line
https://github.com/CovertJaguar/Railcraft/blob/2b29dde6878d5f038950f77e6e10c6a7c61a165c/src/main/java/mods/railcraft/common/blocks/machine/gamma/TileFluidUnloader.java#L132
doesn't make the flow zero, so if the flow is not zero at start, I think it will be marked "has work". If the flow is cleared after last use, then my opinion is 100% wrong.

Is asking whether the cart can be interacted with sufficient? Or do you also care about whether there is any action that actually needs to be performed?

I also would expect hasWork to behave like the redstone output (inverted). i.e. hasWork is true as long as the (un)loader would keep the minecart from moving on.

Might be tricky to come up with a good behavior for manual mode though.

That's the general idea yes.

Closed by 0897218