- Sky
- Blueberry
- Slate
- Blackcurrant
- Watermelon
- Strawberry
- Orange
- Banana
- Apple
- Emerald
- Chocolate
- Charcoal
XyFreak
-
Content Count
401 -
Joined
-
Last visited
-
Days Won
32
Everything posted by XyFreak
-
Fixed, sorry but ACME DNS verification can be a bitch if your TTL is 86400 seconds :/
-
Yeah there seems to be an issue with Lua 5.3 and linux servers. From what I can tell OpenComputers falls back to LuaJ for 5.3 on linux or something. But that is PURE speculation. When I fix my desktop linux I might do some more testing on that.
-
So you already correctly deduced that your OpenOS is too old. I can't help you with the updater though, sorry. You might want to ask for help in the OpenOS-Updater thread.
-
reactor_ctrl.lua line 84 - just add some numbers
-
No, using Big Reactors or Extreme Reactors doesn't matter. If you use steam for something else this IS gonna be a problem cause the program makes all kinds of assumptions based on how much steam is required by the turbines. It does indeed compensate but that's mostly for error correction not for making up for missing numbers
-
Lemme ask you as well: Is there a way I can look into the issue myself / firsthand?
-
I don't think so as the GUI displays the hot fluid tank as full - which wouldn't happen if the bug was active in your case... is that fortunate or unfortunate tho? xD
-
Welp - that clearly rules out any fluid related issues...
-
@Chrisszzyy sorry for not noticing the part where you statet you already recalibrated. I guess I was too focused at thinking what MIGHT help and not double checking. I noticed that your output poly has a max of 9453 mB/t while the reactor I built from your image has 6521 mB/t . Also the calculated optimum is set to 0.01 (wrong) while it has a proper value for me. Is there a server I can reproduce your issues directly on? I'm a bit at a loss here but I also noticed something else with extreme reactors yesterday: @ZeroNoRyouki I'll ping you as well since you might want to kno
-
@Chrisszzyy Thanks, I just built your reactor in my test world and it worked flawlessy. Here's what I think happened: You kicked off everything at once, as you should be able to. This caused the turbines to speed up and the reactor to start calibrating at the same time. Then your turbines went overspeed and got shut down, suddenly causing the reactor to overproduce steam causing calibration to terminate. During the last phase something went wrong when calculating the output curve. I can only suggest you rerun the reactor calibration, assuring the turbines won't suddenly fail. Ca
-
@Moobien You have to let the reactor cool down first. You can easily do that by having it pump out steam (e.g. into your turbine). Also make sure you have enough water.
-
Sounds like you are running an old OpenComputers version - this bug came up before and has since been fixed i believe.
-
1 -> The reason the program has issues with your turbines is that it assumes that it has exactly the correct amount of blades. The formular is pretty simple: total steam = #blades * 25mb/t. Since Your turbine has 72 blades that results in a total of 1800 mb/t, which is too much for your setup and your turbines will go overspeed. 3 -> 350 should be more than fine... if it was over 700 i knew where the problem is but that... seems odd. Something propably went wrong with the calibration. My guess right now would be that it can't output enough steam and thus the program can't collect en
-
@Chrisszzyy first of all, thanks for your feedback. -> 1) Can you go into detail please? Each rotor blade in a turbine consumes 25 mB/t per blade that's attached to the rotor. Unless things have changed significantly, anything more than #blades * 25 mB/t is wasted. The controller should NEVER give your turbine more steam than that. This is mentioned in the instructions. And to be honest.... the method of calibrating turbines is REALLY straight forward. I'm guessing #3 actually the root of your troubles. If your turbines CAN go overspeed (aka you have too many blades) then BRG
-
Ok guys i need more information if you want me to help you. What's your issue? (expected vs actual behavior) What version of OC / ER are you using? (actual mod versions pls) Is your reactor active / passive? What's your reactors layout? => http://br.sidoh.org What does running `brgcctrl service reactor runOnce` do? Are there error messages popping up when the GUI is closed / when you run brgcctrl? Is the grid controller enabled? What does running `brgcctrl service service runOnce` do? Are there external energy components connected? If so
-
@Kyuubi it's something i'd like to fix tho... @Ocelot_ it takes a WHILE depending on how your reactor is built. You can use the GUI to track the rod insertion level to figure out how far it is - it's going to hit 100% eventually and finish shortly after.
-
Can you send me a screenshot of the reactors actual gui right after it errors out?
-
Is it going into ERROR state after calibration? That's the only other thing that can fail.
-
@aliax Exit the gui and please do a `brgcctrl service reactor runOnce` when the reactor(s) are supposed to shut down? Are there any errors popping up? Please repeat with service `grid` if you're using the grid controller (you propably are). @MARTIKRISO Your reactor "overheats" (temp >= 1500) and is flagged as faulty as a result.
-
That's a difficult question but I hope this graph will explain it a bit for you: The blue line is the default config and the red "line" is the max rf/t config. As you can see the power output of the default config will continue to increase until the thermal limit is exceeded and then shut down shortly after. The max rf/t ones power output will increase at first until 2000000 rf/t is reached and then starts oscillating. The resolution of the graph isn't high enough so you see that red block there. The average energy output is somewhere in the lower third of that thingy (pro
-
You're looking for lines 46 and 47 in `/usr/lib/brgc/grid_controller.lua`
-
I'm running out of space there No, every call gets a new table that is created from scratch. The code constructing the table is in reactor_base.lua lines 425 - 467 if you want to take a look at it.
-
Pls check out brgcctrl calibrate brgcctrl calibrate <address here> Alternatively you can always remove the configuration file to reset everything. EDIT: brgcctrl accepts partial addresses (e.g. the first three letters)
-
Well after you extracted the files you can just proceed as you normally would. Keep in mind that the archives are meant to be extracted to the root of your computers filesystem.
-
There is a sanity check in there but if the computer looses control of the flux gates / reactor there is nothing that can be done. For e.g. if the connection to the reactor is lost, it tries to set the output fluxgate to 0 and keeps the input at the last known to be good value. As long as the reactor is still connected and the input flux gate (control over output is lost) It'll keep the containment stable. There's also code that shuts down the reactor but that only happens once the reactor is over 99% saturation. The reason for that is that we don't know if shutting down the rea