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


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by XyFreak

  1. Nice^^ 1.02 drainback is not safe for servers tho but even getting that up to 1.05 or even 1.1 won't really reduce the numbers that much.
  2. @Aquila_chrysaetos The link itself was wrong so i fixed that. You'll have to use the link from the page. Also your browser might've cached the page so try to do a force refresh (SHIFT + F5 i think?). https://tenyx.de/draconic_control/draconic_simulator_64.exe (spot the difference :P)
  3. @ZeroNoRyouki Uh..yeah^^ that function is kinda important^^ If you intend to rename that, could you let me know in advance? I'll just look for either of those methods then and call whatever is available to me. Thanks ^^
  4. @Aquila_chrysaetos thanks for letting me know! It looks like i screwed up the links.... wow.. this must've been broken for a LOOOOONG time. Everything is back up and in order now
  5. /me points at the last line of the changelog
  6. Big Reactors Grid Control Version 4.2.8 has been released! Changelog: - Use threads/coroutines for heavy calculations on calibration data. This'll fix the "too long without yielding" errors. - Hopefully fixed an issue where the controller gets confused by the massive internal energy storage of draconic evolutions energy relays. NOTE: If you see errors regarding the controller not being able to find "thread" you'll have to upgrade your OpenOS! If you're upgrading, you'll have to re-download the installer because it is now fetching an additional package!
  7. Ok guys I have a working solution in the pipeline... It might break old OpenOS instances though so you better be prepared to upgrade that / reinstall the computer I'll see if i can squeeze in another smaller bugfix as well so stay tuned - fix should be out either in an hour or tomorrow
  8. Looks like that didn't get it any further... thanks.
  9. @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.
  10. 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
  11. @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
  12. 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.
  13. @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.
  14. 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.
  15. @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!
  16. Hi @traeck, this is a bug in versions prior to of Extreme Reactors (we think). Please upgrade to or later. EDIT: I got my versions wrong... >_>
  17. 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...
  18. 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.
  19. Ok, i know what's happening... trying to figure out what I can do about it. Thanks for letting me know.
  20. Thanks @BrisingrAerowing Looking into it right now!
  21. 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.
  22. @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
  23. 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.
  24. ->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
  • Create New...

Important Information

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