Big Reactors Grid Control

[XyFreak 36]

Quick results:

Computronics uses an Environment with @Callback

public static class OCDriver extends DriverSidedTileEntity {

		public static class InternalManagedEnvironment extends ManagedEnvironmentOCTile<TileCapBank> {

			@Callback(doc = "function():number; Returns the average storage input per tick")
			public Object[] getAverageInputPerTick(Context c, Arguments a) {
				return DriverCapacitorBank.getAverageInputPerTick(tile);
			}

And Mekanism does not. Mekanism implements the "IComputerIntegration" Interface. So its "invoke" function gets called and....done.

Now I also checked DE myself and...yeah - it does things pretty similar to how mekanism does it - it's wrapped up a LOT nicer tough.

 

EDIT:

Yeahyeah - IComputerIntegration is a mekanism-specific interface

[ZeroNoRyouki 7]

So today I put together a small ManagedPeripheral that use the same stings lookup that DE use with just a couple of methods and the delay did not go away. Implementing ManagedEnvironment and NamedBlock too changed nothing. I've also switched to the SidedEnvironment capability from the Environment one because the former is queried first by the OC cable than the latter but no luck.

I've also traced how callbacks are executed by OC / Lua and the code path is identical for my owns and the DE ones. 

The only big differences between ER and DE at this point is that I use capabilities to interact directly with the OC cables while DE need the adapter block but I'm not sure this is significant

The VM JIT could also have a play at this (maybe DE use the same method used by it's callback while drawing the big energy orb on the screen and so that method is called so much that the JIT optimized the hell of out it) and so I've let the other reactor-controller program I've used so far run for an hour or so but again, no differences

Not sure what else is there to try at the moment...

[XyFreak 36]

Nice work >_>

I don't want to rule out the adapter thingy, but computronics also requires you to use adapters and it suffers from the delay as well.

I don't think the JIT does anything here as it's not really aware of the game logic, is it? Since the delay always seems to be one tick and the game itself doesn't freak out... it should be fine.

My money was on the "@Callback" thingy tbh....

 

Here's some more hints:

This configuration works:

• ER 0.4.5.21
• OC 1.6.1.6
• Forge 12.18.3.2185

As you can see that's before the API rewrite and before OC 1.7. For whatever reason I can't get the new ER version to work with OC 1.6 or OC 1.7 with the old ER version. I'll try to play around with versions some more in a second....

 

[XyFreak 36]

Ok i got different versions working on my notebook - guess I screwed up last time...

Results:

• OC 1.6 + ER 0.4.5.44 = bad
• OC 1.7 + ER 0.4.5.21 = good
• OC 1.6 + ER 0.4.5.21 = good
• OC 1.7 + ER 0.4.5.44 = bad
• OC 1.7 + ER 0.4.5.30 = good
• OC 1.7 + ER 0.4.5.41 = bad
• Upgrading forge did not change the results.

[ZeroNoRyouki 7]

Hi there, I've made another test tonight.

I wrote a very dummy implementation for my OC API with a barebone class that's is a straight implementation of OC's Environment, SidedEnvironment and ManagedPeripheral

No parent classes, no calls to the actual reactor code, just the most dummy and fast implementations of getConnected / getEnergyStored : https://pastebin.com/3Pfs1J99

An instance of that class is created when the computer port TileEntity is created and returned to OC when the cable ask the port for the SidedEnvironment capability

So there is no extra code that can slow things down. But the delay is still there, your test program is still registering it

Please keep in mind that I can't go back to the 0.4.5.30 implementation becase that version relied on OC SimpleComponent / class Transformer to work and I was asked by the OC guys to stop doing that : https://github.com/MightyPirates/OpenComputers/issues/2371

I'm pleased that the problem is not the @Callback annotation because I like it way more than the string lookup 

 

We may have to bring the OC's dev in at this point ...

 

[XyFreak 36]

So it seems @BrisingrAerowing opened an issue on the OC github (https://github.com/MightyPirates/OpenComputers/issues/2632). Since you kinda ruled out the @Callback annotation (tbh. I also think those are rather neat), the issue title / description is not really up to snuff, but this thread is linked so things should be fine...

[ZeroNoRyouki 7]

Please keep in mind that I've run all my test against OC 1.6.2.7 as that is the minimum version I'm targeting. So I don't think this is an 1.7.x problem

[XyFreak 36]

I've confirmed this issue to be present on OC 1.6.x as well

EDIT: I used 1.6.1.6 for my 1.6 tests

EDIT2: So...uh.. my point was - I agree  it's definitely not a 1.7.x problem

[BrisingrAerowing 12]

@XyFreak I've gone ahead and updated the issue with the new information.

[left 0]

Hello
I tried to use your program in FTB Beyond, but this error popped up:

NOTE - I'm not experienced in Lua, so if you could provide as much detail as possible, that would be appreciated. 

[XyFreak 36]

Hi @Gravydigger,

this looks like your installer download broke. Please remove it (rm brgc_installer.lua) and get it again.

[left 0]

@XyFreak,

Thanks, for your reply. Your program is now working

[ResqDiver1317 0]

Curious if there was any new information yet on the issue with the program running extremely slow. I just set up my system tonight and have the same issue using 1 reactor with 8 turbines. The program seems to be working, but takes forever to boot and the OC GUI is painfully slow to respond once it does boot. Takes a good 2 minutes just to type the command to open the BR program GUI and a good 30-45 seconds or more from the time I press a button in the GUI to the screen updating to show it.

 

[ResqDiver1317 0]

I don't know enough about how the individual programs work to try and figure out what the difference is that is causing the slow OC speed, but I am running this program for the moment (https://github.com/OpenPrograms/Vexatos-Programs/blob/master/reactor/bigreactors-control.lua) and it works smooth without the extreme slowness of the computer. The major downside of it is the "gui" is just text and you need a large (4x4) screen setup to even read the text easily and it's only using a small part of the screen space.

[XyFreak 36]

I'm pretty sure this program is also pretty slow, however, since there's not much interaction, you won't notice anything. The cycle time of that program seems to be one second. If the screen doesn't refresh every second, you're expieriencing the same issues. But since this program only turns on and off turbines/reactors, without actually regulating the components themselves, it works mostly fine. And the only user-interaction you have is shutting down the entire thing.... so.. yeah ^^

[ResqDiver1317 0]

Ok yea that makes sense. The only active stuff it seems to do is display statuses and cycle the coils on/off. Fortunately that is enough for me for the time being until whatever is making stuff so slow is resolved so I can use your program as I like it's GUI MUCH better, plus it does more control which is a big plus in my book.

[Silvcry 0]

Hello, i have a problem.

Whenever i want to start the brgc_installer it tells me something about: attempt to index a nil value.

HEre is a picture of how it looks like and btw i am playing on a server.

I would really appreciate if someone could help me with this problem.

Yours Tommy

[BrisingrAerowing 12]

@XyFreak @ZeroNoRyouki I may have identified the cause of the one tick delay and am testing a possible (and hacky) fix. I'll report back with the results.

 

UPDATE: It did not work. Back to the drawing board.

Edited December 12, 2017 by BrisingrAerowing
New info

[ZeroNoRyouki 7]

What is the problem your are trying to fix?

[BrisingrAerowing 12]

I looked at the cable class, and found it always get the capability from whatever it is connected to each time the method hasCapability was called. I tried caching the result but there was still the one tick delay, so it seems the issue is deeper in the code than I thought. I don't know where the actual environment capability is obtained and used, and I haven't found it anywhere yet (I haven't looked too hard, though).

[afr33sl4ve 0]

Is there a way to override the power generation when the total power storage goes below 20%? It caps my reactor ~30k rf/t, however, during calibration I saw it go well above 600k rf/t. My power demand (at base idle with rftools environment controller and EnvTech void miners) is about 25k rf/t.

At 30k generation, it takes forever to fill my generator. And, should I process a large crafting order, that number will jump easily to 200k rf/t.

Please advise.

[XyFreak 36]

Hi @afr33sl4ve.

You can hit the "CHARGE" button that's in the "Grid" GUI. That'll instruct the controller to fill up the energy storage.

The behaviour you're seeing is improving overall efficiency of your power-gen. I don't think there's an issue unless you're running into out-of-power situations due to this - In which case I need to come up with something.

[afr33sl4ve 0]

I noticed that it kicks into "INCREASING CHARGE" at 20%. However, messing about with the help commands, it dips to about 5% before it kicks in.

If I hit CHARGE manually, it'll cap the reactor at 30K rf/t max. The only time it goes beyond that is during the CALIBRATION stage.

[hron84 1]

On 1.12.2, screen does not scale very well, I use a 3x4 widescreen setup with T2 screens but EXIT is still missing. The program requires T3 screens or it is a bug?

[XyFreak 36]

Hey guys,

@afr33sl4ve I need some more info on your setup in order to figure out what's going on here.

@hron84 I have to admit I've only ever tested the GUI with T3 screens. If the resulution doesn't stack with multiple screens, then yes, ever since I introduced the grid controller, you'll need T3 screens