- Sky
- Blueberry
- Slate
- Blackcurrant
- Watermelon
- Strawberry
- Orange
- Banana
- Apple
- Emerald
- Chocolate
- Charcoal
XyFreak
-
Content Count
400 -
Joined
-
Last visited
-
Days Won
32
Recent Profile Visitors
6764 profile views
-
kcinnaJlol reacted to a post in a topic:
Big Reactors Grid Control
-
Spielepapagei reacted to a post in a topic:
Big Reactors Grid Control
-
Hey, sorry for the radio silence - at some point i stopped getting notifications when someone posts here I have just pushed an update that should fix a lot of issues with 1.12.2 (better late than never). It also fixes a bug that messed with the calibration itself (it should actually be accurate now). Now to answer some questions It is not possible to have the GUI displayed on multiple monitors. Output only works to one monitor. I also can't hack that in reliably because there's not enough in-game CPU cycles to draw the GUI twice without flickering and run the contro
- 852 replies
-
- 1
-
-
- gui
- controller
- (and 2 more)
-
@NotHappy I imagine that Computronics forces the computer to yield for every API call (thread-safety yadda yadda) so when you have a lot of cells connected it gets REALLY ugly. I suggest using less components for energy storage. To fix this ThermalExpansion would have to implement the OC API and do so in a thread-safe way ( aka that's not gonna happen ).
-
With the tuned setting on average a max fueld reactor outputs just under 1.7 million RF/t average over its runtime if you include the shutdown phase, netting a total of 1.85319e+13 RF over the course of roughly 7 days. That's a lot of RF. Also you'll get chaos so you can just build... more? If you forego the UI one fully blown server can support like 20 reactors. The max peak RF/t I've gotten out of the thing without it going boom is just under 3.5 million RF/t. Note that there is a hard-limit in the code restricting the extraction of energy to 1/10th of the maximum saturation. The energy
-
Hey, if you're not cool with the high initial temperatures then you can set the burnRFt to 0 - it's a setting that runs the reactor extremely hot and inefficient at first to get the energy output going. I don't remember the exact code but I think the reactor itself will not blow below 20000C - at which point it will just go boom regardless. The thing is that above 8000C the energy requirements for the shield start to explode and get really out of hand above 10000C (9000C really). But it's still fine as long as you can power the shields. I am aware that with the maxRFt settings the da
-
Hey @KangyKSLG, the config has a drainback setting that will determine how much of the field-drain-rate is fed back to the reactor. This has to be >1 for the shield to not collapse and is not linear (so 1.25 does NOT mean you'll end up with a 25% shield). The default of 1.25 yields a containment of roughly 20%. I'm sorry for saying this but 50% is a HUGE waste of energy as all you really need is something >0% (e.g. 0.1%) for the reactor to not blow ( and while you CAN make DC do that I do NOT recommend it ). But yeah you can play around with that setting. The tuned config uses
-
@pierrecastor I don't know for sure but the issue appeared very early on in 1.7.4 and was only resolved with 1.7.5 so I'd assume yes.
-
BRGC uses as much steam as the blades in your turbine support. Your turbine needs to have enough drag (aka coils) so that it doesn't go overspeed. You either don't have enough coils or you have too many blades.
-
There is not. BRGC will push as much steam into your turbines as its blades can take. You could remove some blades to have BRGC push in 450mB/t or 425mB/t
-
There's a comma missing at the end of the "fluxGateDrainbackAddress" line
-
Hi @KnockOutGamer There is no additional work required for 1.12.2. If you get the message, you propably have a typo somewhere.
-
@stealth95l The grid controller drains your energy storage until it's below 20% and then carges it until it's 95% full. It does so by tweaking energy production to be just shy of what you are actually consuming for discharging and just a bit more when charging. The assumption here is that for charging, less production is more efficient overall, and keeping your energy storage filled for longer improves responses to sudden power surges. Note that it will always drive your components at their peak efficiency, unless you have passive reactors in your system and are requesting more
-
@stealth95l Well it's just blindly dividing by 0 so... *cough* woops. 0 would be wrong btw - it should propably display "---" or maybe "not connected". @bjonnfesk You have OpenOS 1.7.4, which is bugged - you'll need to update OpenComputers or use the OpenOS updater. This has been discussed here quite a bit. BRGC is not on a public git repo because I never wrote a "build script" so I just checked in the entire OpenOS installation *cough* and use my package builder to build and upload the different libs and packages from the running installation *cough*. ( I should get that cold c
-
Nice, thanks
-
There is no particular safety check in place - it's just that the system itself stops working properly at some point. There is code in place to mitigate some of it but unfortunately it's something that's nothing I can easily fix. The internal capacity is based on the reactors size but caps out at 50B. What you could do is build a second reactor and BRGC is gonna split the load.
-
The main issue is that the internal steam capacity is limited to 50B so as soon as you hit >25B/t steam and it's no longer possible to level out at 50% (25B) everything kinda goes downhill.