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

XyFreak

Members
  • Content Count

    383
  • Joined

  • Last visited

  • Days Won

    30

Posts posted by XyFreak


  1. You need to have all energy storage devices connected that sit immediately behind your generators (note all generators need to be able to feed all of them - dedicated storage devices for each generator are not supported). Intermediary energy devices don't REALLY matter but it'd obviously give the controller a better understanding of how much power you actually have.

    The wheighted is a rolling average where the factor is determined by how full your energy storage is ( formular is `wheighted_rft = (1 - (energy_stored / storage_total)) * current_rft + (energy_stored / energy_total) * wheighted_rft` ). That value is then used to determine how much power should be produced. The reasoning behind this is simple: If there's a lot of energy stored, react slowly cause there's energy stored - no need to up fuel consumption, is there? If there's less and less energy, the controller needs to react faster to changes in energy demand to not cause a power failure.


  2. Hi @GenSmicer

    The order to connect everything from a CLEAN INSTALL is:

    • Turn on the turbines to make sure steam can be consumed.
    • Connect the reactor.
    • Wait for calibration to finish.
    • Connect the turbines.

    That should be everything you need to do.

    What does "it also never really showed a number" mean?

    There is indeed an issue with RFTools power storage as it caps out at 2^31-1 RF stored (limitation of the API they use).


  3. I just realized that timers had a drifting problem since forever by the looks of it:
    Even since before the commit that broke things, if a timer called something that let time pass (i know this is bad anyways but it CAN happen), it would actually fully delay the deadline of successive timers (instead of just delaying the timer once).

    Here's another patch

    --- C:\Games\MultiMC\instances\Draconic Computers 1.12\.minecraft\saves\BRGC\opencomputers\a201b7a4-e2fd-4565-8b4b-79a6993a7e62\lib\event.lua.bak
    +++ C:\Games\MultiMC\instances\Draconic Computers 1.12\.minecraft\saves\BRGC\opencomputers\a201b7a4-e2fd-4565-8b4b-79a6993a7e62\lib\event.lua
    @@ -62,7 +63,11 @@
           -- nil keys match anything
           if (handler.key == nil or handler.key == signal) or current_time >= handler.timeout then
             handler.times = handler.times - 1
    -        handler.timeout = current_time + handler.interval
    +        -- we need to make sure the timer doesn't drift but at the same time doesn't get rescheduled
    +        -- immediately if it's execution had been delayed significantly (>= handler.interval * 2).
    +        repeat
    +          handler.timeout = handler.timeout + handler.interval
    +        until handler.timeout > current_time + handler.timeout
             -- we have to remove handlers before making the callback in case of timers that pull
             -- and we have to check handlers[id] == handler because callbacks may have unregistered things
             if handler.times <= 0 and handlers[id] == handler then
    

    I decided to go with a loop instead of math based, because the most likely case is this loop getting executed exactly once. Solving this with math would require math.floor which would propably be slower than this most of the time.


  4. Ok since I need a github account I'm just gonna ping @payonel and hope he's the right guy for the job! ;)

    Here's what's up:

    This commit here broke BRGC - and it actually broke timers in general whenever event.pull is involved.

    BRGC uses events and timers all over the place. The entire thing is running asynchronously. Now usually you don't want to drop to the prompt when running a program so here's what it does:

    function libGUI.run()
    	while event.pull(math.huge, "libGUI_terminate") == nil do end
    end

    It just waits for a libGUI_terminate event and then cleans up stuff. Pretty easy.

     

    Now with the linked commit, this event.pull continues to eat timer messages. The timers are only executed once a non-timer event is executed (such as a key press or a touch).

    Here's a small PoC:

    event.timer(5, function() print("canary") end, math.huge)

    Prints "canary" every 5 seconds - pretty easy - nothing should go wrong here. If you now do a simple

    while event.pull(math.huge, "tell_me_to_terminate") == nil do end

    you will stop seeing "canary" show up - it's dead ;)

    --- SNIP because I didn't want to believe the issue is complicated and looked further into it ---

    And here's your bug:

    In /lib/event.lua line 36 computer.uptime() is read and stored in a variable called current_time that is never updated again. Afterwards we enter a post-checked loop. Inside of this loop, on line 54, this line is executed:

    local event_data = table.pack(handlers(closest - computer.uptime()))

    Nothing wrong with that, until you realize, that calling handlers actually calls _pullSignal, which allows time to pass. Later, current_time is used to check if timers have expired. The issue? current_time is no longer current, because _pullSignal was called and time has passed!

    So unless you return from computer.pullSignal (=> cause a non-timer event to be triggered like a key press or a touch), current_time is never updated so timers will never trigger.

    The fix is really easy: update current_time after _pullSignal has been called.

    Here's a patch:

    --- C:\Games\MultiMC\instances\Draconic Computers 1.12\.minecraft\saves\BRGC\opencomputers\a201b7a4-e2fd-4565-8b4b-79a6993a7e62\lib\event.lua.bak
    +++ C:\Games\MultiMC\instances\Draconic Computers 1.12\.minecraft\saves\BRGC\opencomputers\a201b7a4-e2fd-4565-8b4b-79a6993a7e62\lib\event.lua
    @@ -54,6 +54,7 @@
         local event_data = table.pack(handlers(closest - computer.uptime()))
         local signal = event_data[1]
         local copy = {}
    +    current_time = computer.uptime()
         for id,handler in pairs(handlers) do
           copy[id] = handler
         end
    

     

    That was a b*tch to figure out... holy molly.


  5. Hey guys,

    I've been able to confirm this issue after updating OpenOS - unless I can say for sure it's not an issue on my end I'm not gonna bisect the OpenOS version it starts happening on tho... tbc...


  6. I do not have a solution for this issue - the gui is using a timer to redraw stuff - if it suddenly stops drawning then i don't think there's anything wrong with the program. In order for me to test things out I need you to tell me the version of OC, ER and propably your forge version as well.


  7. @CygnusiaX1 Can you check if its related to some mod you are using ( *hint* optifine *hint* )  - the shell cursor should be blinking if you just leave the pc on after booting

    @BrisingrAerowing I did but I forgot about it. `rftools_powercell` is already part of the whitelist. If your mod changes that then please add it to `/usr/lib/brgc/energy_storage_component.lua` and let me know if it works - i'll add it if it does.


  8. Well the design i posted is a drop-in replacement for your current design with no changes to the exterior required so you can go for that if you want to - it's up to you in the end ;) 

    As i mentiond in my last post: 3x3 cores or rings work very well as long as there's one layer of coolant between them


  9. Nah that won't be necessary. If calibration fails that badly, that usually means your reactor has an efficiency curve where its most efficient point is VERY close to 100% rod insertion (in your case that'd be ~97%).

    Sorry but i don't think you can get brgc to work properly with your design. I just checked and when ran at peak efficiency, the 9x9 core is indeed a tad more efficient than 4 individual 3x3 cores ( https://br.sidoh.org/#reactor-design?length=11&amp;width=11&amp;height=10&amp;activelyCooled=false&amp;controlRodInsertion=91&amp;layout=24C3XC3X4C3XC3X4C3XC3X15C3XC3X4C3XC3X4C3XC3X24C ) (I usually go for a 3x3 grid of 3x3 cores like that).

    If you are a bit savvy then can you try editing /usr/lib/brgc/reactor_base.lua ?

    There is a line that looks like this (right near the top):

    local reactorCalibrationMaxOutput = {0.01,0.02,0.05,0.1,0.15,0.2,0.25,0.3,0.35,0.4,0.5,0.6,0.7,0.75,0.8,0.9,1}

    Can you add 0.03 and 0.04 between 0.02 and 0.05 ? And 0.075 between 0.05 and 0.1? Maybe that already hels in your case.


  10. If you extended your reactor you need to make sure BRGC recalibrates it or otherwise it won't know that the reactor is now different.

    There are multiple ways to do this:

    1. Break & replace reactor computer port (this causes the old config to still be present somewhere tho)
    2. Remove the config file ( rm /etc/br_control.cfg ) then reboot
    3. do a brgcctrl recalibrate <first three characters of reactor address here>

    I recommend (3) but (2) is propably easier than that and way cleaner than (1)


  11. Ah ok I see what you did. The ON/OFF switch you pressed is not doing what you think it does :P

    You turned off the GRID controller, which caused the reactor control to fall back to standalone mode. Since you're draining the reactors buffer into your induction matrix, the controller assumed that you are using more energy than you can produce and thus the reactor was running full throttle.

    If you want to turn off the reactor you need to go to the "Reactors" (or "Combined") Tab and disable the reactor from there (click on the reactors bar).

    CHARGE mode only does something if you have more than one reactor / turbine connected. Essentially it powers up every component and sets them to optimal levels to charge your energy storage.


  12. Hi @Minoslo

    Can you give me some more info? How is your reactor built? Active/Passive? Did you connect some sort of energy storage to the computer via an adapter?

    What do you mean by when you tried to put if off? Did you try to turn off the reactor via the GUI? That should just.... turn it off (reactor controller block turning red).


  13. So the 1.7 version is built around extracting energy from the reactor and reinjecting it through a seperate circuit. As a result, the flux gate extracting energy that goes to storage is only extracting CALCULATED_OUTPUT - REINJECT

    So there's your problem. Your setup looks more like the 1.10 setup, in which case you should propably use the 1.10 program. (I knew i changed something important going from 1.7 to 1.10)


  14. It looks like not enough power is being extracted from the reactor. DC is "immune" to config file changes as it has code in place to figure out those multipliers through backwards calculation (and sometimes they just don't matter). Is wherever you're piping the energy to able to accept that much / store that much? (I'm guessing yes but still asking ;) )


  15. @Chaoschaot234 no i never got around doing that, sorry.

    @Electro56 If your temperature is stuck at 20 degrees then your reactor isn't even charging. Please have a look at the flux gate at the energy injector. If that's in computer mode and >0 then the flux gate is either facing the wrong way, not connected to energy or something is just not behaving connection wise.

     

    EDIT:

    @Chaoschaot234 regarding your edits: The GUI always selects the first reactor. If you look for a line like

    local controller = draconic_control.controllers[1]

    towards the end of the dc_gui.lua you can propably figure out on how to get it to display other reactors :P

    I have a modified version around somewhere that makes it so dc_gui takes its first command line parameter and uses that as index but i dunno where it is right now.

    The ultimate goal was to make everything (DC and BRGC) network ready and use the GUI and grid logic from BRGC manage everything but that obviously didn't happen. And right now I'm way to burned out from programming to get to that.

    As for the 1.7.10 autostart one: No promises. It isn't hard but I'd still need to get around and do it. I haven't tried it but the 1.10 code might just work, depending on the version of OpenOS available for 1.7.10. The controller logic itself only got safer to use (and so did the setup).

×
×
  • Create New...

Important Information

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