XyFreak

Looks like that didn't get it any further... thanks.

@Seiver@SpaceBeeGaming

I've updated the "polynomial" component of BRGC to be more efficient with transponating matrixes. I know this is not going to fix the core issue here but it might help you getting over the issue for now. Can you please run the installer again and check if it's still occuring for you? If not please post me the error message again so I can figure out whether this actually helped a little or not. I need more time for a real/proper fix.

Very bad news is that i can't fix that right off the bat.

Looks like the calculations on the calibration data is taking too much time. I have an idea but... going to take a bit

@Marzolan , sweet

The other part isn't actually a failsafe but rather a shutdown condition optimization. The condition becomes false as soon as energy generation is going down really heavily. This usually means that the cycle is almost over. As a result the cooldown time will dramatically (!!!) be reduced while maximizing output. As I said... without the optimization in place you'll run into a situation where the reactor is going to take 15hrs to cool down (compared to the <1 hr with it). The change you made essentially makes the function always return false. The actual code that enforces the temperature limit is somewhere else (line 183 and 194-196). If you don't care for the safety part of the function I highly recommend you hardcode some sort of fuel conversion level so your breeder doesn't take ages to cool down ;).

I assume you know this already but let me put it down here anyways: The more chaos is in your reactor, the longer your reactor takes to cool down. And that scales exponentially. So the difference between 61 mb fuel left (that's close to the point of no return btw - i haven't calculated that yet but i think somewhere around 55mb your reactor will be unable to cool down and past that it'll continue to heat up due to its inability to dicipate heat) and .. let's say 120 mb is 15hrs to 3hrs or something.

Anyways - have fun with your breeder 

Hi @Marzolan,

thanks for reporting this issue and for looking into this. 

Unfortunately, it looks like a failsafe / shutdown optimization mechanism is triggered here that I implemented some time after I came up with the breeder. I'll look into making it possible to disable it.

If you want to play with it please have a look at lines 131 - 141 in /usr/lib/draconic_control.lua.

function DraconicController:decideShutdown(reactorInfo)
	if reactorInfo.generationRate == 0 then
		return false
	end
	
	if reactorInfo.fieldDrainRate * self.drainback / reactorInfo.generationRate < 0.7 or reactorInfo.temperature < self.limitTemperature then
		return false
	end
	
	return true
end

You CAN make that function always return false, in which case your reactor SHOULD shut down with roughly 99.51% fuel conversion - and a shutdown time of well over 15 hours. And the whole thing gets extremely scary towards the end

What I'm also curious about is that the reactor works fine using the simulator so I wonder if there's something else that's causing the condition "reactorInfo.fieldDrainRate * self.drainback / reactorInfo.generationRate < 0.7" to become false (starting the reactor with high energy saturation maybe). I need to look into that. If you want a quickfix i suggest you change the function into something like this

function DraconicController:decideShutdown(reactorInfo)
	if reactorInfo.generationRate == 0 then
		return false
	end
	
	local conversion = reactorInfo.fuelConversion / reactorInfo.maxFuelConversion
	if conversion > 0.05 or reactorInfo.fieldDrainRate * self.drainback / reactorInfo.generationRate < 0.7 or reactorInfo.temperature < self.limitTemperature then
		return false
	end
	
	return true
end

Of course making the function always return false does not fix your issue then the floating point thingy might be true. Although I'm pretty sure lua uses doubles, as does my simulator and so does draconic evolution. And floating-point math SHOULD be consistent throughout C++ (simulator), LUA and JAVA.

@BrisingrAerowing

Really? I thought that would just give you the net energy rate of the orb storage, just like the orbs GUI does.

Anyways, I will not make that part of BRGC but this means that you COULD make a GUI for that, indeed. Looks like I was wrong, sorry.

2 hours ago, Rhajos said:

Hey XyFreak, is there any way in your program to show the RF input and output of a draconic core? Or is there any other way to let me see this with OpenComputers?

Hi @Rhajos,

BRGC works with a draconic energy orb. However it'll only display the net energy balance of your energy storage. AFAIK there is no way to get seperate input / output rates for the draconic energy orb. That's something only the ender io capacitor banks and mekanism induction matrixes have.

I can say for certain, that the API for the draconic energy orb does expose that kind of information so there's no program that can do what you want. Sorry.

@Dr_JFZoidberg

Thanks for reporting the issue. In order to figure out why the reactor is not finishing calibration (... thanks ... you guys just keep breaking it ) I need a reactor schematics so I can rebuild and reproduce the issue.

20 Turbines sounds like 40 B/t steam. While this does kinda work, I highly disencourage driving the reactor at 40 B/t steam because there's too little headroom for clipping. In fact I suggest not exceeding 20 B/t load per reactor. I have not tested that tho so you might be fine. Multiple steam producing reactors can be connected together no problem.

You want BRGC to be connected to your main power storage (the mekanism induction matrix I assume) or else it'll think you're using all of your power and it'll really floor your powergen in order to prevent energy starvation.

Can you also provide me with a screenshot of the components used in your server? I can't seem to reproduce the crash. Its obvious that it's GPU related but it just keeps working fine for me for some reason.

EDIT:

Nvm I can kinda guess what's going on with the gpu stuff. I'll fix that tomorrow. For now: sleep!

Hi @traeck,

this is a bug in versions prior to 0.4.5.40 of Extreme Reactors (we think). Please upgrade to 0.4.5.46 or later.

EDIT:

I got my versions wrong... >_>

Hey guys,

sorry for forgetting you ... >_>.

I've just updated my test world to the latest version of DE an OC. Other than the components having their address changed due to the OC update, draconic control still works as intended for me.

Are you, by chance, using any other guide other than my own? If two ppl are having the same issues then maybe said guide has a typo somewhere in the configuration...

Big Reactors Grid Control Version 4.2.7 has been released!

Changelog:

 - Fixed reactor calibration not completing.
 - Increased calibration accuracy.
 - Implemented workaround for situations where active reactors won't output enough steams from their hot fluid tank even though there should be plenty available.
 - Added graceful degradation to reactor performance if hot fluid tanks are overflowing.
 - Retweaked active reactor regulator.
 - Added fuel level display to the reactor info panel. The fuel level displayed is the REACTIVE fuel, which is fuel + waste / 100.

Thanks again for reporting the calibration bug so fast. It should be fixed for good now. If you still run into that bug you should rethink your reactor design... propably... but still report it

I've also implemented the request from @hron84 (fuel level on reactor tab), but since the GUI is pulling the fuel information from the controller, which is using the fuel that is actually generating radiation, the fuel level is (fuel + waste / 100) instead of just (fuel). I hope that's fine with you.

I also noticed that my turbines were behaving funny and it seems like my reactors don't output enough steam as soon as their hot fluid tank falls below 50%. I dunno why that is. There's definitely steam in there and I'm not producing >50% of the reactors max capacity (which would otherwise explain this behavior). So for now the target isn't 50% but 75%, which, unfortunately, has some bad implications on the regulator itself. Mainly it'll have a lot less room to balance out the steam. I rebalanced that to compensate that but... I'm pretty sure you'll be able to break it. Also, because clipping is now much more likely, the reactor won't just shut down 100% once the hot fluid tank is full but instead will gradually put in the control rods, allowing for much smoother recovery. Unfortunately all of this also means that using the reactor for producing steam for non-turbines won't work as well as before anymore. But since that was never REALLY intended, I'm good with that.

@ZeroNoRyouki I have a small (?) feature request:

There should be blocks (tanks) you can put in your reactor wall that will increase the capacity of the hot fluid tank / coolant tank. As a side effect, this will also allow reactors to output more than 50 B/t steam if not capped by additional code though (I don't really care about the 50 B/t output (!) limit but killing that off might be a good idea regardless). For consistency the same should be done for passive reactors (flux capacitor addon) and for turbines (flux capacitor addon, steam/water tank addon). Especially for turbines this should come in handy, as turbines have a really tiny amount of flux storage for the massive amounts of energy they produce per tick. For balancing reasons you could make the tanks of active reactors no longer scale with the size of the reactor but instead force players to use those tanks instead.

Ok, i know what's happening... trying to figure out what I can do about it. Thanks for letting me know.

Thanks @BrisingrAerowing

Looking into it right now!

5 hours ago, noelmage said:

I'm having trouble getting my reactor to leave calibration mode. The reactor enters calibration mode and the control rods get inserted to 99% immediately, but then nothing ever finishes.

Is there a minimum size requirement for the active reactor maybe?

Hi @noelmage,

this shouldn't happen but when I changed the way calibration works I feared I might cause this....

Can you please give me a schematic of your reactor so I can figure out what's going on for myself? Thank you.

@zendarva It is really unlikely for the calibration to not be able to get finish once it passes 5% (maybe 10%), especially after the last update.

If I understood you correctly, the GUI still displays "CALIBRATING"?

If so, please try running "brgcctrl service reactor runOnce" a few times in quick succession and check whether it errors out or not.

If you installed OpenOS on the HDD and you updated OpenComputers along the road after that (you mentioned something about old log entries) please try reinstalling OpenOS

5 minutes ago, Tahak said:

But as I was told here you can insert double GPUs in server and you will get console on one screen and brgc_gui on the other one

 

BTW:

If I would go nuts and build let's say 100 turbines is there any way to connect them all to server? As PC cannot take that many components even with "Component Bus"

Getting a shell on another screen works. Running the GUI twice doesn't.

Nothing keeps you from using a server instead of a computer. You just can't connect multiples together.

On 30.1.2018 at 10:01 AM, hron84 said:

@XyFreak few questions:

 - Can the controller put grid into charging state without turbines? It didn't work for me in previous version 

 - In next version it would be great if fuel level could be checked on reactor tab...

 - Do you plan to support multiple screens / servers?

->1 That should work just fine

->3 There is no plan for that. Multiple screens is never going to be implemented because I can't dispatch enough drawcalls per tick. Networking and server stuff is going to be realised in a different program. TBA

It's been a WHILE - but it is finally time...

Big Reactors Grid Control Version 4.2.6 has been released!

Changelogs:

 - Greatly reduced the number of API calls for setting reactor fuel rod levels.
 - Fixed a bug where the reactor controller would miscalculate the fuel rod offsets with sub 1% precision.
 - Fixed a bug where the grid controller would not set the reactors output rate to the optimum but leave it as is when coming out of "HOLDING CHARGE" mode.
 - Partially rewrote calibration code for reactors to remove "magic values".
 - The Tabs for "Reactors" and "Turbines" will be omitted if there's not enough space for them (only calculated on GUI startup).
 - Fixed GUI resolution misbehaving on T2 screen setups. The colors are still off due to colorspace limitations on those screens.
 - Fixed grid UI for very slim screen setups. Try a sexy 3x1 T3 screen setup!
 - Added experimental support for mekanism induction matrix. J -> RF conversion ratios can be set in mekanism config.
   Conversion ratios other than 5:2 (J:RF) will confuse the controller.
   The ratio for the induction matrix can be changed in /usr/lib/brgc/energy_storage_component.lua
 - Added support for thermal expansion energy cells.

In order to upgrade from previous versions, you just need to run the installer again.

If you've used BRGC with any ER version between 0.4.5.40 and 0.4.5.45 you might want to upgrade to 0.4.5.46 now and remove your brgc configuration afterwards to recalibrate your setups.

I've changed some of the calibration code for reactors so those might calibrate a lot slower. If you feel calibration does not terminate, please send me a schematics of your reactor.

Also... I can't stress enough how sexy this looks:

It's pure coincidence the spacing works out so well too

Ditto, the 1.10.2 version runs fine with 9 turbines and a reactor. I also noticed that a bug i fixed in brgc makes the active reactor controller run smooth like butter now >_> I'm actually glad I was kinda forced to look at the rod level control code again... ^^"

@ZeroNoRyouki gotcha. (fingers crossed)

If you need input/ideas on anything thread-safety related feel free to hit me up with a pm or something.

Oh so you have to approve posts before they trigger notifications? THAT explains a LOT. Thanks for letting me know

On 22.1.2018 at 5:36 AM, Seiver said:

my reactors refuse to calibrate

 

ER - 0.4.5.44

OC - 1.7.1.43

Sorry for reacting to your post just now. I just got notified about it and as you can see, a lot was going on.

brgcctrl is already telling you what's wrong: You need to supply the reactors address or at least a partial address (read 3 or more characters of the address). Also the API issues we've been discussing here are propably responsible for your reactor not being (properly) calibrated so please wait a while longer until zeros fix is up on curse.

Hmhm,

I hope this "old-direct-call-we-dont-care-about-threads-because-who-knows" doesn't imply: We're not thread-safe

I'll grab it as soon as I can and run it in my test world with some larger setups.

On a different note, I'm currently preparing a new release of BRGC. Here's what's in so far (subject to change):

• Support for mekanism induction matrix
• Greatly reduced the number API calls for setting reactor fuel rods
• Fixed a bug where the grid controller would not set the reactors output rate to the optimum but leave it as is when coming out of "HOLDING CHARGE" mode
• Fixed the Grid GUI for very slim screen setups. A 3x1 T3 screen setup looks pretty sexy now!
• The Tabs for "Reactors" and "Turbines" will be omitted if there's not enough space for them. (Only being calculated on GUI startup though)
• T2 Screen setups finally look good. Resolution wise they're close to the T3 screens now. The coloring for some of the grey is off though. Nothing I can change about it - they're limited like that

If you have anything else you'd like to see - now is your chance!

EDIT:

Here's how T2 screens look now

EDIT2:

It's safe to say that T1 screens are not supported (apart from not having touch controls....)

Oh yeah, that's a thing by now. I should change that as it's "way" easier

58 minutes ago, payonel said:

Read, "where the call takes at least one server tick"

Here: https://github.com/MightyPirates/OpenComputers/blob/f5c19e9e7e0006d3403c7bf0b44dfb970cee8a2f/src/main/java/li/cil/oc/api/machine/Callback.java#L43-L59

THANK YOU!

@ZeroNoRyouki You know about that one don't you? If that fixes things... I need to run around and apologize to ppl... >_>