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

    • Lizzy Trickster

      Latest Stable OpenComputers Version   11/26/16

      The latest released version of OpenComputers is version 1.7 for MC 1.7.10, 1.8.9, 1.9.4, 1.10.2, 1.11.2 & 1.12.1. See more information here! Beta/Dev builds can be found at the Jenkins Build Server (ci.cil.li)


  • Content count

  • Joined

  • Last visited

  • Days Won


XyFreak last won the day on July 24

XyFreak had the most liked content!

1 Follower

About XyFreak

  • Rank
    Leading Member

Contact Methods

  • Minecraft

Recent Profile Visitors

1082 profile views
  1. Big Reactors Grid Control

    Ok i got different versions working on my notebook - guess I screwed up last time... Results: OC 1.6 + ER = bad OC 1.7 + ER = good OC 1.6 + ER = good OC 1.7 + ER = bad OC 1.7 + ER = good OC 1.7 + ER = bad Upgrading forge did not change the results.
  2. Big Reactors Grid Control

    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 OC Forge As you can see that's before the API rewrite and before OC 1.7. For whatever reason I can't get the new ER version to work with OC 1.6 or OC 1.7 with the old ER version. I'll try to play around with versions some more in a second....
  3. Big Reactors Grid Control

    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 also checked DE myself and...yeah - it does things pretty similar to how mekanism does it - it's wrapped up a LOT nicer tough. EDIT: Yeahyeah - IComputerIntegration is a mekanism-specific interface
  4. Big Reactors Grid Control

    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.
  5. Big Reactors Grid Control

    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 the same issue, unfortunately. They require a lot less API calls to control though (BRGC sets each fuel rod individually to achieve finer grained control over the output capabilities). Recap: Reactors + Turbines are affected. ER is not the only mod with this behavior (-> computronics) There are mods without this behavior (-> draconic evolution, mekanism) We have a very small program to check on ... lets call it: API call latency The issue has been observed on 1.10.2 at least (I've not yet tested 1.12) This is pretty much everything we can do without diving into the mods code and comparing how the OC API is implemented here vs DE or mekanism to figure out what's going on. If this goes on for a bit longer I might end up doing that this weekend.
  6. Big Reactors Grid Control

    @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 iterations, calling "getEnergyStored()" and calculate the number of ticks it took to process the call. If you execute the program with a reactor connected, this will print you a bunch of 1s. If you connect a ... lets say... draconic orb and used local myTestComponent = component.draconic_rf_storage instead, you will get a bunch of 0s. Same for the mekanism induction matrix btw. Now I DID notice the same 1 tick cost when accessing components via computronics (ender io capacitor bank), so I suspected this to be an OpenComputers issue at first - but since i got at least two other mods running just fine....this can't be the (whole) issue, can it? Also, removing computronics doesn't change this behavior. As for "other programs run fine". I do believe that. Any program that has a slow cycle time would (a) not cause so much noticable lag and (b) won't be affected by the caused lag (much). That being said, I haven't tested the mentioned program but given the really minimal example above I'm pretty sure it still causes lag / issues, which just aren't as noticable as with BRGC and its "insane" cycle time of running every 10 ticks. As a side note: I had BRGC run on every other tick for fun during development on 1.7.10 . Worked fine but the controller took too much cpu time from the GUI... and anything else for that matter.
  7. Big Reactors Grid Control

    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 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: Each time BRGC calls just one API function from extreme reactors, the computer is forced to yield for 1 tick. Since BRGC does like.... 7 or more calls per cycle per reactor/turbine and wants to do so every 10 ticks.....you can imagine what's going to happen. If this is a bug, then this has to be fixed. If this is intended, however, then I have to suggest removing computer ports from ER entirely - and I'm going to scrap this program because it'll be unusable (as will any kind of program controlling extreme reactors more than just turning it off and on - which can be done with redstone as well). We'll see..... -XyFreak EDIT: Link to the Twitter thread I started: Hopefully we're going to get more information soonish...
  8. Big Reactors Grid Control

    @BrisingrAerowing https://www.dropbox.com/s/16t3my6dc10kgn4/IMG_20171031_224858.jpg and yes
  9. Big Reactors Grid Control

    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.
  10. Big Reactors Grid Control

    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
  11. Big Reactors Grid Control

    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.
  12. Big Reactors Grid Control

    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.
  13. Big Reactors Grid Control

    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.
  14. Big Reactors Grid Control

    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 also look at the issue where BRGC doesn't allow reactors to output as much steam as you want it to. My money is on your reactors temperature. Anything close to 700°C (IIRC) for an active reactor is going to cause BRGC to throttle.
  15. Big Reactors Grid Control

    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.