XyFreak

1 hour ago, payonel said:

As to the delay in the shell, please see my comment in the github ticket

-edit-

I'll post here for  those that don't want to open more tabs:

First of all, if you are sleeping ( os.sleep ) in a service, that is going to block your shell. Use threads instead if you want to sleep without blocking other coroutines http://ocdoc.cil.li/api:thread

I'm not sleeping in a 'service' thread, I'm using timers

From what zero told us here I was under the impression that he already is using the api as it's supposed to be used.

@payonel I did not know the github issue gained some steam during the last couple of days. Thanks for bringing that to my attention.

You've been saying that oc is not a realtime system and i agree. if yielding after each component api call is the intended bebaviour i'd like to see that documented somewhere. Also that limit should be enforced for all mods/apis. And if that's really the case then ... let's say I'm going to be sad

@payonel Please check the post you quoted from ;). On the last two pages of this thread we discussed it in some more detail.

Hi @ZeroNoRyouki

Thanks. Here's a list of things I would query but maybe it'd be a good idea to have a command that includes all non-mod-global-constants. Anyways, here we go:

Active Reactors:

• getHotFluidProducedLastTick
• getHotFluidAmount
• getHotFluidAmountMax
• getFuelTemperature
• getFuelAmount
• getFuelAmountMax
• getFuelConsumedLastTick

Passive Reactors:

• getEnergyProducedLastTick
• getEnergyStored
• getEnergyStoredMax (That's a mod constant right now but this should be included in case you want to change this at some point)
• getFuelTemperature
• getFuelAmount
• getFuelAmountMax
• getFuelConsumedLastTick

Turbines:

• getEnergyProducedLastTick
• getEnergyStored
• getEnergyStoredMax (That's a mod constant right now but this should be included in case you want to change this at some point)
• getRotorSpeed
• getFluidFlowRateMax

In addition to that I also set all fuel rods individually to get finer grained control over the reactor. This is kinda important for everything medium-sized and above (you usually start seeing its effects with 8+ fuel rods and a decent height). So a command that accepts an array of values between 0 and 100 for each rod would be neat. I'd expect this command to fail if:

• The size of the array does not exactly match the number of rods
• Any of the arrays elements is not an integer
• Any of the arrays element integers are outside of range [0, 100]

This is also where I'm currently debating on how to optimize for less API calls.... but that kinda function would solve all my worries here.

Having an API like that would at least make smaller setups feasible again (I'm thinking one active reactor with two turbines). For larger setups the individual passive reactor / turbine controllers would no longer get confused but the controller for active turbines might still not be able to keep the steam tanks fill level as smooth as it was able to in previous versions. Same with "LOAD" mode for anything propably.... But I think we can all live with that for the time being

Thanks again for helping out.

-XyFreak

Ok here's my verdict: Since the yield bug we discovered in november is STILL not fixed, my guess is that any anomalies you see is because of that!

The controller needs to fetch a bunch of stats from the reactor during the same tick, which is no longer possible due to that bug. This throws off the controller and it can't properly calibrate your reactor.

I'm sorry but there is nothing I can do except saying: Early versions of ER for 1.10 still work. 1.7.10 works as well. Later versions of 1.10, all versions for 1.11 and all versions up to today for 1.12 are not supported.

Don't bug ZeroNoRyouki about this too much. He's a cool guy and tried to help already (go check the previous pages). Instead go bug the OpenComputer guys about this. Here's the issue on GitHub (https://github.com/MightyPirates/OpenComputers/issues/2632).

The least I'd expect is some kind of response. But as you can see: Nothing. Sorry for being grumpy about this but this thing really sucks and the guys in the OC IRC channel are not really helpful either, telling me to "just use more computers!" (instead of fixing the issue), which is obviously not practical for most users.

-XyFreak

@afr33sl4ve I just tried to build the reactor in your schematics and it tells me it's too large. Can you double-check the dimensions of your schematics? The dimensions you put in there are for the reactor interiour.

So the total size of your reactor schematics is 18x18x48

Since you are using mekanism: The next version will have support for mekanisms energy storage thingy btw.

Actually Additions fluid placers help ;)...

I can't believe I came up with that only just now....things could've been so much easier, lol

That's going to take a while to build xD

I'll get to it tomorrow

EDIT: BTW - Could it be that you swapped cryotheum and ender around? Cause ender is good on the outside while cryotheum is better inbetween rods afaik

@hron84 I think I'll make it so it hides the "Reactor" and "Turbines" buttons on lower resolutions.. that should do the trick. Thanks for the TE cell thingy.

@afr33sl4ve I need a way to rebuild your reactor in my test world so a schematic would be nice.

@dsplzion What version of draconic evolution are you on?

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

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.

@ClownApocalypse

If you've actually done everything correctly, then I'll have to take a look whether the API changed or not - though I don't think it did.

"Connection Failure" means exactly what you might think it means: It can't contact one of the components. Please double-check whatever you did with https://tenyx.de/draconic_control/. ESPECIALLY the configuration part. Please make sure there is no typo in the keys as well. Also please try to reboot your computer (although I'm pretty sure you already tried that ).

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

Hi @MetalKluG,

you might've double checked the addresses, but you didn't do that for the "variable" names  Looks like you misspelled "fluxGateDrainbackAddress"

Hi @Gravydigger,

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

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

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

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.

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

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

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.

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.

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