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

XyFreak

Members
  • Content count

    314
  • Joined

  • Last visited

  • Days Won

    27

XyFreak last won the day on March 2

XyFreak had the most liked content!

3 Followers

About XyFreak

  • Rank
    Leading Member

Contact Methods

  • Minecraft
    MC_XyFreak

Recent Profile Visitors

1955 profile views
  1. That's a difficult question but I hope this graph will explain it a bit for you: The blue line is the default config and the red "line" is the max rf/t config. As you can see the power output of the default config will continue to increase until the thermal limit is exceeded and then shut down shortly after. The max rf/t ones power output will increase at first until 2000000 rf/t is reached and then starts oscillating. The resolution of the graph isn't high enough so you see that red block there. The average energy output is somewhere in the lower third of that thingy (propably 1/3 * max + 2/3 * min). After reaching a certain temperature it'll quickly shut down here as well. EDIT: Here's the same graph with dots only:
  2. XyFreak

    Big Reactors Grid Control

    You're looking for lines 46 and 47 in `/usr/lib/brgc/grid_controller.lua`
  3. XyFreak

    Big Reactors Grid Control

    I'm running out of space there No, every call gets a new table that is created from scratch. The code constructing the table is in reactor_base.lua lines 425 - 467 if you want to take a look at it.
  4. XyFreak

    Big Reactors Grid Control

    Pls check out brgcctrl calibrate brgcctrl calibrate <address here> Alternatively you can always remove the configuration file to reset everything. EDIT: brgcctrl accepts partial addresses (e.g. the first three letters)
  5. XyFreak

    Big Reactors Grid Control

    Well after you extracted the files you can just proceed as you normally would. Keep in mind that the archives are meant to be extracted to the root of your computers filesystem.
  6. There is a sanity check in there but if the computer looses control of the flux gates / reactor there is nothing that can be done. For e.g. if the connection to the reactor is lost, it tries to set the output fluxgate to 0 and keeps the input at the last known to be good value. As long as the reactor is still connected and the input flux gate (control over output is lost) It'll keep the containment stable. There's also code that shuts down the reactor but that only happens once the reactor is over 99% saturation. The reason for that is that we don't know if shutting down the reactor will cause a brownout and subsequently cause the containment to fail. The issue here is that we lose control over both flux gates and can't do anything. The reactor is never gonna go to 99% saturation and we're screwed. You CAN just replace the check at line 252 with a true to have the failsafe always shut down the reactor if something happens tho.
  7. Hmm ic. The addresses should definitely NOT change after a server reboot.
  8. I had the same issue when using EnderIO OC conduits. Those conduits are bugged as hell and are counted for one component each the first tick after server reboot, which causes your computer to crash. I "fixed" the issue by reducing the number of conduits used and using a server with a lot of component cards. TL;DR Don't use EnderIO conduits and build the computer in the same chunk as the reactor
  9. Hey @Chaoschaot234 My libGUI should only redraw stuff that actually HAS to be redrawn - except when a redraw is forced which should only happen on resolution changes. I'll look into it. Are you sure the static stuff is blinking? You can set up the gui start yourself by ... umm... i think editing /home/.profile or something - there're posts here on the forum that explain how i think. At the present you can not monitor multiple reactors. The GUI doesn't support it - it's a flaw i know about and i actually have a modified version that is extremely wonky that CAN do it xD. Maybe I'll cook up something for that... For the config file it doesn't actually matter whether you coma-separate stuff or use semicolons. How does the GUI fail? You need to restart the reactor service after you changed the configuration file. Safest way is to reboot the computer. If you're not doing crazy breeder shenanigans the reactor will survive a computer reboot without any issues. Infact.... your reactor is gonna be safe if the computer crashes between 30%ish and 80%ish fuel conversion and doesn't come back on until it leaves that range - you're going to lose RF/t tho.
  10. XyFreak

    Big Reactors Grid Control

    Older versions of ER have racing conditions in the OC API that can and will straight up crash your server.
  11. XyFreak

    Big Reactors Grid Control

    Sorry I have no idea. I already offered my assistance but I think zero wants to do it without help
  12. XyFreak

    Big Reactors Grid Control

    Hi @MarkusPriska Your turbines propably have more coil blocks in them than they should have. Please double check your turbine design. As for the freezes, that's most likely a deadlock in extreme reactors. Afaik @ZeroNoRyouki is already looking into it. I don't know if the issues has been fixed. For startest, please try upgrading to the latest version of ER. If you already are on the latest version, then I'm afraid there is no fix just yet
  13. XyFreak

    Big Reactors Grid Control

    You are running an old version of OpenComputers. You'll need to update the mod and then reinstall OpenOS
  14. XyFreak

    Big Reactors Grid Control

    Umm... what is "brgc"? The error you're seeing is because that file is either empty or invalid (not sure which it is). However the installer shouldn't create a "brgc" file anywhere....
  15. XyFreak

    Big Reactors Grid Control

    brgcctrl has a help system - just do brgcctrl help
×

Important Information

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