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

Infinite power with Rotarycraft #1384

Closed
jeremiahwinsley opened this Issue May 3, 2015 · 14 comments

Comments

Projects
None yet
4 participants
@jeremiahwinsley
Contributor

jeremiahwinsley commented May 3, 2015

The Energy Acceptor and ME Controller can produce infinite power with no input.
I'm using version rv2.beta build 32 of AE2, and version v6f of RotaryCraft, in single player.
Steps to reproduce:

  • Place down an Energy Acceptor and a RotaryCraft power source.
  • Once the power is going into the Energy Acceptor, use a Screwdriver to rotate the RotaryCraft power source.
  • Now remove the RotaryCraft power source.
  • With a Network Tool, you should see the Energy Acceptor producing power by itself.
@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch May 3, 2015

Member

Sounds more like a RtC issue to me, waiting for Reika to respond, will test it later on eventually.

Member

thatsIch commented May 3, 2015

Sounds more like a RtC issue to me, waiting for Reika to respond, will test it later on eventually.

@yueh

This comment has been minimized.

Show comment
Hide comment
@yueh

yueh May 4, 2015

Member

The best idea is probably to throw the current implementation away and just use SimpleShaftPowerReceiver.

Member

yueh commented May 4, 2015

The best idea is probably to throw the current implementation away and just use SimpleShaftPowerReceiver.

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch May 4, 2015

Member

hardly applicable if you read the descripton and methods

Member

thatsIch commented May 4, 2015

hardly applicable if you read the descripton and methods

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch May 4, 2015

Member

cant look it up atm which is more appropiate since looking at github is just meh

Member

thatsIch commented May 4, 2015

cant look it up atm which is more appropiate since looking at github is just meh

@yueh

This comment has been minimized.

Show comment
Hide comment
@yueh

yueh May 4, 2015

Member

I think PowerAcceptor is not intended to by implemented directly. At least I would read the documentation so. So we still need to implement ShaftPowerReceiver and everything from ShaftMachine (even with PowerAcceptor).

SimpleShaftPowerReceiver is just the 'dump energy here' interface, without caring about torque and the other things (which is what we are currently doing).

Member

yueh commented May 4, 2015

I think PowerAcceptor is not intended to by implemented directly. At least I would read the documentation so. So we still need to implement ShaftPowerReceiver and everything from ShaftMachine (even with PowerAcceptor).

SimpleShaftPowerReceiver is just the 'dump energy here' interface, without caring about torque and the other things (which is what we are currently doing).

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch May 4, 2015

Member

Just tried it and RtC is not reacting like it used to be in v5, so I assume its a bug in RtC, neither is it disconnecting itself from the energy acceptor, nor is the industrial coil working in creative mode.

Member

thatsIch commented May 4, 2015

Just tried it and RtC is not reacting like it used to be in v5, so I assume its a bug in RtC, neither is it disconnecting itself from the energy acceptor, nor is the industrial coil working in creative mode.

@thatsIch thatsIch closed this May 4, 2015

@jeremiahwinsley

This comment has been minimized.

Show comment
Hide comment
@jeremiahwinsley

jeremiahwinsley May 4, 2015

Contributor

@thatsIch Have you taken this up with Reika, or should I post an issue on his tracker?

Contributor

jeremiahwinsley commented May 4, 2015

@thatsIch Have you taken this up with Reika, or should I post an issue on his tracker?

@thatsIch

This comment has been minimized.

Show comment
Hide comment
@thatsIch

thatsIch May 4, 2015

Member

@jeremiahwinsley I tried, but no response.

Member

thatsIch commented May 4, 2015

@jeremiahwinsley I tried, but no response.

@ReikaKalseki

This comment has been minimized.

Show comment
Hide comment
@ReikaKalseki

ReikaKalseki May 6, 2015

For one, last time I checked, AE is still using the version of the RC API from before I changed it (and informed the AE team) more than 7 months ago.

Two, you do not want SimpleShaftPowerReceiver, as per the javadoc:

unsuitable for actual machines due to the total lack of sensitivity to the amount of power

Three, the methods are called every tick both client and server side from the machine updateEntity(). Seeing as AE works with energy, not power, the only way you can have a "persistent" power source is by adding to the energy buffer yourself in your own tick, rather than letting the method add energy.

ReikaKalseki commented May 6, 2015

For one, last time I checked, AE is still using the version of the RC API from before I changed it (and informed the AE team) more than 7 months ago.

Two, you do not want SimpleShaftPowerReceiver, as per the javadoc:

unsuitable for actual machines due to the total lack of sensitivity to the amount of power

Three, the methods are called every tick both client and server side from the machine updateEntity(). Seeing as AE works with energy, not power, the only way you can have a "persistent" power source is by adding to the energy buffer yourself in your own tick, rather than letting the method add energy.

@yueh

This comment has been minimized.

Show comment
Hide comment
@yueh

yueh May 6, 2015

Member

I have mostly glanced at the API and only later realized that the SimpleShaftPowerReceiver is just a boolean. But it would be perfect for us, if it would just be a similar interface with a int power. All the other things (especially the render stuff) is not really needed for us.

The documentation did not say anything about being called once per tick.
It even looks more like a static system, which only recalculates when something changes and not necessarily once per tick. Which on itself would be quite nice to save performance, but sadly is not true and just recalculated every tick.

Member

yueh commented May 6, 2015

I have mostly glanced at the API and only later realized that the SimpleShaftPowerReceiver is just a boolean. But it would be perfect for us, if it would just be a similar interface with a int power. All the other things (especially the render stuff) is not really needed for us.

The documentation did not say anything about being called once per tick.
It even looks more like a static system, which only recalculates when something changes and not necessarily once per tick. Which on itself would be quite nice to save performance, but sadly is not true and just recalculated every tick.

@ReikaKalseki

This comment has been minimized.

Show comment
Hide comment
@ReikaKalseki

ReikaKalseki May 6, 2015

What you want is AdvancedShaftPowerReceiver, added in the update 7 months ago.

It also has the doc you claim does not exist:

Implement this instead of {@link ShaftPowerReceiver} for more advanced and dynamic control over the power reception capabilities of your machine. To use this, you must implement the methods as you see fit but also set the power to zero at the end of the tick, allowing for it to be set again if the machine remains powered or drop to zero if not. If your intent is purely to receive power for conversion purposes, you may be able to forgo this, instead just adding to the internal buffer each time addPower is called.

And on the method addPower(int torque, int omega, long power, ForgeDirection side) itself:

Called every tick to add power at a given torque and speed, to a given side. For a block receiving multiple inputs, standard RC behavior is to sum the torque of all the inputs at the highest speed and ignore all others (eg 512@32+256@256+64@256 = 320@256) Depending on the intended function and "in-universe" mechanics of your machine, you may choose to do this or do something else. For those using the mechanical power directly (as opposed to internal conversion into a more nebulous form), it is strongly recommended to use the RC summation procedure for the sake of consistency and realism.

ReikaKalseki commented May 6, 2015

What you want is AdvancedShaftPowerReceiver, added in the update 7 months ago.

It also has the doc you claim does not exist:

Implement this instead of {@link ShaftPowerReceiver} for more advanced and dynamic control over the power reception capabilities of your machine. To use this, you must implement the methods as you see fit but also set the power to zero at the end of the tick, allowing for it to be set again if the machine remains powered or drop to zero if not. If your intent is purely to receive power for conversion purposes, you may be able to forgo this, instead just adding to the internal buffer each time addPower is called.

And on the method addPower(int torque, int omega, long power, ForgeDirection side) itself:

Called every tick to add power at a given torque and speed, to a given side. For a block receiving multiple inputs, standard RC behavior is to sum the torque of all the inputs at the highest speed and ignore all others (eg 512@32+256@256+64@256 = 320@256) Depending on the intended function and "in-universe" mechanics of your machine, you may choose to do this or do something else. For those using the mechanical power directly (as opposed to internal conversion into a more nebulous form), it is strongly recommended to use the RC summation procedure for the sake of consistency and realism.

@yueh

This comment has been minimized.

Show comment
Hide comment
@yueh

yueh May 6, 2015

Member

Yes AdvancedShaftPowerReceiver documents it is ticked. But none of the others or that they need to be reset.

Member

yueh commented May 6, 2015

Yes AdvancedShaftPowerReceiver documents it is ticked. But none of the others or that they need to be reset.

@ReikaKalseki

This comment has been minimized.

Show comment
Hide comment
@ReikaKalseki

ReikaKalseki May 6, 2015

Depending on the implementation, they may or may not. For yours, as I said, they almost certainly do not.

ReikaKalseki commented May 6, 2015

Depending on the implementation, they may or may not. For yours, as I said, they almost certainly do not.

thatsIch added a commit that referenced this issue May 19, 2015

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