XyFreak

It's a bug in the command line tool specifically.. though I was pretty sure i fixed this ages ago... You CAN "fix" this by going into Lua 5.2 mode but that's something i need to fix tbh.

Thanks

Well the most important question is: WHY did it go critical?

Did the energy saturation fall below acceptable levels? (= FluxGate malfunction)

Did the containment just straight up fail? (= Injector disconnected from energy grid)

Maybe something is wonky with servers?

Sweet. I just built a new reactor with all mods updated and it worked for me with the gate touching the reactor... i placed the gate after the reactor was already formed tho so placing it beforehand might be an issue. I also noticed that attaching a second energy injector has gotten kinda wonky once the reactor has formed so for now it might be a good idea to fully build the reactor first (and open the GUI) and then place everything else around it.

@CocoVanChoco

The reason the reactor is shutting down is because you enabled "failsafe" - this option doesn't do what you think it does and i advise against using it - it becomes useless after past 11% fuel conversion anyways.

The reason your reactor is filling up is because energy can not be transferred away from the core fast enough (if at all)

On 9/26/2018 at 5:14 AM, MrSmirkNMerc said:

I just ran the energy down to under 10% capacity and the turbines kicked in. However they only stayed on for a few minutes until the cell was filled to about 20% percent and then shut off. Is there a way to set the threshold of when the program shuts the turbines off again to a higher percentage?

Do you have something else feeding into the energy storage? If so that might be enough to fill increase your storages charge. If not then this should not happen. Does the GRID display show the cell being 20% full as well? Do you have multiple turbines?

@Daggz I'll look into it, thanks. brgcctrl has never really been my main focus so I tend to overlook stuff in there. If you really NEED it you could set the OC CPU to Lua5.2 but that error right there is 100% my fault.

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?

@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.

@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.

@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.

@iBrokeMyPick

Umm... the first 3 characters of your turbines address is just b, a and d. Total coincidence

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

Or you can wait for one or two days and I'll release the version that no longer requires you to do that

EDIT:

Yes the version is pretty much finished but I got sick (as in ill) and never got around to release it - I originally wanted to release it last sunday..well...

The installer is just badly written and needs to copy everything to ram first *cough* BRGC needs less ram to run than the installer needs ^^;

@greenrhino33 You need more ram for the installer. Also T1 screens and gpus are not supported (if you intend to use the gui that is)

@cookieman768 Sounds like you changed the reactor layout after connecting the computer port. I suggest either removing the configuration file (and restarting) or breaking and replacing the port.

That depends on (a) your current energy demand and (b) the mode the grid controller is running in at that moment. Since you're >50% the grid controller propably started in DECREASING CHARGE mode, meaning it'll drain your storage until it reaches 20% and then charge it up to 95%, then drain it to 20% again etc etc...

If you connect multiple turbines it'll try to minimize the energy drainage / charging rate to keep your setup running more efficiently. Ofc if your energy demand raises above what you can actually produce, everything will kick on to maximize the remaining uptime of your grid.

@Bjoerniboii SUSPENDED means the controller (you're running GRID mode, right?) decided that your turbine does not need to be run. Most likely because there's a net gain of energy in your energy storage (INCREASING CHARGE) or because your turbine would charge your energy storage in DECREASING CHARGE mode.

EDIT: It may also be the case that your turbines internal energy storage is saturated

Fixed, sorry but ACME DNS verification can be a bitch if your TTL is 86400 seconds :/

Yeah there seems to be an issue with Lua 5.3 and linux servers. From what I can tell OpenComputers falls back to LuaJ for 5.3 on linux or something. But that is PURE speculation. When I fix my desktop linux I might do some more testing on that.

So you already correctly deduced that your OpenOS is too old. I can't help you with the updater though, sorry. You might want to ask for help in the OpenOS-Updater thread.

reactor_ctrl.lua line 84 - just add some numbers

No, using Big Reactors or Extreme Reactors doesn't matter. If you use steam for something else this IS gonna be a problem cause the program makes all kinds of assumptions based on how much steam is required by the turbines. It does indeed compensate but that's mostly for error correction not for making up for missing numbers

Lemme ask you as well: Is there a way I can look into the issue myself / firsthand?

I don't think so as the GUI displays the hot fluid tank as full - which wouldn't happen if the bug was active in your case... is that fortunate or unfortunate tho? xD

Welp - that clearly rules out any fluid related issues...