Tahak

Hi there,
I've just uploaded the new version of ER (with the new API) on Curse (it's under review at the moment)
Have fun!

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 there!
So, I've run the "test" program in my 1.10.2 devenv and got the same bunch of 1s. I then changed getEnergyStored() to always return a fixed values without querying the reactor and tested again: same result. This is good, as it's not the reactor code that it's slowing thigs down
What I basically have, code wise, is an OC'Enviroment with a bunch of @Callbacks (getEnergyStored, getFuelAmount, etc). DE also implement an Enviroment but it use a string lookup (from ManagedPeripheral) to call the methods. If OC is using reflection to find the correct method on every method invocation we could have and explanation of the delay. I'll have to look around a bit more in OC code
Z

Unfortunately, this is not correct. Running the controller in larger intervals would devastate its ability to keep the reactor output leveled. For smaller to medium sized passive reactors this wouldn't really be an issue. Active reactors however would constantly overproduce steam - then get their output cut and underproduce steam. Something similar would happen to larger passive reactors. My point was that in the past you could run BRGC litterally every tick with no additional lag introduced by outside factors whatsoever
I've run my test program (last post) against turbines and they have the same issue, unfortunately. They require a lot less API calls to control though (BRGC sets each fuel rod individually to achieve finer grained control over the output capabilities).
 
Recap:
Reactors + Turbines are affected. ER is not the only mod with this behavior (-> computronics) There are mods without this behavior (-> draconic evolution, mekanism) We have a very small program to check on ... lets call it: API call latency The issue has been observed on 1.10.2 at least (I've not yet tested 1.12) This is pretty much everything we can do without diving into the mods code and comparing how the OC API is implemented here vs DE or mekanism to figure out what's going on. If this goes on for a bit longer I might end up doing that this weekend.