XyFreak

Ok guys - good news and bad news.

Good news first: Implementing @BrisingrAerowings request was easy. It is already done in my latest dev version. Infact - I did it on stream

Now the bad news: I've been able to reproduce this "computer is slow" issue with newer modpacks.

And I'm 99% sure this is extreme reactors related. I can confirm that this behaviour starts with ER 0.4.5.40. Earlier versions of it won't work with OpenComputers 1.7, because of some Forge version incompatibility. Earlier versions of ER will just crash with the forge version OC needs now.

Now for the cause: Each time BRGC calls just one API function from extreme reactors, the computer is forced to yield for 1 tick. Since BRGC does like.... 7 or more calls per cycle per reactor/turbine and wants to do so every 10 ticks.....you can imagine what's going to happen. If this is a bug, then this has to be fixed. If this is intended, however, then I have to suggest removing computer ports from ER entirely - and I'm going to scrap this program because it'll be unusable (as will any kind of program controlling extreme reactors more than just turning it off and on - which can be done with redstone as well).

We'll see.....

-XyFreak

EDIT:

Link to the Twitter thread I started: 

Hopefully we're going to get more information soonish...

@BrisingrAerowing

https://www.dropbox.com/s/16t3my6dc10kgn4/IMG_20171031_224858.jpg

and yes

No, the grid controller just hooks into the other components and takes over control over some parts. If anything, not using that should make the computer run faster.

That's the default. 1:1 is easily possible.

Try this pls:

• Disconnect all reactors and turbines
• Stop the controller
• Remove /etc/br_control.cfg
• Reboot the computer
• Start the controller
• Open brgc_gui
• Connect all reactors / turbines at once

Hmm - how many reactors / turbines are connected to the controller? The most I've seen running was something like 3 reactors and 9 turbines. Also, if you're on a server with other ppl, OC might be set up to only use a very limited amount of time for its computation thread so there might be a bottleneck here.

On 31.10.2017 at 12:26 AM, TylzSomeone said:

So I have the program running but when the computer boots, it starts up really slow, once it finally boots up, it takes a while for the letters to show up ie- typing "brgc_gui", if i disconnect the turbine and reactor, the issue goes away, any thoughts?

Sounds like you're using a T1 CPU. I've only really tested the program with T3 CPUs. T2 might work if you're starved for resources but I haven't tested that.

22 hours ago, tempelon said:

i absolutly love this script! But is there any posibility to get the gui on startup? 

Check this out: 

On 4.10.2017 at 5:37 AM, TylzSomeone said:

Ok so opencomputers automatically uses Lua 5.3 correct? do i have to tell it to use 5.2 somehow? Also, i am also having the issue with the ticking world crash that is known. I'm moving my stuff around and trying random things to fix it but nothing good is coming of it yet. My GUI seems to work fine but maybe that is why the crash is happening due to Lua 5.3? Also, I'm using refined storage to supply water to the reactor and steam to the turbine, i thought possibly the issues was when it lost power but i fixed that issue so that is not the problem. For those with the same issue, what was your/their way of providing water and steam?

I haven't thought of that! You can cycle between Lua versions by holding the CPU in your hand and right-clicking into the air. I've tested BRGC with Lua 5.2. Someone once ran into a Lua 5.3 issue and I fixed it and did a bit of testing on 5.3 so it should work just fine on 5.3 but I'm not 100% sure on that one. Its definitely worth testing.

Hey guys - I JUST got a bunch of notifications from the OC forums so... I'll go through them now...pretty late if you ask me.

Anyways:

• My desktop computer is broken.
• I'm building a new one.
• The parts are on the way.
• No data has been lost.
• I'll resume development once everything is up and running again.

@CrazyDolphin I don't know whats wrong right now but it seems you've connected a looooot of stuff. Can you replace the tier 1 component card with a tier 3 one and/or put in more? I'll try to reproduce the issue once I have a working desktop again

I'll also look at the issue where BRGC doesn't allow reactors to output as much steam as you want it to. My money is on your reactors temperature. Anything close to 700°C (IIRC) for an active reactor is going to cause BRGC to throttle.

Well BRGC also has something like that, the regulation takes place on the energy, not the RPM  

Especially since max efficiency turbines peak out at 1780 RPM

Also: @Ghan is 100% correct.

Not right now, no. I'll have to include the fuel levels into some decisions - that's going to require a bit of code changes here and there.

I'm kinda burned out from traveling all over the place this weekend so... no code is going to be written for BRGC this week, sorry.

Its always prefering the one it thinks has the best efficiency. Since there is a lot of randomness going on, two identical reactors are never calibrated to exactly the same values. Even recalibrating a reactor may yield different results.

@blunge

Sounds like it temperatures are jittering too much. I've gotta find a different way of finding "the" stable state....

@corbanj6534

If your reactors run out of fuel, the grid controller gets confused (or rather - it doesn't care). I'll put that on my TODO

@Ghan

Thanks for your input. A few pages back where I talked about the "overdrive" mechanic I've stated that I do not want to add a lot of state to the controller because that makes it increasingly harder to debug. I'd rather use an incredibly complicated algorithm that uses very little state than a very simple algorithm that uses a lot of state. Most of your suggestions require the controller to keep measurment values - a lot of them. You did give me an idea however:

Decaying Maximum

The issue with figuring out the maximum energy consumption is that if we blindly take the all time maximum, we're going to be trapped if there is a spike ONCE. This is bad obviously. We can counter this by keeping track of energy consumption over a given amount of time and aggregate things. This, however, requires to add a lot of state. So my idea now is to just take the maximum and have it decay over time. That way we have a maximum which will be affected by spikes but will not get trapped. The basic idea is the following:

If storedMax <= current then
  storedMax = current
else
  storedMax = storedMax * weight + (1 - weight) * current
end

"weight" is going to be inversely based on the energy storages fill level - similar to how the weighted energy consumption metric works but with a different range and curve. If the energy storage is full, we might not need to care too much about the maximum and it decays faster.

Now we also need to keep track of the duration of these peaks. I plan on measuring the duration between first exceeding the "storedMax" value and a significant drop (not too sure on how to define this). The controller will then attempt to always keep "storedMax * duration" RF stored at all times. I'll see how this performs....

Again, thanks for the input. I'll keep you updated

Correct

@corbanj6534

Absolutely, yes. You can mix types of storage components as well. Just make sure they're all connected to the same power network.

Hi @Gepetto,

Lets start with the easy part:

-> 3) You can safely edit the files with tab characters. It's just a display thingy.

Now to the odd part:

-> 1) Good catch - there is a bug in the grid controller init script: It forgets to initiate scanning for energy storage components on startup. However that raises another question: Why does it even find the energy storage blocks on computer startup on my test world in the first place?

-> 2) I didn't read your EDIT at first and went bug hunting. But....

BRGC measures the energy that is output from your energy storage and substracts the amount of energy that is currently produced by components connected to it (aka turbines / reactors). If you feed it energy from an external source, your energy output becomes negative. Thus it is indeed INCREASING your CHARGE by not running anything. This is part of the logic that shuts down everything if you're not consuming any power and... as far as I'm concerned... the correct behavior (only produce as much power as needed).

I'm guessing you're generating the ingrediends out of thin air (aka a farm)? Wouldn't it indeed be most efficient to not burn any fuel then?

If you have a good idea on how to make the logic smarter I'm all ears. I guess I can see the issue you have with your energy storage being essentially empty all the time thus removing the advantage of having it in the first place.....

Ok - again for everyone here.

BRGC does NOT work with your CPU set to Lua 5.3 right now. I have to at least change all my string.format uses throught the entire code for that to work.

So unless I release an update: Do not attempt to use Lua 5.3 if you want to use the GUI. The controller itself works perfectly fine on 5.3 though.

The good news is: The controller itself seems to be working.

The bad news is: While I know WHAT is happening (thanks to your big screenshot of the libGUI error), I don't know WHY.

Essentially the rate with which RF is extracted from your reactor is calculated to be NAN. Of course getting NAN is simple: divide zero by zero, divide by infinity or use NAN in a calculation. And yes, there is a division in there somewhere but that one can't devide by zero. I made sure of it. The only numbers I get which are not under my control are the ones from extreme reactors. And I'll just assume those are not NAN as well

So yeah....

I also just double checked in my test world that your setup should not be an issue at all.

I kinda hate using this answer as a solution for everything lately, but: Is there a way for me to check this issue in person? Like: a world file or a server?

@Humpledink

This looks like either a nil value is stuck somewhere. I need some more info here:

• What version of minecraft are you running?
• What does your setup look like?

Also can you try to run

brgcctrl service reactor runOnce

and if that errors out please post the message? Thanks.

@mcshadowdrag I've never seen this kind of issue before. Maybe try to reinstall OpenOS? You can redownload the installer by doing

rm /home/brgc_installer.lua

and then wget it again.

Big Reactors Grid Control Version 4.2.4 has been released!

Changelogs:

 - Fixed a bug that caused the grid controller to crash if more than one passive reactor is connected
 - Fixed a bug where the turbine controller would include disabled/suspended turbines steam input in the total steam requirements.

Just the installer though.... xD

2 minutes ago, corbanj6534 said:

Soooo Hi again, it's been a while xD. Having a bit of trouble with the latest version on 1.7.10. I have set up a reactor with a computer controlling it just fine, my friends are trying to do the same on the same server and it's failing to download br_grid_control @ 50% however it works fine in single player. Any idea what would cause this? Is it one controller per server?

No but you should check the amount of RAM you installed in the computer. Also the server might hit a memory limit somewhere...

If nothing works, just clone your computers hdd

In order to use more than 16 components with a server you need to insert "Component Bus" Cards into the server. Each T3 card allows you to connect 16 more components to the server.

In the rack GUI you can/have to connect the server to one side of your rack. Afterwards the server can access all components connected to this side and this side only so make sure to connect everything properly

If you want to use the terminal server (doesn't work very good with the GUI btw) you also have to connect the terminal server to that side in the rack GUI. Monitors can of course be connected to said side of the rack as well.

Side node: If you have more than one GPU and monitor in your server the GUI will pop up on your OTHER monitor and will give you back your shell on your primary monitor.

@Ghan

First of all thanks for the throughout description of your situation. I really hate to give a very short answer to very throughout questions, but.... can you PM me the server address? ^^;

The picture of the reactor GUI shows stuff that shouldn't happen - at all: The reactors steam tank is full, there is excessive heat and the rods are STILL not inserted 100% (aka you're consuming fuel) - that's just not right.

So...just to make sure I fully understood your setup:

You have 5 turbines and one reactor for each. All reactors/turbines are connected to a single controller? If so make sure all reactors can feed steam to al turbines.

If it's a simple 1 turbine, 1 reactor, 1 controller setup then everything SHOULD be fine. But the water supply is a serious concern. If you want to use a tank, concider using the Thermal Expansion ones. Putting those on top of a coolant port and having them output SHOULD be able to buffer some demand - if you're also feeding the condensed water from the turbine directly into the reactor.