Arcanox

5 hours ago, XyFreak said:

It's been a WHILE - but it is finally time...

Big Reactors Grid Control Version 4.2.6 has been released!

Changelogs:

 - Greatly reduced the number of API calls for setting reactor fuel rod levels.
 - Fixed a bug where the reactor controller would miscalculate the fuel rod offsets with sub 1% precision.
 - Fixed a bug where the grid controller would not set the reactors output rate to the optimum but leave it as is when coming out of "HOLDING CHARGE" mode.
 - Partially rewrote calibration code for reactors to remove "magic values".
 - The Tabs for "Reactors" and "Turbines" will be omitted if there's not enough space for them (only calculated on GUI startup).
 - Fixed GUI resolution misbehaving on T2 screen setups. The colors are still off due to colorspace limitations on those screens.
 - Fixed grid UI for very slim screen setups. Try a sexy 3x1 T3 screen setup!
 - Added experimental support for mekanism induction matrix. J -> RF conversion ratios can be set in mekanism config.
   Conversion ratios other than 5:2 (J:RF) will confuse the controller.
   The ratio for the induction matrix can be changed in /usr/lib/brgc/energy_storage_component.lua
 - Added support for thermal expansion energy cells.

In order to upgrade from previous versions, you just need to run the installer again.

If you've used BRGC with any ER version between 0.4.5.40 and 0.4.5.45 you might want to upgrade to 0.4.5.46 now and remove your brgc configuration afterwards to recalibrate your setups.

I've changed some of the calibration code for reactors so those might calibrate a lot slower. If you feel calibration does not terminate, please send me a schematics of your reactor.

Also... I can't stress enough how sexy this looks:

It's pure coincidence the spacing works out so well too

I just updated BRGC and now it won't start my reactor. I did delete the /etc/br_control.cfg file before starting the services again. Every time I try and turn the reactor on, it just immediately goes to the "ERROR" state without heating up the reactor at all. It didn't re-create the /etc/br_control.cfg file at all.

EDIT: Apparently something really screwed up with my power system while updating and the P2P nodes weren't getting power, so the reactor filled up with steam. Fixed now.

8 hours ago, ZeroNoRyouki said:

Hi,

I've just posted and updated version of ER on Curse (It's under review right now). All the Callbacks are back to the old-direct-call-we-dont-care-about-threads-because-who-knows way of the original code. You must break and replace all your computer ports to see this in action

Z

Put this on my server and it works great! My computer is buttery smooth with all three BRGC programs and the GUI running. Thank you so much!

10 minutes ago, payonel said:

The list of versions affected show both good and bad for oc 1.6 and 1.7, while ER >= 0.4.5.41 (thus, including 44) is bad in both cases

So from that list alone it seems to be an issue with ER, and not a regression in oc 1.6 -> 1.7

Also, I had not realized the event handling delay with keyboard hits was so intense. Curious, when that is occurring, is the cursor blinking normally? (.5 second blink)

-edit-

It isn't by design to have such a delay in typing. The delay by design is to limit the number of direct api calls you can make within a tick

 

I don't believe the cursor blinks at its normal rate; I would have to check after work to be sure, but if I recall correctly, it blinks much slower (it appears to not blink at all because it is so slow).

I didn't figure it was by design to have such a large delay; I can understand only being able to make 20 or 10 or maybe even 5 API calls per tick, but the restriction seems to be effectively "less than one" per tick, judging by the way BRGC runs. I would at least expect BRGC to be able to acquire the energy/steam produced last tick once a tick, and reactor core temperature, and turbine RPM at least once every couple ticks without the computer being slowed down. 

31 minutes ago, payonel said:

I've read the entire post. I've read your review of the system yielding longer than you'd like, but I haven't read about a yield bug.

Read my response to this github ticket: https://github.com/MightyPirates/OpenComputers/issues/2632

Is there something I'm missing?

It is certainly a bug, because it was introduced in a recent version of OpenComputers. This has not always been the case. The post here details which versions of OC/ER are affected by the bug.

Not all mods' APIs are affected; certain other mods return nearly instantly from API calls (such as Draconic Evolution) and there can be multiple API calls per tick without slowing down the computer to any noticeable extent. Extreme Reactors is one of the mods affected, however, and when running this program with any number of ER devices attached, the computer is slowed down to the point where typing characters into the shell can take upwards of 5 seconds per character (that is not an exaggeration). I can't possibly see how that could be by-design, especially since it just started happening since a particular version of ER and OC.

1 hour ago, Ghan said:

I suspect your turbine is built incorrectly in that case. It sounds like you have too many turbine blades to support the coils you're using. IIRC, the program will basically push the turbine to the floor and run it as fast as it can during the calibration. It only will decrease the steam flow rate once it has calibrated against the maximum energy production possible. If the calibration causes it to go overspeed, then the program stops and errors out, as you see. So you should either reduce the number of turbine blades to bring it more in line with the coil(s) you're using, or add more coils to slow down the rotation.

Ah, I will play around with it later today. I didn't know it tried to calibrate with max efficient steam flow...the turbine program I wrote a long time ago just used a PI loop on the steam flow to keep it at 1800 RPM.

I'm experimenting around in creative mode with this because I'd like to eventually run it on my server, but I can't get the turbine control working. When I start the computer, it starts spinning up the turbine (KICKOFF mode), but once it reaches the CALIBRATING stage, it doesn't seem to be adjusting the steam flow rate at all, so it keeps spinning up until it hits the ERROR state. The Target RPM is displayed as "0" and the steam flow rate stays at 600 after it reaches CALIBRATING stage, never decreasing to stabilize the RPM. I'm guessing I'm doing something wrong with setup, but I have no idea what.