Big Reactors Grid Control

[TylzSomeone 0]

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?

[tempelon 0]

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

[XyFreak 36]

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.

[tempelon 0]

Thank you exact what i needed 

[BrisingrAerowing 12]

@XyFreak When you get your computer up and running again, you may want to look at the new 'getMultiblockAssembled' method in Extreme Reactors, which tells you if the multiblock is complete or not. May be useful to avoid calling methods on an invalid multiblock.

Also, the crash with computers has been fixed completely in the latest versions of ER for MC 1.10.2+.

[TylzSomeone 0]

3 minutes ago, BrisingrAerowing said:

Also, the crash with computers has been fixed completely in the latest versions of ER for MC 1.10.2+.

That’s great to know. I wish it didn’t require updated forge though. Updating forge and not all of the other mods seems to slowly kill our server. 

[TylzSomeone 0]

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?

[XyFreak 36]

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.

[TylzSomeone 0]

Honestly, that’s what I thought too but that was the first thing I checked, using T3 CPU. 

[XyFreak 36]

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.

[TylzSomeone 0]

Just one reactor and one turbine. The OC CPU budget is set to .5, 1.0, and 1.5 on the server. I’m not sure if those are the standard OC settings or if it was adjusted. 

[XyFreak 36]

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

[TylzSomeone 0]

46 minutes ago, XyFreak said:

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

I completed all of those steps. So when I disconnect the reactor and turbine, the computer runs at normal speed, once I connect the reactor and turbine again, OC runs really slow but the brgc program runs fine. If I terminate the reactor and turbine programs, the OC returns to normal speed again. I don't run the grid program, that wouldn't have anything to do with it would it?

[XyFreak 36]

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.

[Gendal 0]

I have the same issue as TylzSomeone on Modern Skyblock 2 - 2.6.2.1

Just a 7x7 bog standard extreme reactor, no turbine or grid components. Tier 3 everything, tried both Lua 5.2 and 5.3, etc. Super slow when running the services, but the gui runs fine oddly enough, though it doesn't actually seem to control anything or display the charge level in the reactor. 

[BrisingrAerowing 12]

@XyFreak

Once you get your computer up and running (if it isn't already), could you add Grid Controller support for Mekanism's Induction Matrix (A multiblock power storage system)?

[XyFreak 36]

@BrisingrAerowing

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

and yes

[killerjerick 0]

Yup, that definitely looks like an open computer ^^ 

Thanks a tonne for this program, been trying to write my own for days an kept getting strange errors or worse, no error but no functionality, this worked straight up and was super simple to install, Thanks again!

 

 

Edit: First time (when I made this post) it worked straight away, was very straightforward. The second time (I changed the turbine configuration) it started being really delayed, not unlike TylzSomeone and Gendal playing on ATM3 modpack. Wonder what could be causing this.

Edited November 8, 2017 by killerjerick
Started having issues

[XyFreak 36]

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...

[Tahak 1]

Hey @XyFreak

So after few days I posted issue about this problem to EX github. Well, you can read about it there, much faster than Twitter. Hope this get sorted out and it won't be one of those cases of finger pointing.

https://github.com/ZeroNoRyouki/BigReactors/issues/146

[XyFreak 36]

@Tahak Thanks for the github issue. Unfortunately, I don't have a github account so I can't answer there.

Now I don't want to do any finger pointing either. However, you can see the computer yield by writing a program as small as this:

 

local component = require("component")
local computer = require("computer")

local myTestComponent = component.br_reactor

for i = 0, 10 do
	local ts1 = computer.uptime()
	myTestComponent.getEnergyStored()
	local ts2 = computer.uptime()
	print(string.format("%1.0f", (ts2 - ts1) * 20))
	os.sleep(0.05)
end

This program will run for 10 11 iterations, calling "getEnergyStored()" and calculate the number of ticks it took to process the call. If you execute the program with a reactor connected, this will print you a bunch of 1s.

If you connect a ... lets say... draconic orb and used

local myTestComponent = component.draconic_rf_storage

instead, you will get a bunch of 0s. Same for the mekanism induction matrix btw. Now I DID notice the same 1 tick cost when accessing components via computronics (ender io capacitor bank), so I suspected this to be an OpenComputers issue at first - but since i got at least two other mods running just fine....this can't be the (whole) issue, can it? Also, removing computronics doesn't change this behavior.

 

As for "other programs run fine". I do believe that. Any program that has a slow cycle time would (a) not cause so much noticable lag and (b) won't be affected by the caused lag (much). That being said, I haven't tested the mentioned program but given the really minimal example above I'm pretty sure it still causes lag / issues, which just aren't as noticable as with BRGC and its "insane" cycle time of running every 10 ticks.

As a side note: I had BRGC run on every other tick for fun during development on 1.7.10 . Worked fine but the controller took too much cpu time from the GUI... and anything else for that matter.

[Tahak 1]

So if I get this correctly this could be avoided, by running the function that is working with reactor in larger intervals? Meaning that it would be slower but not completely ruin OC PC.

At the same moment what is mystery for me, is that turbines works fine, it is only reactor that is affected. 

As soon as we get some evidence here I will post it back to git. Also I'm going go test 'the other program' and report the results here.

[XyFreak 36]

5 hours ago, Tahak said:

So if I get this correctly this could be avoided, by running the function that is working with reactor in larger intervals? Meaning that it would be slower but not completely ruin OC PC.

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.

[ZeroNoRyouki 7]

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

[XyFreak 36]

Hi @ZeroNoRyouki

Thanks for showing up. Good to know you're taking this serious. I mean it. Thanks.

I'll also try to poke around a bit. Though I'm not really familiar with the OC internals ^^;

Knowing it's not your code but something in between is also really valuable information. I'll look into computronics code and see if they're also using OC Environment + @Callbacks and if Mekanism does something similar to DE. If so - that should reinforce your hunch.