Skip to content
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
Closed

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

psxlover opened this issue Dec 5, 2014 · 26 comments

Comments

@psxlover
Copy link

@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
Copy link
Member

@thatsIch thatsIch commented Dec 5, 2014

works fine for me

2014-12-05_11 38 03

@Cisien
Copy link
Contributor

@Cisien Cisien commented Dec 5, 2014

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

@thatsIch
Copy link
Member

@thatsIch thatsIch commented Dec 5, 2014

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

@psxlover
Copy link
Author

@psxlover 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
Copy link
Member

@thatsIch 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
Copy link
Author

@psxlover 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
Copy link
Author

@psxlover 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
Copy link
Member

@thatsIch 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
Copy link
Author

@psxlover 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
Copy link
Member

@thatsIch thatsIch commented Dec 5, 2014

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

@thatsIch
Copy link
Member

@thatsIch thatsIch commented Dec 5, 2014

@psxlover
Copy link
Author

@psxlover psxlover commented Dec 5, 2014

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

@thatsIch
Copy link
Member

@thatsIch thatsIch commented Dec 5, 2014

screenshot?

@psxlover
Copy link
Author

@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
Copy link
Member

@thatsIch thatsIch commented Dec 5, 2014

what does the GUI of the energy acceptor state

@psxlover
Copy link
Author

@psxlover psxlover commented Dec 5, 2014

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

@psxlover
Copy link
Author

@psxlover 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
Copy link
Member

@thatsIch thatsIch commented Dec 5, 2014

no clue lol

@thatsIch
Copy link
Member

@thatsIch 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
Copy link
Author

@psxlover 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
Copy link
Member

@thatsIch 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
Copy link
Author

@psxlover psxlover commented Dec 5, 2014

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

@psxlover
Copy link
Author

@psxlover 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
Copy link
Member

@thatsIch thatsIch commented Dec 6, 2014

yep, you are correct

@thatsIch
Copy link
Member

@thatsIch thatsIch commented Dec 6, 2014

Newest PR should fix this

@thatsIch thatsIch closed this Dec 6, 2014
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.