XyFreak

I do not have a solution for this issue - the gui is using a timer to redraw stuff - if it suddenly stops drawning then i don't think there's anything wrong with the program. In order for me to test things out I need you to tell me the version of OC, ER and propably your forge version as well.

@CygnusiaX1 Can you check if its related to some mod you are using ( *hint* optifine *hint* )  - the shell cursor should be blinking if you just leave the pc on after booting

@BrisingrAerowing I did but I forgot about it. `rftools_powercell` is already part of the whitelist. If your mod changes that then please add it to `/usr/lib/brgc/energy_storage_component.lua` and let me know if it works - i'll add it if it does.

@CygnusiaX1 the screen "updates" every second (it only redraws stuff that needs to be redrawn tho)

Well the design i posted is a drop-in replacement for your current design with no changes to the exterior required so you can go for that if you want to - it's up to you in the end  

As i mentiond in my last post: 3x3 cores or rings work very well as long as there's one layer of coolant between them

Nah that won't be necessary. If calibration fails that badly, that usually means your reactor has an efficiency curve where its most efficient point is VERY close to 100% rod insertion (in your case that'd be ~97%).

Sorry but i don't think you can get brgc to work properly with your design. I just checked and when ran at peak efficiency, the 9x9 core is indeed a tad more efficient than 4 individual 3x3 cores ( https://br.sidoh.org/#reactor-design?length=11&width=11&height=10&activelyCooled=false&controlRodInsertion=91&layout=24C3XC3X4C3XC3X4C3XC3X15C3XC3X4C3XC3X4C3XC3X24C ) (I usually go for a 3x3 grid of 3x3 cores like that).

If you are a bit savvy then can you try editing /usr/lib/brgc/reactor_base.lua ?

There is a line that looks like this (right near the top):

local reactorCalibrationMaxOutput = {0.01,0.02,0.05,0.1,0.15,0.2,0.25,0.3,0.35,0.4,0.5,0.6,0.7,0.75,0.8,0.9,1}

Can you add 0.03 and 0.04 between 0.02 and 0.05 ? And 0.075 between 0.05 and 0.1? Maybe that already hels in your case.

If you extended your reactor you need to make sure BRGC recalibrates it or otherwise it won't know that the reactor is now different.

There are multiple ways to do this:

1. Break & replace reactor computer port (this causes the old config to still be present somewhere tho)
2. Remove the config file ( rm /etc/br_control.cfg ) then reboot
3. do a brgcctrl recalibrate <first three characters of reactor address here>

I recommend (3) but (2) is propably easier than that and way cleaner than (1)

Ah ok I see what you did. The ON/OFF switch you pressed is not doing what you think it does

You turned off the GRID controller, which caused the reactor control to fall back to standalone mode. Since you're draining the reactors buffer into your induction matrix, the controller assumed that you are using more energy than you can produce and thus the reactor was running full throttle.

If you want to turn off the reactor you need to go to the "Reactors" (or "Combined") Tab and disable the reactor from there (click on the reactors bar).

CHARGE mode only does something if you have more than one reactor / turbine connected. Essentially it powers up every component and sets them to optimal levels to charge your energy storage.

Hi @Minoslo

Can you give me some more info? How is your reactor built? Active/Passive? Did you connect some sort of energy storage to the computer via an adapter?

What do you mean by when you tried to put if off? Did you try to turn off the reactor via the GUI? That should just.... turn it off (reactor controller block turning red).

It SHOULD work with T2/T2.5 (the installer needs lots of ram) components but as always I recommend you just go with T3 stuff to make sure everything runs smoothly.

So the 1.7 version is built around extracting energy from the reactor and reinjecting it through a seperate circuit. As a result, the flux gate extracting energy that goes to storage is only extracting CALCULATED_OUTPUT - REINJECT

So there's your problem. Your setup looks more like the 1.10 setup, in which case you should propably use the 1.10 program. (I knew i changed something important going from 1.7 to 1.10)

It looks like not enough power is being extracted from the reactor. DC is "immune" to config file changes as it has code in place to figure out those multipliers through backwards calculation (and sometimes they just don't matter). Is wherever you're piping the energy to able to accept that much / store that much? (I'm guessing yes but still asking )

ok

It should display the RF transfer limit in green text at the bottom of its GUI

@Chaoschaot234 no i never got around doing that, sorry.

@Electro56 If your temperature is stuck at 20 degrees then your reactor isn't even charging. Please have a look at the flux gate at the energy injector. If that's in computer mode and >0 then the flux gate is either facing the wrong way, not connected to energy or something is just not behaving connection wise.

EDIT:

@Chaoschaot234 regarding your edits: The GUI always selects the first reactor. If you look for a line like

local controller = draconic_control.controllers[1]

towards the end of the dc_gui.lua you can propably figure out on how to get it to display other reactors

I have a modified version around somewhere that makes it so dc_gui takes its first command line parameter and uses that as index but i dunno where it is right now.

The ultimate goal was to make everything (DC and BRGC) network ready and use the GUI and grid logic from BRGC manage everything but that obviously didn't happen. And right now I'm way to burned out from programming to get to that.

As for the 1.7.10 autostart one: No promises. It isn't hard but I'd still need to get around and do it. I haven't tried it but the 1.10 code might just work, depending on the version of OpenOS available for 1.7.10. The controller logic itself only got safer to use (and so did the setup).

exactly

you're welcome

no but if you're using my building guide, you should definitely follow the new one.

@isaacay

One last thing, since you are looking at the 1.7 page - the setup on the non-1.7 page is safer and you should go for that instead. It won't change any of the logic but shutting down the reactor is... not incredibly risky anymore.

i updated the link so you might have to hit shift + f5 to force clear your browsers cache - the link you're looking for is https://tenyx.de/draconic_control/1.7.10/draconic_simulator_64.exe btw

OH! Fixed the link, thanks.

@isaacay

I just doublechecked the links on https://tenyx.de/draconic_control/advanced.html#simulator and the files are accessable

What I'm more concerned about is that the error @Crack3dC0d3 posted can't/shouldn't happen. The code explicitly tests for nil there and there's a line offset by one.

So either he uses an older version or the sources on my server are not what they should be....

@Crack3dC0d3

i need more info on how you build your computer.

If BRGC does not set the fuel rods then something is broken. It does that every .5 seconds so....

I'll try to reproduce the issue but by the looks of it something is going wrong somewhere... is there any way for me to debug it on-site

@katt1204 You are running OpenOS 1.5 - that sounds REALLY old to me. I think i tested the earliest version of brgc against OpenOS 1.6 so... your only option is to upgrade i think.

Honestly you might get away with not using brgcctrl and start the services directly on your own but that's just speculation. Upgrading OC is your best bet.

@squidflex 
So everything is hooked up. Can you please hit the "CHARGE" button on the GUI and see if that changes anything for you? If it does then BRGC simply decides, that it's overproducing energy. Although 1600 mB/t sounds odd (as it should be 2000 mB/t -> 1 turbine).