Transferring fluids over pipes

[fr0st]

Here I am, again! Now that my pipe renders correctly, i feel better. But what's a pipe if it doesn't transfer liquids?

So basically, this is my TE class:

https://gist.github.com/anonymous/7139d767f5265af00c6f

 

As you can see, I'm able to suck liquids in by having a water block under the pipe (Just for testing). The problem is, the pipe will keep the liquid for itself and won't transfer it to nearby pipes. The thing I don't understand is, i coded the method to transfer liquids. As you can see it gets nearby pipes, increases their liquid level and decreases its one. THat's why I'm asking for help.

[fr0st]

I know someone might hate me but please, my mod NEEDS these pipes. I don't know whats wrong with them

[FlameAtronach93]

Help me to help you. What's that check good for:

 

pipeTile.getFluidLevel() > 0

(see https://gist.github.com/anonymous/7139d767f5265af00c6f#file-tileentitybasepipe-L52)

 

Doesn't that imply that your adjacent pipe must already contain a fluid in order to accept more fluid? Sounds counterproductive if you ask me.

Also, shouldn't you rather check pipeTile.canInjectFluid(f) instead of [this.]canInjectFluid(f) in the same line? Just in case you want to change behavior later...

 

If that's not it, how about providing some debugging information? What does it do once you reach that condition? (Step-by-step debugging?)

[fr0st]

I cannot believe how I did that. Eagle eye down there, man! Thats my problem in real life at school and at coding: I CAN'T FOCUS. I always make this kind of little errors. Let's see if i change it what it does.

 

Thanks for even having bothered reading my crappy code

[fr0st]

Alright so now i updated the code. This is what the pipe is doing:

 

Hmm i found another pipe, let's connect to it. Done. So now we should transfer our liquids into it.. Nah! Let's keep the liquid for me

 

It's like the pipe finds himself instead of other ones so the process is handled by the single pipe itself, and it does nothing.

 

Updated code with prints for debugging: (It doesnt even print the first one so it's like it's stuck to itself instead of checking other directions too)

https://gist.github.com/anonymous/aa0643cd94e825e470c2

[Glenn]

I highly recommend debugging. It has helped me so much with complicated block mechanisms, such as gas flow and gas piping.

[fr0st]

I can only imagine the pain you've been through.. using only the block class to make gas flow..

 

By the way i have my idea on why it doesn't work. As i already stated, the block SHOULD check for every direction (for(ForgeDirection dir : ForgeDirection.VALID_DIRECTIONS) and that's ok, but instead of cycling all of them, it stops on the first one (itself) and doesn't do anything...

[FlameAtronach93]

I have to say I never used ForgeDirection.VALID_DIRECTIONS. Instead I used ForgeDirection.values() and skipped over ForgeDirection.UNKNOWN... which has all offsets set to 0 = this block. Thanks for that though.

 

Back to your problem. Since your loop does not feature any exit conditions, there are only two possible answers to why your loop could possibly end before all 6 "rounds" have been completed. To confirm, do some more logging... but unconditional, just to refresh your basic counting skills.

One of these reasons ist that Forge.VALID_DIRECTIONS doesn't contain all valid directions in the first place, which would be total non-sense and thus the idea is trashed.

The second answer would be that you have an uncaught exception causing your method to terminate. But I guess you'd notice that one, unless you have somewhere an ingeniusly placed try {} catch (Exception ex) {} wrapper in your base code...

 

Given all this, we'd need more information on what happens internally. Do some real debugging...

 

By the way, when we say "Debugging", we're not talking about printing messages to the console. Of course that too is a technique in debugging, but is more useful to quickly check where the malfunctioning occurs: before or after the logged message. At least that's how I use it when pb]actively[/b] debugging.

Instead Eclipse grants you the ability to walk through your code step by step or - even better - set breakpoints at which you want Minecraft to interrupt in order to go through only specific parts of your code. Whilst debugging Eclipse shows you the values of variables and allows you to evaluate code under the current conditions (i.e. return value of methods using current values of parameters). It's a highly useful feature and just invaluable to solving such problems.

[fr0st]

OK so i started debugging seriously with breakpoints. I saw that the code gets stuck on

int d2 = y + dir.offsetY;

I really don't know what's the problem. IN this moment dir.offsetY equals -1 so under the pipe.. i really don't know, maybe I should code it from scratch.

 

Some further debugging had me discover that it checks for the directions actually but it's like it doesnt find any pipe. I know this because i tried to make it set blocks around it at the directions it should check, and since it doesnt replace itself, i know that it doesnt check for itself. At least a problem solved. Now i still need to realize if it doesnt find pipes or it can't inject water in them. To discover this it's simple.

 

Btw guys i'm very glad you keep heling me. My english is not that good and my java skills aren't either, I'm learning.

 

Thanks for helping this stupid 14yrs old boy