New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buildcraft Kinesis Pipe interaction with AE Energy Acceptors Part 2 #549

Closed
psxlover opened this Issue Dec 5, 2014 · 26 comments

Comments

Projects
None yet
3 participants
@psxlover

psxlover commented Dec 5, 2014

This is probably related to #524.
I'm using AE rv2-alpha-28. I'm seeing a similar issue with #524 when the pipe connecting to the Energy Acceptor is either Cobblestone or Stone Kinesis Pipe.
2014-12-05_07 05 08
It doesn't matter what pipes are in the network as long as the pipe connecting to the energy acceptor is either Cobblestone (80 RF/t) or Stone (160 RF/t).

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Dec 5, 2014

Member

works fine for me

2014-12-05_11 38 03

Member

thatsIch commented Dec 5, 2014

works fine for me

2014-12-05_11 38 03

@Cisien

This comment has been minimized.

Show comment
Hide comment
@Cisien

Cisien Dec 5, 2014

Contributor

What builds of buildcraft are being tested here? Could this simply be a rendering bug on their side?

Contributor

Cisien commented Dec 5, 2014

What builds of buildcraft are being tested here? Could this simply be a rendering bug on their side?

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Dec 5, 2014

Member

I used the latest 6.2.2 I think directly from their homepage.

Member

thatsIch commented Dec 5, 2014

I used the latest 6.2.2 I think directly from their homepage.

@psxlover

This comment has been minimized.

Show comment
Hide comment
@psxlover

psxlover Dec 5, 2014

When you say it's working fine, do you mean it stops transferring power when the energy cell fills? Cause in your screenshot it's still transferring power.
2014-12-05_20 31 49
I'm sorry if I didn't make myself clear, the problem is that it never stops sending power even when no power is needed in the AE network.

psxlover commented Dec 5, 2014

When you say it's working fine, do you mean it stops transferring power when the energy cell fills? Cause in your screenshot it's still transferring power.
2014-12-05_20 31 49
I'm sorry if I didn't make myself clear, the problem is that it never stops sending power even when no power is needed in the AE network.

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Dec 5, 2014

Member

Then thats not on our end. Isnt BC supposed to work like this?

Member

thatsIch commented Dec 5, 2014

Then thats not on our end. Isnt BC supposed to work like this?

@thatsIch thatsIch closed this Dec 5, 2014

@psxlover

This comment has been minimized.

Show comment
Hide comment
@psxlover

psxlover Dec 5, 2014

Work like what? Like I said it doesn't happen if the Energy Acceptor is connected to a different kind of pipe, e.g. if the pipe directly next to the Energy Acceptor is a Gold Kinetic Pipe.
I don't think buildcraft pipes are supposed to send any energy when it is not needed, let alone 40 RF/t.

psxlover commented Dec 5, 2014

Work like what? Like I said it doesn't happen if the Energy Acceptor is connected to a different kind of pipe, e.g. if the pipe directly next to the Energy Acceptor is a Gold Kinetic Pipe.
I don't think buildcraft pipes are supposed to send any energy when it is not needed, let alone 40 RF/t.

@psxlover

This comment has been minimized.

Show comment
Hide comment
@psxlover

psxlover Dec 5, 2014

It's 40 RF/t for the Stone Kinesis Pipe (which can transport 160 RF/t).
With a Cobblestone Kinesis Pipe it's wasting 80 RF/t which is the max it can transport.

psxlover commented Dec 5, 2014

It's 40 RF/t for the Stone Kinesis Pipe (which can transport 160 RF/t).
With a Cobblestone Kinesis Pipe it's wasting 80 RF/t which is the max it can transport.

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Dec 5, 2014

Member

We request the energy the network is missing + the drain per tick. So if the network is full, it will request 0 RF
if BC is doing things if the receiver does not need power, we have no jurisdiction over it

Member

thatsIch commented Dec 5, 2014

We request the energy the network is missing + the drain per tick. So if the network is full, it will request 0 RF
if BC is doing things if the receiver does not need power, we have no jurisdiction over it

@psxlover

This comment has been minimized.

Show comment
Hide comment
@psxlover

psxlover Dec 5, 2014

If you replace the Energy Acceptor with a pump, the pump will receive some power until it's internal buffer is full and then stop.

psxlover commented Dec 5, 2014

If you replace the Energy Acceptor with a pump, the pump will receive some power until it's internal buffer is full and then stop.

@thatsIch thatsIch reopened this Dec 5, 2014

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Dec 5, 2014

Member

I will take a look at it, might take a while

Member

thatsIch commented Dec 5, 2014

I will take a look at it, might take a while

@thatsIch

This comment has been minimized.

Show comment
Hide comment
Member

thatsIch commented Dec 5, 2014

@psxlover

This comment has been minimized.

Show comment
Hide comment
@psxlover

psxlover Dec 5, 2014

That seems to constantly use all the power it can get.

psxlover commented Dec 5, 2014

That seems to constantly use all the power it can get.

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Dec 5, 2014

Member

screenshot?

Member

thatsIch commented Dec 5, 2014

screenshot?

@psxlover

This comment has been minimized.

Show comment
Hide comment
@psxlover

psxlover commented Dec 5, 2014

2014-12-06_00 08 54
2014-12-06_00 09 02
2014-12-06_00 09 11

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Dec 5, 2014

Member

what does the GUI of the energy acceptor state

Member

thatsIch commented Dec 5, 2014

what does the GUI of the energy acceptor state

@psxlover

This comment has been minimized.

Show comment
Hide comment
@psxlover

psxlover Dec 5, 2014

Also it doesn't seem to use it:
2014-12-06_00 11 56

psxlover commented Dec 5, 2014

Also it doesn't seem to use it:
2014-12-06_00 11 56

@psxlover

This comment has been minimized.

Show comment
Hide comment
@psxlover

psxlover Dec 5, 2014

That one seems to be working fine. And the code seems easier to understand now. What was the logic behind those overflow variables before?

psxlover commented Dec 5, 2014

That one seems to be working fine. And the code seems easier to understand now. What was the logic behind those overflow variables before?

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Dec 5, 2014

Member

no clue lol

Member

thatsIch commented Dec 5, 2014

no clue lol

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Dec 5, 2014

Member

ok the idea behind this was, that since RF is implemented using integers, and AE uses internally doubles, you can get rounding issues if you perform lots of cycles. It basically was there to level the values

Member

thatsIch commented Dec 5, 2014

ok the idea behind this was, that since RF is implemented using integers, and AE uses internally doubles, you can get rounding issues if you perform lots of cycles. It basically was there to level the values

@psxlover

This comment has been minimized.

Show comment
Hide comment
@psxlover

psxlover Dec 5, 2014

You store the part after the . in an internal buffer right? Is that used in injectExternalPower()? Cause I don't see it anywhere else in the code.
Also shouldn't you return the lowOverflow back to the system? (usedRF -= lowOverflow;)

psxlover commented Dec 5, 2014

You store the part after the . in an internal buffer right? Is that used in injectExternalPower()? Cause I don't see it anywhere else in the code.
Also shouldn't you return the lowOverflow back to the system? (usedRF -= lowOverflow;)

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Dec 5, 2014

Member

actually.. lowOverflow should be < 1 all the time since I use the usedRF to inject. I need to step it through in the debugger.
So, no I should not need to use usedRF -= lowOverflow but rather kill line 38

Member

thatsIch commented Dec 5, 2014

actually.. lowOverflow should be < 1 all the time since I use the usedRF to inject. I need to step it through in the debugger.
So, no I should not need to use usedRF -= lowOverflow but rather kill line 38

@psxlover

This comment has been minimized.

Show comment
Hide comment
@psxlover

psxlover Dec 5, 2014

Indeed (I should have opened the file directly instead of trying to visualize it through two commits).

psxlover commented Dec 5, 2014

Indeed (I should have opened the file directly instead of trying to visualize it through two commits).

@psxlover

This comment has been minimized.

Show comment
Hide comment
@psxlover

psxlover Dec 5, 2014

Wait, there shouldn't be an overflow at all since you've already used the floor of getExternalPowerDemand(), unless if the demand can be less than you can inject, or if somehow someone else injects at the same time in which case the overflow could be anything (this shouldn't happen since block updates are not multithreaded, and if it happened the overflow would be the least of your concerns)

psxlover commented Dec 5, 2014

Wait, there shouldn't be an overflow at all since you've already used the floor of getExternalPowerDemand(), unless if the demand can be less than you can inject, or if somehow someone else injects at the same time in which case the overflow could be anything (this shouldn't happen since block updates are not multithreaded, and if it happened the overflow would be the least of your concerns)

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Dec 6, 2014

Member

yep, you are correct

Member

thatsIch commented Dec 6, 2014

yep, you are correct

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch Dec 6, 2014

Member

Newest PR should fix this

Member

thatsIch commented Dec 6, 2014

Newest PR should fix this

@thatsIch thatsIch closed this Dec 6, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment