- 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
-
So it seems @BrisingrAerowing opened an issue on the OC github (https://github.com/MightyPirates/OpenComputers/issues/2632). Since you kinda ruled out the @Callback annotation (tbh. I also think those are rather neat), the issue title / description is not really up to snuff, but this thread is linked so things should be fine...
-
Ok i got different versions working on my notebook - guess I screwed up last time... Results: OC 1.6 + ER 0.4.5.44 = bad OC 1.7 + ER 0.4.5.21 = good OC 1.6 + ER 0.4.5.21 = good OC 1.7 + ER 0.4.5.44 = bad OC 1.7 + ER 0.4.5.30 = good OC 1.7 + ER 0.4.5.41 = bad Upgrading forge did not change the results.
-
Nice work >_> I don't want to rule out the adapter thingy, but computronics also requires you to use adapters and it suffers from the delay as well. I don't think the JIT does anything here as it's not really aware of the game logic, is it? Since the delay always seems to be one tick and the game itself doesn't freak out... it should be fine. My money was on the "@Callback" thingy tbh.... Here's some more hints: This configuration works: ER 0.4.5.21 OC 1.6.1.6 Forge 12.18.3.2185 As you can see that's before the API rewrite and before
-
Quick results: Computronics uses an Environment with @Callback public static class OCDriver extends DriverSidedTileEntity { public static class InternalManagedEnvironment extends ManagedEnvironmentOCTile<TileCapBank> { @Callback(doc = "function():number; Returns the average storage input per tick") public Object[] getAverageInputPerTick(Context c, Arguments a) { return DriverCapacitorBank.getAverageInputPerTick(tile); } And Mekanism does not. Mekanism implements the "IComputerIntegration" Interface. So its "invoke" function gets called and....done. Now I
-
Hi @ZeroNoRyouki Thanks for showing up. Good to know you're taking this serious. I mean it. Thanks. I'll also try to poke around a bit. Though I'm not really familiar with the OC internals ^^; Knowing it's not your code but something in between is also really valuable information. I'll look into computronics code and see if they're also using OC Environment + @Callbacks and if Mekanism does something similar to DE. If so - that should reinforce your hunch.
-
Unfortunately, this is not correct. Running the controller in larger intervals would devastate its ability to keep the reactor output leveled. For smaller to medium sized passive reactors this wouldn't really be an issue. Active reactors however would constantly overproduce steam - then get their output cut and underproduce steam. Something similar would happen to larger passive reactors. My point was that in the past you could run BRGC litterally every tick with no additional lag introduced by outside factors whatsoever I've run my test program (last post) against turbines and they have
- 852 replies
-
- 1
-
-
- gui
- controller
- (and 2 more)
-
@Tahak Thanks for the github issue. Unfortunately, I don't have a github account so I can't answer there. Now I don't want to do any finger pointing either. However, you can see the computer yield by writing a program as small as this: local component = require("component") local computer = require("computer") local myTestComponent = component.br_reactor for i = 0, 10 do local ts1 = computer.uptime() myTestComponent.getEnergyStored() local ts2 = computer.uptime() print(string.format("%1.0f", (ts2 - ts1) * 20)) os.sleep(0.05) end This program will run for 10 11 iterati
-
Ok guys - good news and bad news. Good news first: Implementing @BrisingrAerowings request was easy. It is already done in my latest dev version. Infact - I did it on stream Now the bad news: I've been able to reproduce this "computer is slow" issue with newer modpacks. And I'm 99% sure this is extreme reactors related. I can confirm that this behaviour starts with ER 0.4.5.40. Earlier versions of it won't work with OpenComputers 1.7, because of some Forge version incompatibility. Earlier versions of ER will just crash with the forge version OC needs now. Now for the cause:
-
@BrisingrAerowing https://www.dropbox.com/s/16t3my6dc10kgn4/IMG_20171031_224858.jpg and yes
-
No, the grid controller just hooks into the other components and takes over control over some parts. If anything, not using that should make the computer run faster.
-
That's the default. 1:1 is easily possible. Try this pls: Disconnect all reactors and turbines Stop the controller Remove /etc/br_control.cfg Reboot the computer Start the controller Open brgc_gui Connect all reactors / turbines at once
-
Hmm - how many reactors / turbines are connected to the controller? The most I've seen running was something like 3 reactors and 9 turbines. Also, if you're on a server with other ppl, OC might be set up to only use a very limited amount of time for its computation thread so there might be a bottleneck here.
-
Sounds like you're using a T1 CPU. I've only really tested the program with T3 CPUs. T2 might work if you're starved for resources but I haven't tested that.
-
Check this out: I haven't thought of that! You can cycle between Lua versions by holding the CPU in your hand and right-clicking into the air. I've tested BRGC with Lua 5.2. Someone once ran into a Lua 5.3 issue and I fixed it and did a bit of testing on 5.3 so it should work just fine on 5.3 but I'm not 100% sure on that one. Its definitely worth testing.
-
Hey guys - I JUST got a bunch of notifications from the OC forums so... I'll go through them now...pretty late if you ask me. Anyways: My desktop computer is broken. I'm building a new one. The parts are on the way. No data has been lost. I'll resume development once everything is up and running again. @CrazyDolphin I don't know whats wrong right now but it seems you've connected a looooot of stuff. Can you replace the tier 1 component card with a tier 3 one and/or put in more? I'll try to reproduce the issue once I have a working desktop again I'll
-
Well BRGC also has something like that, the regulation takes place on the energy, not the RPM Especially since max efficiency turbines peak out at 1780 RPM Also: @Ghan is 100% correct.
-
Not right now, no. I'll have to include the fuel levels into some decisions - that's going to require a bit of code changes here and there. I'm kinda burned out from traveling all over the place this weekend so... no code is going to be written for BRGC this week, sorry.
-
Its always prefering the one it thinks has the best efficiency. Since there is a lot of randomness going on, two identical reactors are never calibrated to exactly the same values. Even recalibrating a reactor may yield different results.
-
@blunge Sounds like it temperatures are jittering too much. I've gotta find a different way of finding "the" stable state.... @corbanj6534 If your reactors run out of fuel, the grid controller gets confused (or rather - it doesn't care). I'll put that on my TODO @Ghan Thanks for your input. A few pages back where I talked about the "overdrive" mechanic I've stated that I do not want to add a lot of state to the controller because that makes it increasingly harder to debug. I'd rather use an incredibly complicated algorithm that uses very little state than
-
Correct
-
@corbanj6534 Absolutely, yes. You can mix types of storage components as well. Just make sure they're all connected to the same power network.
-
Hi @Gepetto, Lets start with the easy part: -> 3) You can safely edit the files with tab characters. It's just a display thingy. Now to the odd part: -> 1) Good catch - there is a bug in the grid controller init script: It forgets to initiate scanning for energy storage components on startup. However that raises another question: Why does it even find the energy storage blocks on computer startup on my test world in the first place? -> 2) I didn't read your EDIT at first and went bug hunting. But.... BRGC measures the energy that is output from your energ
-
Ok - again for everyone here. BRGC does NOT work with your CPU set to Lua 5.3 right now. I have to at least change all my string.format uses throught the entire code for that to work. So unless I release an update: Do not attempt to use Lua 5.3 if you want to use the GUI. The controller itself works perfectly fine on 5.3 though.
- 852 replies
-
- 1
-
-
- gui
- controller
- (and 2 more)
-
The good news is: The controller itself seems to be working. The bad news is: While I know WHAT is happening (thanks to your big screenshot of the libGUI error), I don't know WHY. Essentially the rate with which RF is extracted from your reactor is calculated to be NAN. Of course getting NAN is simple: divide zero by zero, divide by infinity or use NAN in a calculation. And yes, there is a division in there somewhere but that one can't devide by zero. I made sure of it. The only numbers I get which are not under my control are the ones from extreme reactors. And I'll just assume thos
-
@Humpledink This looks like either a nil value is stuck somewhere. I need some more info here: What version of minecraft are you running? What does your setup look like? Also can you try to run brgcctrl service reactor runOnce and if that errors out please post the message? Thanks.