- 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
-
@steel720 that's a bug, you can just turn on the reactor again directly after that and it'll work just fine.
-
Hey guys, my email inbox told me that something is going on here First of all, you CAN use the same controller for multiple reactors. No problems there. However the GUI will only show the first reactor because I never implemented that. I've heared that in some cases, the adapter addresses may change and the analyzer will read out the wrong addresses. Please compare the addresses of the adapters to the output of the "components" command. If they're indeed different, this is the second time I've heared of this. Also if you are on a server, make sure the computers stay turned
-
Can you do a brgcctrl service turbines runOnce ?
-
xD good luck. If you have any questions just send me a pm. I can't promise I'll be able to help you but I'll try. Start off by serializing and sending the data from the controller. OC has a serialization library so you just need to call it. As soon as you got that part right, you shouldn't accidentally blow up your reactor :P.
-
Don't worry about it. The main issue with the whole networking thing is to get it done properly. A quick and dirty hack is always easy but that kind of code isn't really what I'm aiming for. If you want to try to do these modifications, here is how you do it the hacky way: Make the actual controller serialize and send its reactor info object over to a computer that is to draw the gui. Modify the gui so that it no longer starts the controller locally. Have the gui instantiate a controller object. You will be feeding it data in a bit. Do it like this: local dra
-
Which is exactly what i just wrote
-
No easy way, sorry. There is a hard way of course, which includes writing your own provider service and modifying the gui to get its data from this service via OC network messages ;).
-
That is what i originally intended to do but never got around it (the GUI part). As for the server displaying stuff: This is not going to happen unless i rework my networking stack first. You see, I wrote a networking stack that allowed computers to discover services and route packets (i.e. to linked cards), which allowed my tablet to access my whole OC network. Unfortunately I need to rework some parts of it for OC 1.6 (i think it was? yes its old(er)). IF I ever make the reactor control programs network aware, I'd be using this stack. The reason is simple: Service Auto Discovery.
-
Well connection failure means that components.proxy failed to create a proxy object to the reactor. This is usually because the reactor address is wrong. Now... appearently it's not? Could you please do a quick "components" command? The reactor should show up there.
-
They're not and yes I forgot to change the guide for 1.7. That's fixed. However, your reactor address is wrong or OC can't access it (you should double check that). Anyways It seems i forgot a null check there. Thanks for noticing
-
This looks like a bug i already fixed >_>. Let me doublecheck.
-
Hmm ok... maybe something is wrong with the configuration loader.... that thing is going to be revamped anyways. Thanks.
-
Uuuuuh.... ups?
-
Ok guys I'll post the "solution" to @JustCallMeJick s problem here for everyone to read. RefinedStorage is NOT able to transfer steam fast enough on its own. It COULD do it because it is able to transfer large amounts of liquids at once, but it only does it every other tick. Unfortunately, turbines only have enough steam tank capacity for 2 ticks at full steam (see what I did there xD). RS seems to transfer liquids every 4 ticks (that's a guesstimate, not something I actually verified). The result is your turbines not running faster than half their speed. The catch here is that
-
@JustCallMeJick please do. If you need a drop off space for the world file please send me a PM and I'll give you some. @Programeditor I see two flaws there with your setup: Your turbine goes over speed. Anything above 1950 RPM is considered a failure. Your reactor gets too hot. This is usually caused by your steam transfer rate being too low. This might be induced by the turbine being shut down though. -XyFreak EDIT: Fixed my grammar.
-
Ok thanks. Please try to remove /etc/br_control.cfg file and reboot the computer. It looks like something went wrong during reactor calibration.
-
Well the reactor outputs 3.53 B/t, which is obviously not 4 B/t. What I'd like to know is whether the actual generation rate is too low (e.g. the steam tank in the reactor being empty) or if the steam isn't transfered fast enough. I don't know how fast RS can transfer liquids so... There's also a possibility that the energy extraction from the turbines to the capacitors is too low and the controller adjusts the output.
-
@JustCallMeJick Can you make screenshots of the turbines and reactors gui? This looks....odd.
-
@magi_nator currently, no @shikamaru looks like you haven't started the controller services try a brgcctrl service all start
-
Ok thanks, I'll look into it. In the meantime you can just remove /etc/br_config.cfg and restart the computer to cause everything to be recalibrated.
-
brgcctrl calibrate <address or partial address> The first three letters of the address will usually do.
-
@sedstr Do both turbines get set to 800ish RPM? If so, can you make sure the controller managed to calibrate your reactor correctly? As in: what steam inputs are your turbines set to and how much steam is actually produced by the reactor. For the usual setup you are required to connect both turbines and reactor so the controller knows how much steam it has to produce (i need to optimize that code a "bit"). What YOU want is propably: Connect the reactor only Do NOT start the turbine controller Manually set the "steamtarget" to 4000 with "brgcctrl steamtarget 400
-
@vik2or Thanks for your input. I talked about this with a friend yesterday and we also came to the conclusion that idea 4 is the best way to do it without doing any statistical analysis (which would be way over the top). The gui is currently set up in a way where it will bind an unused monitor to an unused gpu if it finds multiple of them. So if you have two monitors/gpu then it will draw on the second one and fall back to shell on your "primary" monitor. Unfortunately I never intended libGUI to draw on multiple screens so I would have to rework parts of that. It's propably not gonna
-
Hi guys, it's time for a status update. Obviously I didn't manage to get everything ready within the timeframe I hoped to do it. So instead I'll post a quick status update. I'm done refactoring BRGC. BRGC is now caching and calculating a lot more in advance. The caching allowed me to eliminate a LOT of API calls into Big Reactors/Extreme Reactors which should lower the overall load of your actual game server a bit. While this shouldn't matter in practice (it's not like it had any noticable impact to begin with) I'm hoping that this will stop triggering those server crash
-
@vik2or Thanks for your input. As I said before the lua program should not be able to kill the server. We're either triggering a bug with OpenComputers or a bug with Extreme Reactors. I'm going to have a look once I'm done refacturing/rewriting some compoments of BRGC that'll allow you to include external storage devices into your grid. If I have a surefire way to reproduce it (I think with your input it can be done quite easily...I hope...) I'll also file a few bug reports or support already existing ones to the best of my abilities. I'm aware of the autostart issue