- Sky
- Blueberry
- Slate
- Blackcurrant
- Watermelon
- Strawberry
- Orange
- Banana
- Apple
- Emerald
- Chocolate
- Charcoal
XyFreak
-
Content Count
400 -
Joined
-
Last visited
-
Days Won
32
Everything posted by XyFreak
-
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.
-
Hi @Freedbot, the issue is that BRGC has issues with certain reactor designs when you attempt to push past 50% total capacity. You could try to recalibrate the reactor with all turbines connected and see if that helps.
-
Hi @ManinSuit try this:
-
No you will either have to use a loooong cable and chunkload a the entire cable or use some kind of mod that allows direct OC connectivity wirelessly
-
When I tried to update my test instance I noticed that no new version of OC has been uploaded to curseforge yet. That means that the timer bug is still a thing in your OpenOS installations So the "fix" is to downgrade OC (and reinstall OpenOS afterwards) or do the thing at the bottom of my post here That would explain why @ZeroNoRyouki runs into issues as well as all of your "calibration stuck" issues. I'm sorry but that is something I can't fix.
-
Please post a schematic of your reactor so I can investigate the issue. Calibration never took longer than 3 minutes for me (passive reactor). Active reactors calibrate really fast tho.
-
Can you try a "brgcctrl service reactor runOnce" and see if an error occurs? Also a screenshot of the reactors GUI and the layout would be nice.
-
Welp - your setup is a lot bigger than my test setup then xD I'll look into it. My guess is that they run into an error while they're being spun up to optimal rpm? I'll try to free up some time to build a new setup and debug the issue. Also... maybe scrollbar
-
Scrolling support, eh? maybe Sounds easy, right? Fricking hard to actually do. If your turbines run straight into "error" mode then you have more turbine blades for your coil. BRGC assumes that if your turbine has enough blades to support X mB/t then your coil does too. EDIT: That being said - if that's not the case and everything SHOULD work but its not then its a bug
-
@ZeroNoRyouki The program assumes that whatever fluid gets produced, can be consumed by any connected turbine as long as it doesn't cap out the internal capacity. The power balancing might actually be an issue - but the fix would be: Don't attach ports if you don't need them.
-
@BattyCynris Sorry for the delay i JUST got the email notification that you posted something. You are running into an OpenOS issue that should be fixed by now (see posts a bit "earlier" on this page). Please update OpenComputers and then reinstall OpenOS.