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


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by XyFreak

  1. I don't see anything wrong, no. "waiting for server" usually means that you have tickrate problems. If your server keeps spamming the exception you posted earlier tho, this would explain why your tps is basically non-existing ;). We'll have to wait for Zero to show up so he can take a look at the extreme reactors code as your pastebin points towards there being a problem.
  2. @ZeroNoRyouki I think you might've forgot to check for a 0 somewhere
  3. @Will135 you're most likely seeing a limitation to what the API can handle for rftools. I'll look into it but it's extremely likely, that I can't fix it. For the capacitor bank you literally just need that mod installed. Afterwards just use an OC adapter as you did with rftools.
  4. @Draaven that issue is actually related to the old version of the ER API, you will have to upgrade ER (to or higher) in order to fix this issue if you want to computer control ER stuff. Personally I only managed to reproduce this issue with turbines but I guess it can happen with pretty much anything.
  5. Currently there are no plans to do that. Fun fact: the installer already downloads packets but it doesn't actually act as packet manager. The whole thing originally emerged from my "xypm" which was able to get packets from the internet tunneling everything over OC network and allowing computers without internet cards to ... install packets (as long as there is a computer on said network with an internet card). My plan is to revive that but...heh.. dunno when.
  6. Just update lol, as you can see the issue will be fixed in the next OpenComputers dev build so no need to report it anymore. The BRGC update includes a hack that makes it work for now. EDIT: Alternatively you could change your CPUs mode to Lua 5.2 but .... I fear I have more 5.3 related bugs in my code due to behaviour changes (like the format one) so... the more ppl use 5.3 here the more of those bugs are found so that's a plus.
  7. I'll make it official now. Big Reactors Grid Control Version 4.3.1 has been released! Changelog: - Now using the new ER API ( and higher). Old API is still supported. - Implemented further mitigations for the "too long without yielding" issues. - Included a hack/workaround for a bug with OpenOS 1.7.1 (and earlier) and Lua 5.3 mode. - Fixed a bug where attempting to format a number as an integer (illegal in Lua 5.3 mode). I'm sorry for abusing some of you as beta testers
  8. Yes, definitely. Right now 1.12 is propably the most important version... I guess.
  9. @payonel I figured I can do that after seeing your commit. I'm debating whether I actually want to include hacks affecting _G in BRGC tho..... maybe I will just to avoid this issue coming up more and more.... tough call ^^ thanks tho EDIT: It's done, I put it in my "promise" library (where uuid is used)
  10. @payonel sweet I'm glad we're finding real issues now and not just me being supid / jumpy
  11. Ok the issue has been fixed @Dreytac @sanovskiy, sorry for missing that... that was stupid of me...
  12. @payonel The uuid library appears to be accessing bit32, which for whatever reason has not been defined. See here: EDIT: please note that I can NOT reproduce this with version EDIT2: I took a quick look and it appears bit32 has been removed from lua 5.3, so uuid will work in lua 5.2 mode but not 5.3...
  13. @sanovskiy I also found the issue thanks to @Dreytacs screenshot. I feel stupid now. My linter even warned me about this... gonna be fixed in a few minutes EDIT: NVM the "few minutes" part, my test world no longer loads...
  14. @Moobien Looks like you ran into an OpenOS bug. Please report it to the OpenComputer guys One COULD do that but i won't. For now. @SpaceBeeGaming That's good to hear
  15. @ZeroNoRyouki awesome! thanks @Moobien yeah i'm looking for the issue in screenshot 2. However you ran brgc_gui there which lowered the screens resolution so i can't see the top of the stack trace, which is what i actually need :P. I assure you the error should pop up even without running the GUI so...i need a screenshot for that However I think your explanation gave me a hint to what's going on.... shouldn't happen but might. Lemme take a look. Still, I'd really like a screenshot where brgc_gui never ran / was terminated before the issue occurred
  16. Ok I just ninja updated BRGC. It's now using the new API but can still use the old one. If one or two ppl could confirm that stuff is still working for you that'd be great. I've also tried to make the "too long without yielding" issue less likely to occur so... there's that. Without knowing what exactly is causing https://i.imgur.com/1eV8hJj.png don't actually want to call it RELEASE! time yet tho.
  17. @Moobien can you please run BRGC without the GUI so you can screenshot the full error? That'd really help. Thanks
  18. I feel like i fixed that one eons ago. What LUA version is your OC CPU set to? It should work with both but...you know.... EDIT: the format one. The third one is something else
  19. Hey @m_2018 The default presets take quite a while to get going. What's "slowing you down" is the energy saturation target. As you can see, it's kept at a constant 50%. As fuel conversion increases, energy generation increases as well so that's where the gain in energy generation comes from. You can set the saturation target to something lower (without touching the throttling) to speed everything up if you want. The default presets are only meant for making sure everything is fine tbh ... i thought more ppl would jump on the maxrf/t train EDIT: If you don't want to mess with any setting and just throw in a number, use 25% for the target saturation. That'll get things going a lot faster.
  20. @payonel Well the way the docs are worded / i understood them the thread API would take care of yielding / resuming. But it doesn't do that / can't do that. You still have to yield yourself (with os.sleep). I know this was a misconception on my part And looking at the LUA C API everything makes sense: you can't interrupt the LUA VM without terminating the current context. Now... since I'm doing matrix operations here I can't just put sleeps everywhere and call it a day: it'd litterally take ages to complete so my only hope is that I can do at least one interpolation op per timeslice so the program won't run into "too long without yielding" issues.
  21. Since the threads library didn't really do the thing I expected it to do I'll remove the dependency on that sooner or later. I'm not at home right now tho and thus won't be able to update anything for the next week.
  22. Are you kidding me? The thread API is supposed to not have that problem! And that right there is running in a thread.... You're on 1.7.10, right?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.