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


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by XyFreak

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

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

  3. 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)

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

    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.

  5. 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).

  6. 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)

  7. 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 ;) )

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



    @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 :P

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

  9. 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 ;)

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

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


Important Information

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