Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal
XyFreak

Big Reactors Grid Control

Recommended Posts

@XyFreak

16 hours ago, XyFreak said:

Big Reactors Grid Control Version 4.3.2 has been released!

Changelog:


 - Removed dependency on OpenOS "threads" library. This means BRGC should world with OpenOS 1.6 again.
 - Implemented workaround for a bug with OpenComputers and Extreme Reactors when using Lua 5.3.
 - Fixed a bug that would sometimes flash an error message when done calibrating multiple reactors at once.

 

... Sorry it took me so long... erm.. I have no excuses for delaying this until now!

@Luke Brehm Can you try upgrading? I'm guessing you're running into a bug I implemented a workaround for (changelog #2). If that DOES work for you I suggest setting your CPU to Lua 5.2 mode regardless as BRGC will fall back to the old ER API if it detects issues with that. The new API is far more efficient tho... :/

I hope the removal of the "threads" library dependency makes some of you happy :P

Switching to LUA 5.2 worked. For anyone wondering you take the actual CPU out of the computer and shift+right click it while its in hand. 

Share this post


Link to post
Share on other sites
18 hours ago, XyFreak said:

bug with OpenComputers and Extreme Reactors when using Lua 5.3.

what bug?

Share this post


Link to post
Share on other sites

@payonel

With OC on linux servers and using Lua5.3, calling setControlRodsLevels on any reactor will cause the function to return

nil, "something something luanj something" (I think it was luanj but i'm not 100% sure right now)

I was unable to reproduce this issue on windows but it does happen on pretty much any server running linux. Normally I'd say: "Yep, ER bug!" but since it looks like it's OS dependent I'm not 100% sure... now that I'm writing about it... it might be JRE dependent....

Anyways - the function in question takes an array/table with keys starting at 0 instead of 1. There is also getControlRodsLevels which returns a table you can pass to setControlRodsLevels. Doing so is the easiest way to trigger the issue on any reactor.

Share this post


Link to post
Share on other sites

Hello not sure if this has been discussed yet. Im looking to get your program to auto start on its own every time my server restarts. i am new to all of this and have no idea how to do that. If someone could explain in detial to me or send me to a youtube tutorial that would be great, as i have not been able to find anything helpful in hours.

Share this post


Link to post
Share on other sites
1 hour ago, XyFreak said:

With OC on linux servers and using Lua5.3, calling setControlRodsLevels on any reactor will cause the function to return

I think you are using this on the br_reactor, yes? I found the br code for that here: https://github.com/ZeroNoRyouki/BigReactors/blob/master/src/main/java/erogenousbeef/bigreactors/common/multiblock/tileentity/TileEntityReactorComputerPort.java

Strangely, there is no setControlRodsLevels method on that component. There is a setAllControlRodLevels. I searched the commit history on the component and there never was a setControlRodsLevels, nor a get*. I also checked the original BR code, same story there. So I"m confused what method this was calling. Searching the entire code base of ER also came up empty. Is @ZeroNoRyouki available to discuss this?

 

1 hour ago, XyFreak said:

the function in question takes an array/table with keys starting at 0 instead of 1. There is also getControlRodsLevels which returns a table you can pass to setControlRodsLevels. Doing so is the easiest way to trigger the issue on any reactor

I'd be happy to test this and review the related ER code, but as I stated above, I couldn't trace it.

Thanks

@Sindor Nex

I'm quoting from that page I linked you: "Don't forget to add brgc_reactor, brgc_turbine and brgc_grid to your /etc/rc.cfg if you want to start the controller at boot time:"

If that sounds like what you asked for:

9 minutes ago, Sindor Nex said:

Im looking to get your program to auto start on its own every time my server restarts

Then read more of that page: https://tenyx.de/brgc/index.html#setup

 

If that isn't what you're asking for, you'll need to explain yourself a bit more.

Share this post


Link to post
Share on other sites

the only thing that link tells me is how to manually start the program myself... I want a way for it to be autorun without me inputting the start lines everytime the server restarts.

 

Sorry i do see to add it to /etc/rc.cfg but i still do not know how to that.

Share this post


Link to post
Share on other sites

You need to read that whole page I linked. It literally tells you how to do that.

13 minutes ago, payonel said:

I'm quoting from that page I linked you: "Don't forget to add brgc_reactor, brgc_turbine and brgc_grid to your /etc/rc.cfg if you want to start the controller at boot time:"

That is what I said to you in my last post. Again, "if you want to start the controller at boot time"

"start at boot time" IS literally what you are asking for, for it to "autorun"

also, if you want more information about autorunning programs on OpenOS in general, read this: https://ocdoc.cil.li/tutorial:autorun_options

But that covers all of the options, and is not specific to this program nor the service that XyFreak made for it

Share this post


Link to post
Share on other sites

@Sindor Nex

rc brgc_reactor enable
rc brgc_turbine enable
rc brgc_grid enable

(taken from the page)

I did not implement anything to start up the GUI on boot (that's propably what you're looking for). I think a hacky version of what you want is somewhere in this thread.

Share this post


Link to post
Share on other sites

Sorry i havent slept in over 24 hours so it just wasnt clicking in for me.... sorry for all the trouble and thanks.

Yes i was also looking for a way yo auto start the gui as well.

Share this post


Link to post
Share on other sites

in the more recent versions of OC (check out the dev builds for 1.7.10 and 1.10, I haven't merged up to 1.11 and 1.12 with all of these fixes as of this writing, but will "soon") it is safe/reliable to run gui programs from your .shrc

the gui program for brgc is `brgc_gui`, so this should be sufficient to run the gui at start up

echo brgc_gui >> /home/.shrc

 

though this will probably work just fine in the version you are running, try it out. update if you have issues

Share this post


Link to post
Share on other sites
15 hours ago, payonel said:

in the more recent versions of OC (check out the dev builds for 1.7.10 and 1.10, I haven't merged up to 1.11 and 1.12 with all of these fixes as of this writing, but will "soon") it is safe/reliable to run gui programs from your .shrc

the gui program for brgc is `brgc_gui`, so this should be sufficient to run the gui at start up

echo brgc_gui >> /home/.shrc

 

though this will probably work just fine in the version you are running, try it out. update if you have issues

Thanks will give it a shot. 

@XyFreak So i notice that you have a extra button called grid on the passive reactor screen. Was just wondering what it does differently compared to the other options as it is not listed in the opening post.

Share this post


Link to post
Share on other sites

@Sindor Nex

Grid mode means everything is coupled together using the grid controller. In order for that mode to work you need to connect your energy storage to the computer.

With everything hooked up the controller will attempt to make energy production as efficient as possible:

energy potential = max energy production possible by all connected generators

optimal energy potential = max energy production possible by all connected generators running at their efficiency peak

 

If your current energy consumption is less or equal than your optimal energy potential, then:

  • storage < 20% -> Enable just enough components so that there is a net energy gain
  • storage >90% -> Disable just enough components so that there is a small energy loss

If your current energy consumption is larger than your optimal energy optential but less than your energy potential, then:

  • Enable everything and put passive reactors in LOAD mode so that energy production = energy consumption

If your current energy consumption is larger than your energy potential, then:

  • Everything at full blast!

 

The metric that decides what to do is based on a weighted running average on the current energy consumption. The weight itself is based on your energy storage fill level:

  • Higher levels -> metric decreases slower, but increases faster
  • Lower levels -> metric decreases faster, but increases slower
  • 50% = equilibrium ;)

That way power spikes don't cause the controller to go haywire on high energy levels but keeps it responsive on lower levels to prevent blackouts.

The components that are turned on for the <= opt energy pot. is as follows:

  • Any turbine has priority over a passive reactor
  • Passive reactors are sorted by their fuel efficiency and then turned on from most efficient -> least efficient

 

That about sums it up. Basically you WANT to use grid mode whenever possible. Its the smart way to use BRGC ;)

The logic that was responsible for controlling turbines before the grid controller is gone btw. Yes the grid controller requires you to hook up your energy storage, but it does a MUCH better job than the previous logic that relied on the turbines internal energy storage. You can still run turbines without it but they'll not cooperate. Independent mode on turbines will also remove the turbine from the grid controller.

Share this post


Link to post
Share on other sites

Kinda. But what if you can't connect energy storage blocks? E.g. you don't have computronics installed? Or maybe you don't want to connect more cables? I don't see any reason to remove it.

Also the AUTO logic will take over for a particular component whenever that component actually fills with energy itself (aka you wired something wrong - your conduits are too weak). I that case the logic self throttles everything.

The only thing I COULD remove would be the button - but why prevent ppl from using stuff that has to be there anyways and can be used at any time?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.