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

There's a comma missing at the end of the "fluxGateDrainbackAddress" line

Hi @KnockOutGamer

There is no additional work required for 1.12.2. If you get the message, you propably have a typo somewhere.

@stealth95l

The grid controller drains your energy storage until it's below 20% and then carges it until it's 95% full. It does so by tweaking energy production to be just shy of what you are actually consuming for discharging and just a bit more when charging.

The assumption here is that for charging, less production is more efficient overall, and keeping your energy storage filled for longer improves responses to sudden power surges.

Note that it will always drive your components at their peak efficiency, unless you have passive reactors in your system and are requesting more energy than you can efficiently produce.

Meaning: Turbines will always run at peak efficiency or are halted. Reactors SHOULD always run at peak efficiency except when you just need more power.

@stealth95l Well it's just blindly dividing by 0 so... *cough* woops. 0 would be wrong btw - it should propably display "---" or maybe "not connected".

@bjonnfesk You have OpenOS 1.7.4, which is bugged - you'll need to update OpenComputers or use the OpenOS updater. This has been discussed here quite a bit.

BRGC is not on a public git repo because I never wrote a "build script" so I just checked in the entire OpenOS installation *cough* and use my package builder to build and upload the different libs and packages from the running installation *cough*.

( I should get that cold checked  )

Nice, thanks

There is no particular safety check in place - it's just that the system itself stops working properly at some point. There is code in place to mitigate some of it but unfortunately it's something that's nothing I can easily fix.

The internal capacity is based on the reactors size but caps out at 50B. What you could do is build a second reactor and BRGC is gonna split the load.

The main issue is that the internal steam capacity is limited to 50B so as soon as you hit >25B/t steam and it's no longer possible to level out at 50% (25B) everything kinda goes downhill.

Hi @Freedbot,

the issue is that BRGC has issues with certain reactor designs when you attempt to push past 50% total capacity. You could try to recalibrate the reactor with all turbines connected and see if that helps.

Hi @ManinSuit

try this: 

No you will either have to use a loooong cable and chunkload a the entire cable or use some kind of mod that allows direct OC connectivity wirelessly

When I tried to update my test instance I noticed that no new version of OC has been uploaded to curseforge yet.

That means that the timer bug is still a thing in your OpenOS installations

So the "fix" is to downgrade OC (and reinstall OpenOS afterwards) or do the thing at the bottom of my post here 

That would explain why @ZeroNoRyouki runs into issues as well as all of your "calibration stuck" issues.

I'm sorry but that is something I can't fix.

Please post a schematic of your reactor so I can investigate the issue. Calibration never took longer than 3 minutes for me (passive reactor). Active reactors calibrate really fast tho.

Can you try a "brgcctrl service reactor runOnce" and see if an error occurs? Also a screenshot of the reactors GUI and the layout would be nice.

Welp - your setup is a lot bigger than my test setup then xD

I'll look into it. My guess is that they run into an error while they're being spun up to optimal rpm?

I'll try to free up some time to build a new setup and debug the issue. Also... maybe scrollbar

Scrolling support, eh? maybe  Sounds easy, right? Fricking hard to actually do.

If your turbines run straight into "error" mode then you have more turbine blades for your coil. BRGC assumes that if your turbine has enough blades to support X mB/t then your coil does too.

EDIT:

That being said - if that's not the case and everything SHOULD work but its not then its a bug

@ZeroNoRyouki

The program assumes that whatever fluid gets produced, can be consumed by any connected turbine as long as it doesn't cap out the internal capacity. The power balancing might actually be an issue - but the fix would be: Don't attach ports if you don't need them.

@BattyCynris

Sorry for the delay i JUST got the email notification that you posted something. You are running into an OpenOS issue that should be fixed by now (see posts a bit "earlier" on this page). Please update OpenComputers and then reinstall OpenOS.

You need to have all energy storage devices connected that sit immediately behind your generators (note all generators need to be able to feed all of them - dedicated storage devices for each generator are not supported). Intermediary energy devices don't REALLY matter but it'd obviously give the controller a better understanding of how much power you actually have.

The wheighted is a rolling average where the factor is determined by how full your energy storage is ( formular is `wheighted_rft = (1 - (energy_stored / storage_total)) * current_rft + (energy_stored / energy_total) * wheighted_rft` ). That value is then used to determine how much power should be produced. The reasoning behind this is simple: If there's a lot of energy stored, react slowly cause there's energy stored - no need to up fuel consumption, is there? If there's less and less energy, the controller needs to react faster to changes in energy demand to not cause a power failure.

Hi @GenSmicer

The order to connect everything from a CLEAN INSTALL is:

• Turn on the turbines to make sure steam can be consumed.
• Connect the reactor.
• Wait for calibration to finish.
• Connect the turbines.

That should be everything you need to do.

What does "it also never really showed a number" mean?

There is indeed an issue with RFTools power storage as it caps out at 2^31-1 RF stored (limitation of the API they use).

I just realized that timers had a drifting problem since forever by the looks of it:
Even since before the commit that broke things, if a timer called something that let time pass (i know this is bad anyways but it CAN happen), it would actually fully delay the deadline of successive timers (instead of just delaying the timer once).

Here's another patch

--- C:\Games\MultiMC\instances\Draconic Computers 1.12\.minecraft\saves\BRGC\opencomputers\a201b7a4-e2fd-4565-8b4b-79a6993a7e62\lib\event.lua.bak
+++ C:\Games\MultiMC\instances\Draconic Computers 1.12\.minecraft\saves\BRGC\opencomputers\a201b7a4-e2fd-4565-8b4b-79a6993a7e62\lib\event.lua
@@ -62,7 +63,11 @@
       -- nil keys match anything
       if (handler.key == nil or handler.key == signal) or current_time >= handler.timeout then
         handler.times = handler.times - 1
-        handler.timeout = current_time + handler.interval
+        -- we need to make sure the timer doesn't drift but at the same time doesn't get rescheduled
+        -- immediately if it's execution had been delayed significantly (>= handler.interval * 2).
+        repeat
+          handler.timeout = handler.timeout + handler.interval
+        until handler.timeout > current_time + handler.timeout
         -- we have to remove handlers before making the callback in case of timers that pull
         -- and we have to check handlers[id] == handler because callbacks may have unregistered things
         if handler.times <= 0 and handlers[id] == handler then

I decided to go with a loop instead of math based, because the most likely case is this loop getting executed exactly once. Solving this with math would require math.floor which would propably be slower than this most of the time.

Ok since I need a github account I'm just gonna ping @payonel and hope he's the right guy for the job!

Here's what's up:

This commit here broke BRGC - and it actually broke timers in general whenever event.pull is involved.

BRGC uses events and timers all over the place. The entire thing is running asynchronously. Now usually you don't want to drop to the prompt when running a program so here's what it does:

function libGUI.run()
	while event.pull(math.huge, "libGUI_terminate") == nil do end
end

It just waits for a libGUI_terminate event and then cleans up stuff. Pretty easy.

Now with the linked commit, this event.pull continues to eat timer messages. The timers are only executed once a non-timer event is executed (such as a key press or a touch).

Here's a small PoC:

event.timer(5, function() print("canary") end, math.huge)

Prints "canary" every 5 seconds - pretty easy - nothing should go wrong here. If you now do a simple

while event.pull(math.huge, "tell_me_to_terminate") == nil do end

you will stop seeing "canary" show up - it's dead

--- SNIP because I didn't want to believe the issue is complicated and looked further into it ---

And here's your bug:

In /lib/event.lua line 36 computer.uptime() is read and stored in a variable called current_time that is never updated again. Afterwards we enter a post-checked loop. Inside of this loop, on line 54, this line is executed:

local event_data = table.pack(handlers(closest - computer.uptime()))

Nothing wrong with that, until you realize, that calling handlers actually calls _pullSignal, which allows time to pass. Later, current_time is used to check if timers have expired. The issue? current_time is no longer current, because _pullSignal was called and time has passed!

So unless you return from computer.pullSignal (=> cause a non-timer event to be triggered like a key press or a touch), current_time is never updated so timers will never trigger.

The fix is really easy: update current_time after _pullSignal has been called.

Here's a patch:

--- C:\Games\MultiMC\instances\Draconic Computers 1.12\.minecraft\saves\BRGC\opencomputers\a201b7a4-e2fd-4565-8b4b-79a6993a7e62\lib\event.lua.bak
+++ C:\Games\MultiMC\instances\Draconic Computers 1.12\.minecraft\saves\BRGC\opencomputers\a201b7a4-e2fd-4565-8b4b-79a6993a7e62\lib\event.lua
@@ -54,6 +54,7 @@
     local event_data = table.pack(handlers(closest - computer.uptime()))
     local signal = event_data[1]
     local copy = {}
+    current_time = computer.uptime()
     for id,handler in pairs(handlers) do
       copy[id] = handler
     end

That was a b*tch to figure out... holy molly.

Yeah at this point I'm convinced it's a bug in recent versions of OpenOS - I'm gonna file a bug report

Ok i traced it back to changes in /lib/event.lua - stay tuned!

Hey guys,

I've been able to confirm this issue after updating OpenOS - unless I can say for sure it's not an issue on my end I'm not gonna bisect the OpenOS version it starts happening on tho... tbc...