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.1 for MC 1.7.10, 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)
    • Lizzy Trickster

      !!FORUM DOWNTIME!!   01/16/18

      On 2018-01-27 the forums will be going down at around 1100 GMT0 for up-to 5 hours to allow for hardware configuration changes on the system that hosts these forums as well as various updates to patch recently publicised CPU vulnerabilities. Apologies for the inconvenience that this will cause.  If you would like to keep up-to-date on the progress of the work, join our IRC channel (http://webchat.esper.net/?nick=&channels=oc) or our Discord ( https://discord.gg/0hVukoQ2KYifZFCA ).

XyFreak

Members
  • Content count

    216
  • Joined

  • Last visited

  • Days Won

    22

XyFreak last won the day on July 24 2017

XyFreak had the most liked content!

2 Followers

About XyFreak

Contact Methods

  • Minecraft
    MC_XyFreak

Recent Profile Visitors

1311 profile views
  1. Big Reactors Grid Control

    @hron84 I think I'll make it so it hides the "Reactor" and "Turbines" buttons on lower resolutions.. that should do the trick. Thanks for the TE cell thingy. @afr33sl4ve I need a way to rebuild your reactor in my test world so a schematic would be nice.
  2. @dsplzion What version of draconic evolution are you on?
  3. Big Reactors Grid Control

    Hey guys, @afr33sl4ve I need some more info on your setup in order to figure out what's going on here. @hron84 I have to admit I've only ever tested the GUI with T3 screens. If the resulution doesn't stack with multiple screens, then yes, ever since I introduced the grid controller, you'll need T3 screens
  4. Big Reactors Grid Control

    Hi @afr33sl4ve. You can hit the "CHARGE" button that's in the "Grid" GUI. That'll instruct the controller to fill up the energy storage. The behaviour you're seeing is improving overall efficiency of your power-gen. I don't think there's an issue unless you're running into out-of-power situations due to this - In which case I need to come up with something.
  5. @ClownApocalypse If you've actually done everything correctly, then I'll have to take a look whether the API changed or not - though I don't think it did. "Connection Failure" means exactly what you might think it means: It can't contact one of the components. Please double-check whatever you did with https://tenyx.de/draconic_control/. ESPECIALLY the configuration part. Please make sure there is no typo in the keys as well. Also please try to reboot your computer (although I'm pretty sure you already tried that ).
  6. Big Reactors Grid Control

    I'm pretty sure this program is also pretty slow, however, since there's not much interaction, you won't notice anything. The cycle time of that program seems to be one second. If the screen doesn't refresh every second, you're expieriencing the same issues. But since this program only turns on and off turbines/reactors, without actually regulating the components themselves, it works mostly fine. And the only user-interaction you have is shutting down the entire thing.... so.. yeah ^^
  7. Hi @MetalKluG, you might've double checked the addresses, but you didn't do that for the "variable" names Looks like you misspelled "fluxGateDrainbackAddress"
  8. Big Reactors Grid Control

    Hi @Gravydigger, this looks like your installer download broke. Please remove it (rm brgc_installer.lua) and get it again.
  9. Big Reactors Grid Control

    I've confirmed this issue to be present on OC 1.6.x as well EDIT: I used 1.6.1.6 for my 1.6 tests EDIT2: So...uh.. my point was - I agree it's definitely not a 1.7.x problem
  10. Big Reactors Grid Control

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

    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.
  12. 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 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 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....
  13. 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
  14. 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.
  15. 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.
×