[minor] Fluid pipes and Sheet Metal Tanks...

[theunkn0wn1]

When a pipe comes into contact with a silo, both from IE, regardless if the silo block is a valid input the pipe 'connects' to it. No fluids can be inserted into the silo this way, though is a graphical glitch.

The simple workaround is to hit the undesired inputs with the hammer though it is undesirable.

build 00ecb6b

[theunkn0wn1]

Not completely unrelated, they are on the same chapter in the book, my mistake. Yeah... because the construction between the Silos and the Sheet metal Tanks are separated by an extra layer or two of sheet metal blocks I call them close enough.

Edit: 0.o web interface glitch is glitchy

[BluSunrize]

Well IE is barely the only mod doing that. There is no true way for me to define an IFluidHandler as "don't connect"

As you can see, EIO, TD and BC all have the same 'issue'

[mindforger]

does every "te" of the multiblock have to be an IFluidHandler? Can't you just (while forming the multiblock) replace the "port"-tiles of the multiblock with a what_ever_machine_class-derived class that also implements the iFluidHandler to make just this one tile connecting?

[BluSunrize]

I am /not/ making multiblock sublclasses for separate elements of the MB. That is absolutely not worth the effort, and more importantly impossible to achieve when every multiblock only uses a single metadata. TileEntity's are chosen based on meta and this change alone would require the DieselGen to take up 3 metadata instead of one. Same goes for pretty much every other MB. So no, not happening, ever.

[mindforger]

okay, just was an idea :P

[cobra]

Just for fun, I added additional checks for IE's pipes. They now check canDrain and (technically or) canFill for IFluidHandlers, using null als fluid. That works perfectly with the sheetmetal tank and the other fluid machines of IE after slightly modifying their respective methods (they returned true for all positions before). I don't know about other mods though, that needs more testing.

[cobra]

off-topic: why can the refinery output fluid at the back, below the RF input?

[BluSunrize]

...it can? xD

Also, no calling canFill with null as a fluid isn't a very good idea, since certain machines might just return false on the account that the fluid is null I'd rather not take that risk. I'd rather have pipes to connect to useless things than not connect to necessary things.

[cobra]

I was wondering why it checked two pos values and yes, the back one works when pulling fluid.

I already thought of that, that's why I mentioned testing and did it only as proof-of-concept. One possible solution (didn't look into it yet) could be that pipes will only connect to IFluidHandlers returning true for null fluids by default (my branch), but can be hammered to connect to any IFluidHandler regardless of canDrain/canFill return value (master branch). There isn't a fluid wildcard value, is there?

[BluSunrize]

There isn't. And I don't like forcing the user to connect things. That always annoyed me on MFR's rednet wires. Things will stay as is for now until an intelligent solution has been found.

I'll tend to that refinery bug.

[cobra]

I fixed that refinery thing already and have some other tiny fixes.