Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

XyFreak

Members
  • Content Count

    408
  • Joined

  • Last visited

  • Days Won

    30

XyFreak last won the day on December 2 2018

XyFreak had the most liked content!

5 Followers

About XyFreak

  • Rank
    Leading Member

Contact Methods

  • Minecraft
    MC_XyFreak

Recent Profile Visitors

3929 profile views
  1. @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 ).
  2. 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 generation rate also has a hard limit at each given fuel percentage (I don't know the numbers off the top of my head but they're suprisingly low) so I don't think we'll get much more out of it. EDIT: I just did the math - the MOST a draconic reactor can generate is 3 million RF/t - and it will decide to go boom that exact same tick. That means the 3.5 million RF/t figure is picked from the initial discharge propably... kinda disappointing but yeah - 3 million is the hard limit for sustained power gen.
  3. 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 danger notification flashes for a bit before it then displays BURN MODE. ¯\_(ツ)_/¯ Also I don't think I'll be adding numbers to the bars - the UI was designed to match the reactor UI and most of the raw values are displayed at the center - even some things that have been removed from the reactor UI after 1.7.10 ;). One of the issues is that the bars would require a lot more draw calls to actually draw them and unfortunately those are extremely limited with OC. I don't want the DC GUI to flicker or worse - steal ticks from the controller.
  4. 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 a value of 1.1 which yields a containment of about 9% iirc and I would not go below that if you want to be able to safely shut your reactor down at high chaos rates (and you want a lot of chaos in your reactor cause more chaos = more energy). For 50% you'll need to set drainback to 2. For 75% you'll need to set drainback to 4. For 87.5% you'll need to set drainback to 8. You get the idea - it's exponential. And as the drainback setting directly corresponds to how much energy is fed into the containment field, this means that you'll be using ~82% more energy on it going from 10% to 50%. If you are using the setting with the burnRFt setting then you are using the setting that maximizes the RF/t you get out of your fuel. I've not been able to get the reactor to output considerably more RF/t without going into regions where the reactor might fail eventually in simulations (not saying it's not possible - I've just not found the right configuration). The setting without burnRFt actually yields a suprisingly high efficiency while also generating a lot of RF/t. If you feel really uncomfortable with your reactor running REALLY hot and your containment being so low you might go with the latter config. Also a little hint: When refueling the reactor, pull out just the big chaos chunks and leave the medium and small ones in - more chaos in the begining equals to less time with low RF/t (as more chaos = more energy). EDIT: The settings have been tuned for high RF/t which also translates into low runtimes while not wasting an excess amount of fuel. If you need a lot of chaos fast you can make a "safe" breeder with DC that is mostly self powered and sputs out 8 large chaos chunks within 23hrs IIRC. And if you hook them up to an external power source 4hrs for 8 large chaos chunks are possible while being semi-safe*. *) Insane amounts of powergen required to keep the containment field up. The author of the software is not responsible for loss of base, world or sanity.
  5. @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.
  6. 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.
  7. 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
  8. The downloader requires an insane amount of ram so you might have to give it more sorry it's... not well designed ^^;
  9. @Dankhus The reactor get's too hot and the program assumes there's a problem. Either there's a problem with your reactors design or with fluid transfer.
  10. There's a comma missing at the end of the "fluxGateDrainbackAddress" line
  11. Hi @KnockOutGamer There is no additional work required for 1.12.2. If you get the message, you propably have a typo somewhere.
  12. @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 energy than you can efficiently produce. Meaning: Turbines will always run at peak efficiency or are halted. Reactors SHOULD always run at peak efficiency except when you just need more power.
  13. @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 checked )
  14. 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.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.