XyFreak

Hi @MaSch
An OpenComputers program should never be able to crash your server.
Lets do a quick breakdown.
Here's your stacktrace:
Description: Exception in server tick loop java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextNode(Unknown Source) at java.util.HashMap$KeyIterator.next(Unknown Source) at java.util.AbstractCollection.toArray(Unknown Source) at com.google.common.collect.ImmutableSet.copyOf(ImmutableSet.java:374) at elec332.core.grid.internal.GridEventInputHandler.tickEnd(GridEventInputHandler.java:91) at elec332.core.grid.internal.GridEventHandler.serverTick(GridEventHandler.java:49) at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_304_GridEventHandler_serverTick_ServerTickEvent.invoke(.dynamic) at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90) at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:185) at net.minecraftforge.fml.common.FMLCommonHandler.onPostServerTick(FMLCommonHandler.java:261) at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:657) at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:471) at java.lang.Thread.run(Unknown Source) You can see there're two lines that don't look like they're not vanilla minecraft or forge related:
at elec332.core.grid.internal.GridEventInputHandler.tickEnd(GridEventInputHandler.java:91) at elec332.core.grid.internal.GridEventHandler.serverTick(GridEventHandler.java:49) A quick google reveals that the mod those methods belong to is (suprise suprise) eleccore.
I suggest you go to the github issue tracker and report your findings because this looks pretty much like the exact same thing that's happening to you.
 
Next up... what is eleccore used for and can we temporarily remove it? Well it looks like eleccore is used by Deep Resonance and that mod has worldgen. So removing it is a no-no. Duh....
So...what can we do?
Since we know that Deep Resonance is using eleccore, you can try to remove all your Deep Resonance machines and see if you're still able to reproduce the isse. Is it gone? Well... this means that you're no longer able to use DeepResonance without crashing your server... but at least you're no longer crashing the server so that's a start. Additionally go and look for the Deep Resonance issue tracker as well and tell them that using that there're some serious issues with the library they're using.
 
I hope this somehow helps you. Unfortunately there's nothing more I can do. Those are the joys of modded Minecraft
 
-XyFreak

Hey,
sorry for the radio silence - at some point i stopped getting notifications when someone posts here
I have just pushed an update that should fix a lot of issues with 1.12.2 (better late than never). It also fixes a bug that messed with the calibration itself (it should actually be accurate now).
 
Now to answer some questions
It is not possible to have the GUI displayed on multiple monitors. Output only works to one monitor. I also can't hack that in reliably because there's not enough in-game CPU cycles to draw the GUI twice without flickering and run the controller.
The "ERROR" message almost always means that your reactor is overheating during calibration (check your piping) or that your turbine goes overspeed. Please check the guide on what the program expects your turbine to be capable of.
 
@CompuRight now the controller is suspending by disengaging the coild and shutting it down. Are you saying the small loss in speed over time is completely negated by setting the flow rate to 0 instead? o.O

Hi everyone.     A while back I promised more releases, so here you go: Big Reactors Grid Control is a multi reactor/turbine controller for Big Reactors and Extreme Reactors. Mission goal: Be the best big reactors controller there is. Nothing more, nothing less.
First things first - here's the website: https://tenyx.de/brgc/
NOTE: Due to a bug with OpenOS 1.7.4, BRGC will not work with that version. Please update to 1.7.5.
Main features Active and passive reactor support Support for multiple reactors and turbines at the same time (n:m) Control active and passive reactors with the same controller Automatic configuration of everything (EVERYTHING!) Setup instructions
wget the installer from here: http://xypm.tenyx.de/standalone/brgc_installer.lua Run it Done Big Reactors Grid Control comes with three rc.d files:
/etc/rc.d/brgc_reactor.lua /etc/rc.d/brgc_turbine.lua /etc/rc.d/brgc_grid.lua If you want the controller to run at boot time, you can just use OpenOS' rc.d schema.
  There's a GUI as well as a command line utility for advanced users.
To start the gui, simply run "brgc_gui" and watch the magic happen.
The gui scales the screen resolution to match the screens ratio and should scale with basically all screen setups.
I recommend 3x2 or 4x3 screens.
 
As of now the command line utility allows you to do (almost) everything you can do with the GUI and also allows you to change the controllers configuration at runtime (if you so desire).
Check out "brgcctrl help" for further information.
 
How to set up the grid
In a basic setup you just interconnect everything:
All active reactors can output steam to all turbines. All passive reactors and turbines output energy to the same grid.
You CAN have passive reactors and turbines output energy to different energy grids.
While this poses absolutely NO problem for passive reactors, you will have to set some turbines to "independent"-mode (more on that below).
If you want your reactors and turbines to properly cooperate, you'll also need to connect at least one energy storage block to your energy grid.
Currently supported storage "blocks" are:
EnderIO Capacitors (requires the mod "Computronics") Draconic Evolution Energy Storage multiblocks. RFTools Energy Cells Thermal Expansion Energy Cells Mekanism Induction Matrices You can connect them using OpenComputers Adapters.
 
Discovering new components As mentioned before the controller tries to autoconfigure everything:
 
Passive Reactors When a new passive reactor is connected to the controller, the controller will first try to measure its maximum energy output. The reactor will have its output increased step by step and the average (interpolated) maximum will be used for that value (CALIBRATING).
After calibration has been completed, the controller calculates the most efficient energy output of the reactor.
 
Active Reactors
When a new active reactor is connected to the controller, the controller will first try to measure its maximum steam output (CALIBRATING). For this to work correctly the reactor must be able to output at least SOME steam (read: you need a consumer) and you will need to provide sufficient ammounts of water. The controller will detect reactors with a potential steam output greater than 50 B/t and limit its energy accordingly.
 
Turbines
When a new turbine is connected to the controller, the controller will first try to measure its maximum energy output (CALIBRATING). For this to work, make sure your turbine is built correctly. This means your turbine can be run at maximum supported steam (25mb/t per blade) without exceeding 1950 RPM. Should your turbine exceed 1950 RPM at any stage, the controller will shut down the turbine and flag it as failed.
Note: Your turbine is NOT required to be able to process 2000 mB/t. Smaller turbines work perfectly fine.
 
Screenshots
After this wall of text, here're some screenshots (pre 4.2).
 
Setup:  
Main view:
 
Passive reactor details:
 
Active reactor details:

 
Turbine details:
 
Let's go in order:
When you start up the GUI you will be presented with the main view.
Here a combined overview of passive reactors, active reactors and turbines will be presented.
You can click (or touch) on any of these items to open up a detailed view of the component.
Here you can enable/disable the component or change its behaviour.
 
What behaviour? This is where it gets interesting.
 
Passive Reactors You will notice that passive reactors have two modes and an "auto" mode.
 
PWM This is the behaviour everyone knows: The reactor gets turned on when its internal energy storage drops below 10% and gets turned off when the energy storage exceeds 90% of it's maximum capacity.
In PWM mode the reactor will generate energy at its most efficient rod level.
Overall this mode allows the reactor to generate energy as efficiently as possible as long as your actual energy consumption is below or equal to its optimal energy output.
But sometimes you need just a bit more energy and you don't want to upgrade your reactor or build a new one. "Classic" controllers will fail to produce sufficient ammounts of energy here.
 
This leads me to the second behaviour: Load
In "Load"-mode the reactor will always aim to produce energy at the same rate as it's consumed. Maybe some people already suspect what that mode is all about: It's a PD-like regulator.
While "Load"-mode is not as efficient as PWM-mode in situations where the energy consumption is below the optimal energy output, it will guarantee you're never running into energy shortages - provided you're not exceeding the reactors maximal capacity.  
Auto "Auto"-mode aims to eliminate the disadvantages of both modes by combining them:
If the energy consumption can be satisfied with PWM-mode, PWM will be used. If the energy consumption is above optimal levels, "Load"-mode will be used instead.
As a result, "auto"-mode generates energy as efficient as possible while always saturating your energy demands.
 
Active Reactors As of now, active reactors only operate in "load" mode. Steam is consumed and produced way too fast and the reactors internal steam storage does not allow for anything else.
 
Turbines
Turbines controlled similar to reactors in "load" mode: The controller will always try to balance the turbines internal energy storage out to 50% by using a PD-like regulator.
Turbines can be operated in "ganged"-mode or in "independent"-mode, with "ganged"-mode being the default.
The only difference between these two modes is that turbines in "ganged"-mode can be shut down by the controller, while "independent" turbines will always be active, even if they overproduce energy at the lowest RPM allowed.
This is handy if one (or more) of your turbines produces energy for a seperate (dedicated) energy grid but has to be controlled by the same controller. If such a turbine is not in "independent"-mode it may be shut down which will lead to energy failure in that grid.
 
That's it for now. If you have any questions, want to report bugs, etc., feel free to drop a message here.
Also: Do you want an indepth tutorial on how to use the command line utility? Need a description on what the GUI is actually showing?  
Have fun 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

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)

@XyFreak It's likely because RFTools Power uses a new API in McJtyLib that uses Longs for power. I'm going to write a quick and dirty driver for said API so that this can work with it.
 
EDIT: Unfortunately OC seems to be capping returned values to the maximum value of a 32 bit integer. Although Vex said that it internally uses doubles, so it should work. Not sure why it doesn't. I'm going to try casting it to a double and see what happens.
EDIT2: I GOT IT TO WORK!!! Uploading to CurseForge now!

Currently there are no plans to do that. Fun fact: the installer already downloads packets but it doesn't actually act as packet manager.
The whole thing originally emerged from my "xypm" which was able to get packets from the internet tunneling everything over OC network and allowing computers without internet cards to ... install packets (as long as there is a computer on said network with an internet card). My plan is to revive that but...heh.. dunno when.

Ok the issue has been fixed @Dreytac @sanovskiy, sorry for missing that... that was stupid of me...

I'll make it official now.
Big Reactors Grid Control Version 4.3.1 has been released!
Changelog:
- Now using the new ER API (0.4.5.48 and higher). Old API is still supported. - Implemented further mitigations for the "too long without yielding" issues. - Included a hack/workaround for a bug with OpenOS 1.7.1 (and earlier) and Lua 5.3 mode. - Fixed a bug where attempting to format a number as an integer (illegal in Lua 5.3 mode). I'm sorry for abusing some of you as beta testers

yep, should always require("bit32"), it is not intended to be global (we aren't clearing it from _G in boot). I'll fix in dev. sorry

Hi everyone.     A while back I promised more releases, so here you go: Big Reactors Grid Control is a multi reactor/turbine controller for Big Reactors and Extreme Reactors. Mission goal: Be the best big reactors controller there is. Nothing more, nothing less.
First things first - here's the website: https://tenyx.de/brgc/
NOTE: Due to a bug with OpenOS 1.7.4, BRGC will not work with that version. Please update to 1.7.5.
Main features Active and passive reactor support Support for multiple reactors and turbines at the same time (n:m) Control active and passive reactors with the same controller Automatic configuration of everything (EVERYTHING!) Setup instructions
wget the installer from here: http://xypm.tenyx.de/standalone/brgc_installer.lua Run it Done Big Reactors Grid Control comes with three rc.d files:
/etc/rc.d/brgc_reactor.lua /etc/rc.d/brgc_turbine.lua /etc/rc.d/brgc_grid.lua If you want the controller to run at boot time, you can just use OpenOS' rc.d schema.
  There's a GUI as well as a command line utility for advanced users.
To start the gui, simply run "brgc_gui" and watch the magic happen.
The gui scales the screen resolution to match the screens ratio and should scale with basically all screen setups.
I recommend 3x2 or 4x3 screens.
 
As of now the command line utility allows you to do (almost) everything you can do with the GUI and also allows you to change the controllers configuration at runtime (if you so desire).
Check out "brgcctrl help" for further information.
 
How to set up the grid
In a basic setup you just interconnect everything:
All active reactors can output steam to all turbines. All passive reactors and turbines output energy to the same grid.
You CAN have passive reactors and turbines output energy to different energy grids.
While this poses absolutely NO problem for passive reactors, you will have to set some turbines to "independent"-mode (more on that below).
If you want your reactors and turbines to properly cooperate, you'll also need to connect at least one energy storage block to your energy grid.
Currently supported storage "blocks" are:
EnderIO Capacitors (requires the mod "Computronics") Draconic Evolution Energy Storage multiblocks. RFTools Energy Cells Thermal Expansion Energy Cells Mekanism Induction Matrices You can connect them using OpenComputers Adapters.
 
Discovering new components As mentioned before the controller tries to autoconfigure everything:
 
Passive Reactors When a new passive reactor is connected to the controller, the controller will first try to measure its maximum energy output. The reactor will have its output increased step by step and the average (interpolated) maximum will be used for that value (CALIBRATING).
After calibration has been completed, the controller calculates the most efficient energy output of the reactor.
 
Active Reactors
When a new active reactor is connected to the controller, the controller will first try to measure its maximum steam output (CALIBRATING). For this to work correctly the reactor must be able to output at least SOME steam (read: you need a consumer) and you will need to provide sufficient ammounts of water. The controller will detect reactors with a potential steam output greater than 50 B/t and limit its energy accordingly.
 
Turbines
When a new turbine is connected to the controller, the controller will first try to measure its maximum energy output (CALIBRATING). For this to work, make sure your turbine is built correctly. This means your turbine can be run at maximum supported steam (25mb/t per blade) without exceeding 1950 RPM. Should your turbine exceed 1950 RPM at any stage, the controller will shut down the turbine and flag it as failed.
Note: Your turbine is NOT required to be able to process 2000 mB/t. Smaller turbines work perfectly fine.
 
Screenshots
After this wall of text, here're some screenshots (pre 4.2).
 
Setup:  
Main view:
 
Passive reactor details:
 
Active reactor details:

 
Turbine details:
 
Let's go in order:
When you start up the GUI you will be presented with the main view.
Here a combined overview of passive reactors, active reactors and turbines will be presented.
You can click (or touch) on any of these items to open up a detailed view of the component.
Here you can enable/disable the component or change its behaviour.
 
What behaviour? This is where it gets interesting.
 
Passive Reactors You will notice that passive reactors have two modes and an "auto" mode.
 
PWM This is the behaviour everyone knows: The reactor gets turned on when its internal energy storage drops below 10% and gets turned off when the energy storage exceeds 90% of it's maximum capacity.
In PWM mode the reactor will generate energy at its most efficient rod level.
Overall this mode allows the reactor to generate energy as efficiently as possible as long as your actual energy consumption is below or equal to its optimal energy output.
But sometimes you need just a bit more energy and you don't want to upgrade your reactor or build a new one. "Classic" controllers will fail to produce sufficient ammounts of energy here.
 
This leads me to the second behaviour: Load
In "Load"-mode the reactor will always aim to produce energy at the same rate as it's consumed. Maybe some people already suspect what that mode is all about: It's a PD-like regulator.
While "Load"-mode is not as efficient as PWM-mode in situations where the energy consumption is below the optimal energy output, it will guarantee you're never running into energy shortages - provided you're not exceeding the reactors maximal capacity.  
Auto "Auto"-mode aims to eliminate the disadvantages of both modes by combining them:
If the energy consumption can be satisfied with PWM-mode, PWM will be used. If the energy consumption is above optimal levels, "Load"-mode will be used instead.
As a result, "auto"-mode generates energy as efficient as possible while always saturating your energy demands.
 
Active Reactors As of now, active reactors only operate in "load" mode. Steam is consumed and produced way too fast and the reactors internal steam storage does not allow for anything else.
 
Turbines
Turbines controlled similar to reactors in "load" mode: The controller will always try to balance the turbines internal energy storage out to 50% by using a PD-like regulator.
Turbines can be operated in "ganged"-mode or in "independent"-mode, with "ganged"-mode being the default.
The only difference between these two modes is that turbines in "ganged"-mode can be shut down by the controller, while "independent" turbines will always be active, even if they overproduce energy at the lowest RPM allowed.
This is handy if one (or more) of your turbines produces energy for a seperate (dedicated) energy grid but has to be controlled by the same controller. If such a turbine is not in "independent"-mode it may be shut down which will lead to energy failure in that grid.
 
That's it for now. If you have any questions, want to report bugs, etc., feel free to drop a message here.
Also: Do you want an indepth tutorial on how to use the command line utility? Need a description on what the GUI is actually showing?  
Have fun XyFreak  

Nice^^
1.02 drainback is not safe for servers tho  but even getting that up to 1.05 or even 1.1 won't really reduce the numbers that much.

@Aquila_chrysaetos
The link itself was wrong so i fixed that. You'll have to use the link from the page. Also your browser might've cached the page so try to do a force refresh (SHIFT + F5 i think?).
https://tenyx.de/draconic_control/draconic_simulator_64.exe (spot the difference :P)

@Aquila_chrysaetos
thanks for letting me know! It looks like i screwed up the links.... wow.. this must've been broken for a LOOOOONG time.
Everything is back up and in order now

Excuse me @XyFreak,
The link to simulation program for both 32bit and 64bit are down.
I've searched many forum posts and got no clue about what happened to those links.
Any ideas?

Looks like your trying to run the program on an older OpenOS version or an older version of OpenComputers  if the OC version is recent but you haven’t upgraded the OpenOS install you don’t have the new thread library.

Hi @Marzolan,
thanks for reporting this issue and for looking into this. 
Unfortunately, it looks like a failsafe / shutdown optimization mechanism is triggered here that I implemented some time after I came up with the breeder. I'll look into making it possible to disable it.
If you want to play with it please have a look at lines 131 - 141 in /usr/lib/draconic_control.lua.
function DraconicController:decideShutdown(reactorInfo) if reactorInfo.generationRate == 0 then return false end if reactorInfo.fieldDrainRate * self.drainback / reactorInfo.generationRate < 0.7 or reactorInfo.temperature < self.limitTemperature then return false end return true end You CAN make that function always return false, in which case your reactor SHOULD shut down with roughly 99.51% fuel conversion - and a shutdown time of well over 15 hours. And the whole thing gets extremely scary towards the end
What I'm also curious about is that the reactor works fine using the simulator so I wonder if there's something else that's causing the condition "reactorInfo.fieldDrainRate * self.drainback / reactorInfo.generationRate < 0.7" to become false (starting the reactor with high energy saturation maybe). I need to look into that. If you want a quickfix i suggest you change the function into something like this
function DraconicController:decideShutdown(reactorInfo) if reactorInfo.generationRate == 0 then return false end local conversion = reactorInfo.fuelConversion / reactorInfo.maxFuelConversion if conversion > 0.05 or reactorInfo.fieldDrainRate * self.drainback / reactorInfo.generationRate < 0.7 or reactorInfo.temperature < self.limitTemperature then return false end return true end Of course making the function always return false does not fix your issue then the floating point thingy might be true. Although I'm pretty sure lua uses doubles, as does my simulator and so does draconic evolution. And floating-point math SHOULD be consistent throughout C++ (simulator), LUA and JAVA.

@Marzolan , sweet
The other part isn't actually a failsafe but rather a shutdown condition optimization. The condition becomes false as soon as energy generation is going down really heavily. This usually means that the cycle is almost over. As a result the cooldown time will dramatically (!!!) be reduced while maximizing output. As I said... without the optimization in place you'll run into a situation where the reactor is going to take 15hrs to cool down (compared to the <1 hr with it). The change you made essentially makes the function always return false. The actual code that enforces the temperature limit is somewhere else (line 183 and 194-196). If you don't care for the safety part of the function I highly recommend you hardcode some sort of fuel conversion level so your breeder doesn't take ages to cool down ;).
I assume you know this already but let me put it down here anyways: The more chaos is in your reactor, the longer your reactor takes to cool down. And that scales exponentially. So the difference between 61 mb fuel left (that's close to the point of no return btw - i haven't calculated that yet but i think somewhere around 55mb your reactor will be unable to cool down and past that it'll continue to heat up due to its inability to dicipate heat) and .. let's say 120 mb is 15hrs to 3hrs or something.
Anyways - have fun with your breeder 

Hi @traeck,
this is a bug in versions prior to 0.4.5.40 of Extreme Reactors (we think). Please upgrade to 0.4.5.46 or later.
EDIT:
I got my versions wrong... >_>

It's been a WHILE - but it is finally time...
Big Reactors Grid Control Version 4.2.6 has been released!
Changelogs:
- Greatly reduced the number of API calls for setting reactor fuel rod levels. - Fixed a bug where the reactor controller would miscalculate the fuel rod offsets with sub 1% precision. - Fixed a bug where the grid controller would not set the reactors output rate to the optimum but leave it as is when coming out of "HOLDING CHARGE" mode. - Partially rewrote calibration code for reactors to remove "magic values". - The Tabs for "Reactors" and "Turbines" will be omitted if there's not enough space for them (only calculated on GUI startup). - Fixed GUI resolution misbehaving on T2 screen setups. The colors are still off due to colorspace limitations on those screens. - Fixed grid UI for very slim screen setups. Try a sexy 3x1 T3 screen setup! - Added experimental support for mekanism induction matrix. J -> RF conversion ratios can be set in mekanism config. Conversion ratios other than 5:2 (J:RF) will confuse the controller. The ratio for the induction matrix can be changed in /usr/lib/brgc/energy_storage_component.lua - Added support for thermal expansion energy cells. In order to upgrade from previous versions, you just need to run the installer again.
If you've used BRGC with any ER version between 0.4.5.40 and 0.4.5.45 you might want to upgrade to 0.4.5.46 now and remove your brgc configuration afterwards to recalibrate your setups.
I've changed some of the calibration code for reactors so those might calibrate a lot slower. If you feel calibration does not terminate, please send me a schematics of your reactor.
Also... I can't stress enough how sexy this looks:

It's pure coincidence the spacing works out so well too

Hi,
I've just posted and updated version of ER on Curse (It's under review right now). All the Callbacks are back to the old-direct-call-we-dont-care-about-threads-because-who-knows way of the original code. You must break and replace all your computer ports to see this in action
Z

Hi everyone.     A while back I promised more releases, so here you go: Big Reactors Grid Control is a multi reactor/turbine controller for Big Reactors and Extreme Reactors. Mission goal: Be the best big reactors controller there is. Nothing more, nothing less.
First things first - here's the website: https://tenyx.de/brgc/
NOTE: Due to a bug with OpenOS 1.7.4, BRGC will not work with that version. Please update to 1.7.5.
Main features Active and passive reactor support Support for multiple reactors and turbines at the same time (n:m) Control active and passive reactors with the same controller Automatic configuration of everything (EVERYTHING!) Setup instructions
wget the installer from here: http://xypm.tenyx.de/standalone/brgc_installer.lua Run it Done Big Reactors Grid Control comes with three rc.d files:
/etc/rc.d/brgc_reactor.lua /etc/rc.d/brgc_turbine.lua /etc/rc.d/brgc_grid.lua If you want the controller to run at boot time, you can just use OpenOS' rc.d schema.
  There's a GUI as well as a command line utility for advanced users.
To start the gui, simply run "brgc_gui" and watch the magic happen.
The gui scales the screen resolution to match the screens ratio and should scale with basically all screen setups.
I recommend 3x2 or 4x3 screens.
 
As of now the command line utility allows you to do (almost) everything you can do with the GUI and also allows you to change the controllers configuration at runtime (if you so desire).
Check out "brgcctrl help" for further information.
 
How to set up the grid
In a basic setup you just interconnect everything:
All active reactors can output steam to all turbines. All passive reactors and turbines output energy to the same grid.
You CAN have passive reactors and turbines output energy to different energy grids.
While this poses absolutely NO problem for passive reactors, you will have to set some turbines to "independent"-mode (more on that below).
If you want your reactors and turbines to properly cooperate, you'll also need to connect at least one energy storage block to your energy grid.
Currently supported storage "blocks" are:
EnderIO Capacitors (requires the mod "Computronics") Draconic Evolution Energy Storage multiblocks. RFTools Energy Cells Thermal Expansion Energy Cells Mekanism Induction Matrices You can connect them using OpenComputers Adapters.
 
Discovering new components As mentioned before the controller tries to autoconfigure everything:
 
Passive Reactors When a new passive reactor is connected to the controller, the controller will first try to measure its maximum energy output. The reactor will have its output increased step by step and the average (interpolated) maximum will be used for that value (CALIBRATING).
After calibration has been completed, the controller calculates the most efficient energy output of the reactor.
 
Active Reactors
When a new active reactor is connected to the controller, the controller will first try to measure its maximum steam output (CALIBRATING). For this to work correctly the reactor must be able to output at least SOME steam (read: you need a consumer) and you will need to provide sufficient ammounts of water. The controller will detect reactors with a potential steam output greater than 50 B/t and limit its energy accordingly.
 
Turbines
When a new turbine is connected to the controller, the controller will first try to measure its maximum energy output (CALIBRATING). For this to work, make sure your turbine is built correctly. This means your turbine can be run at maximum supported steam (25mb/t per blade) without exceeding 1950 RPM. Should your turbine exceed 1950 RPM at any stage, the controller will shut down the turbine and flag it as failed.
Note: Your turbine is NOT required to be able to process 2000 mB/t. Smaller turbines work perfectly fine.
 
Screenshots
After this wall of text, here're some screenshots (pre 4.2).
 
Setup:  
Main view:
 
Passive reactor details:
 
Active reactor details:

 
Turbine details:
 
Let's go in order:
When you start up the GUI you will be presented with the main view.
Here a combined overview of passive reactors, active reactors and turbines will be presented.
You can click (or touch) on any of these items to open up a detailed view of the component.
Here you can enable/disable the component or change its behaviour.
 
What behaviour? This is where it gets interesting.
 
Passive Reactors You will notice that passive reactors have two modes and an "auto" mode.
 
PWM This is the behaviour everyone knows: The reactor gets turned on when its internal energy storage drops below 10% and gets turned off when the energy storage exceeds 90% of it's maximum capacity.
In PWM mode the reactor will generate energy at its most efficient rod level.
Overall this mode allows the reactor to generate energy as efficiently as possible as long as your actual energy consumption is below or equal to its optimal energy output.
But sometimes you need just a bit more energy and you don't want to upgrade your reactor or build a new one. "Classic" controllers will fail to produce sufficient ammounts of energy here.
 
This leads me to the second behaviour: Load
In "Load"-mode the reactor will always aim to produce energy at the same rate as it's consumed. Maybe some people already suspect what that mode is all about: It's a PD-like regulator.
While "Load"-mode is not as efficient as PWM-mode in situations where the energy consumption is below the optimal energy output, it will guarantee you're never running into energy shortages - provided you're not exceeding the reactors maximal capacity.  
Auto "Auto"-mode aims to eliminate the disadvantages of both modes by combining them:
If the energy consumption can be satisfied with PWM-mode, PWM will be used. If the energy consumption is above optimal levels, "Load"-mode will be used instead.
As a result, "auto"-mode generates energy as efficient as possible while always saturating your energy demands.
 
Active Reactors As of now, active reactors only operate in "load" mode. Steam is consumed and produced way too fast and the reactors internal steam storage does not allow for anything else.
 
Turbines
Turbines controlled similar to reactors in "load" mode: The controller will always try to balance the turbines internal energy storage out to 50% by using a PD-like regulator.
Turbines can be operated in "ganged"-mode or in "independent"-mode, with "ganged"-mode being the default.
The only difference between these two modes is that turbines in "ganged"-mode can be shut down by the controller, while "independent" turbines will always be active, even if they overproduce energy at the lowest RPM allowed.
This is handy if one (or more) of your turbines produces energy for a seperate (dedicated) energy grid but has to be controlled by the same controller. If such a turbine is not in "independent"-mode it may be shut down which will lead to energy failure in that grid.
 
That's it for now. If you have any questions, want to report bugs, etc., feel free to drop a message here.
Also: Do you want an indepth tutorial on how to use the command line utility? Need a description on what the GUI is actually showing?  
Have fun XyFreak  

Read, "where the call takes at least one server tick"
Here: https://github.com/MightyPirates/OpenComputers/blob/f5c19e9e7e0006d3403c7bf0b44dfb970cee8a2f/src/main/java/li/cil/oc/api/machine/Callback.java#L43-L59

Since you are using mekanism: The next version will have support for mekanisms energy storage thingy btw.