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

XyFreak

Members
  • Content Count

    400
  • Joined

  • Last visited

  • Days Won

    32

Posts posted by XyFreak

  1. That is what i originally intended to do but never got around it (the GUI part). As for the server displaying stuff: This is not going to happen unless i rework my networking stack first.

    You see, I wrote a networking stack that allowed computers to discover services and route packets (i.e. to linked cards), which allowed my tablet to access my whole OC network. Unfortunately I need to rework some parts of it for OC 1.6 (i think it was? yes its old(er)). IF I ever make the reactor control programs network aware, I'd be using this stack.

    The reason is simple: Service Auto Discovery.

    Draconic Control aside, BRGC is intended to be a "install, run, you're good" solution. The network gui should behave the same.

    So yeah. Sorry.

     

    As for the containment field strength: It should be sitting around 20% with default settings, which is not low by any means. Going higher would mean MUCH more energy consumption as it does not scale linearly.

  2. Ok guys I'll post the "solution" to @JustCallMeJick s problem here for everyone to read.

    RefinedStorage is NOT able to transfer steam fast enough on its own. It COULD do it because it is able to transfer large amounts of liquids at once, but it only does it every other tick.

    Unfortunately, turbines only have enough steam tank capacity for 2 ticks at full steam (see what I did there xD). RS seems to transfer liquids every 4 ticks (that's a guesstimate, not something I actually verified). The result is your turbines not running faster than half their speed.

    The catch here is that the turbines GUI doesn't update fast enough to show you this. Instead it would appear that there is either not enough steam at all or enough steam at all times... and the result is that you don't know what's wrong.

    If you'd still like to use RefinedStorage I suggest putting the steam storage barrel near the turbines and use something like ActuallyAdditions Lasers (do they transfer fast enough?) or maybe ExtraUtilities 2 Nodes from there.

     

    -XyFreak

     

    EDIT:

    I just came up with another pure RefinedStorage idea:

    Instead of importing steam into a barrel and exporting it into the turbines, connect the turbines as "storage" directly. This might work.

  3. @JustCallMeJick please do. If you need a drop off space for the world file please send me a PM and I'll give you some.

    @Programeditor I see two flaws there with your setup:

    Your turbine goes over speed. Anything above 1950 RPM is considered a failure.

    Your reactor gets too hot. This is usually caused by your steam transfer rate being too low. This might be induced by the turbine being shut down though.

     

    -XyFreak

     

    EDIT: Fixed my grammar.

  4. Well the reactor outputs 3.53 B/t, which is obviously not 4 B/t.

    What I'd like to know is whether the actual generation rate is too low (e.g. the steam tank in the reactor being empty) or if the steam isn't transfered fast enough.

    I don't know how fast RS can transfer liquids so...

     

    There's also a possibility that the energy extraction from the turbines to the capacitors is too low and the controller adjusts the output.

  5. @sedstr

    Do both turbines get set to 800ish RPM? If so, can you make sure the controller managed to calibrate your reactor correctly? As in: what steam inputs are your turbines set to and how much steam is actually produced by the reactor.

    For the usual setup you are required to connect both turbines and reactor so the controller knows how much steam it has to produce (i need to optimize that code a "bit").

    What YOU want is propably:

    1. Connect the reactor only
    2. Do NOT start the turbine controller
    3. Manually set the "steamtarget" to 4000 with "brgcctrl steamtarget 4000"

    The thing where you want to switch on/off the turbines based on capacity is going to be implemented in the next release. If you really want to do it yourself you don't need another computer to do it. Just make sure you don't start the turbine controller and do it on the same computer as you are running brgc. Should work just fine AND you can hook into the reactor api to set the steamtarget to lower the reactors output or shut it down if you turn off turbines.

    local reactor_api = require("brgc/reactor_ctrl")
    reactor_api.setSteamProductionTarget(4000)

     

  6. @vik2or

    Thanks for your input. I talked about this with a friend yesterday and we also came to the conclusion that idea 4 is the best way to do it without doing any statistical analysis (which would be way over the top).

    The gui is currently set up in a way where it will bind an unused monitor to an unused gpu if it finds multiple of them. So if you have two monitors/gpu then it will draw on the second one and fall back to shell on your "primary" monitor. Unfortunately I never intended libGUI to draw on multiple screens so I would have to rework parts of that. It's propably not gonna happen, sorry.

    The code is not done yet btw. There's still some stuff to do.

  7. Hi guys,

    it's time for a status update.

    Obviously I didn't manage to get everything ready within the timeframe I hoped to do it. So instead I'll post a quick status update.

     

    I'm done refactoring BRGC. BRGC is now caching and calculating a lot more in advance. The caching allowed me to eliminate a LOT of API calls into Big Reactors/Extreme Reactors which should lower the overall load of your actual game server a bit. While this shouldn't matter in practice (it's not like it had any noticable impact to begin with) I'm hoping that this will stop triggering those server crash bugs. Anyways... the code is a bit nicer now and easier for me to work with/extend.

    The grid controller for when you have capacitors attached is about half way done (maybe more). It already works perfectly fine if you don't consume more energy than you can produce at your optimal max. This includes running turbines and passive reactors simultaneously. Turbines are always prefered to passive reactors.

    So here's what's left:

    • Balance the "overload" in case you need more energy than you can produce at optimal levels (LOAD)
    • Figure out a good way to decide when to switch over to LOAD mode. I'm currently considering a dynamic threshold based on how much more RF/t you're consuming in relation to how much you can produce at an absolute max. More on that later.
    • Write a small GUI for the grid controller itself (It'll be a widget like what I did for the reactors/turbines)
    • Finally have the GUI automatically refresh its components. Right now you need to restart the GUI for additional turbines/reactors to show up.

     

    If you're not interested in the ideas and are just here for the status update, you can skip to the end of the post now ;)

     

    Now regarding the LOAD mode switch ideas.

    The main idea behind energy storage is to buffer energy when you don't need much of it and to provide energy when you need more than you can provide. BRGC takes this one step further and tries to optimize your energy production at all times so it is as efficient as possible at any given time while providing enough power for whatever you want to power with it. If this means your reactors have to run inefficiently in order to generate enough power, then that's what it's going to make your reactors do.

    This is perfectly fine if you don't have (a lot of) energy storage because you're most likely going to run out of power very quickly if your reactor is not producing enough energy. This may not be fine if you have a large energy storage which can buffer extreme energy needs over a short or even extended period of time (e.g. you're creating a new RFTools World with large draconium ore spheres). So I've got to figure out a way to decide when it is ok for BRGC to abandon efficiency in order to make sure your energy grid stays saturated when more energy is required than your grid can generate efficiently / generate at all.

    The simplest idea is: Choose a threshold. If energy falls below that point, start generating more energy. This is what BRGC does right now with passive reactors in AUTO mode. If more energy is required than the reactor can provide efficiently and if the internal storage falls below 50% it will start squeezing more power out of the reactor at the cost of efficiency. I never felt that this solution is very satisfying and it's really bad when you add larger storage. If you have 1TRF energy stored and you're consuming 10kRF/t more than you can produce, having the reactors run inefficiently is a waste of fuel. However if you only have 10 MRF storage, then 50% might be way too low. Having the user set this value means that there is manual configuration required which I want to avoid at all cost (it needs to be Plug&Play).

    Idea 1: Use a percentage based thershold based on how much more energy is consumed than can be generated. E.g.: Threshold = 0.0001 * more energy consumed then generated. This is really easy to implement and automatically adapt to whatever setup you have. It does require a lot of experimentation though.

    Idea 2: This is a refinement of Idea 1. Calculate how long the energy storage is going to last at the current energy consumption. If the energy storage is going to be depleted within an hour (real time) then produce more energy.

    Both of this ideas are easy to implement but have the disadvantage that they can (and will) overreact pretty easily when large power spikes occur.

    Idea 3: Use idea 2. Instead of using the current power consumption, use a weighted average that is only slowly approaching the current value. This will prevent the controller from overreacting when it's not neccessary but it will also prevent it from doing so when it is neccessary.

    Idea 4: Use idea 3 but make the weight based on how much energy (percentage based) is left in storage. This will prevent overreactions when the storage is full and may allow it when storage is empty.

     

    If you're still reading this ( ;) ) then please let me know what you think and what you want to see implemented.

    I've got some time off from work at the end of this month/start of the next month so I'll be getting things done then for sure.

     

    -XyFreak

  8. @vik2or Thanks for your input. As I said before the lua program should not be able to kill the server.

    We're either triggering a bug with OpenComputers or a bug with Extreme Reactors.

    I'm going to have a look once I'm done refacturing/rewriting some compoments of BRGC that'll allow you to include external storage devices into your grid.

    If I have a surefire way to reproduce it (I think with your input it can be done quite easily...I hope...) I'll also file a few bug reports or support already existing ones to the best of my abilities.

     

    I'm aware of the autostart issues and the config issues btw. In my latest dev snapshot the config issues are pretty much gone and the code is a lot simpler. Give me a week or so to get everything polished up.

     

    -XyFreak

  9. Ok first of all I'm jelly at your 230fps in minecraft (and a texture pack). Just letting you know :P

    Next I'm really really confused about this whole thing not starting up. How did you set up your computer (aka what components are in there) and are you using a modpack? If I'd have to guess it's the direwolf20 one but...just making sure.

     

    -XyFreak

  10. Hi @MaSch

    An OpenComputers program should never be able to crash your server.

    Lets do a quick breakdown.

    Here's your stacktrace:

    Description: Exception in server tick loop
    
    java.util.ConcurrentModificationException
    	at java.util.HashMap$HashIterator.nextNode(Unknown Source)
    	at java.util.HashMap$KeyIterator.next(Unknown Source)
    	at java.util.AbstractCollection.toArray(Unknown Source)
    	at com.google.common.collect.ImmutableSet.copyOf(ImmutableSet.java:374)
    	at elec332.core.grid.internal.GridEventInputHandler.tickEnd(GridEventInputHandler.java:91)
    	at elec332.core.grid.internal.GridEventHandler.serverTick(GridEventHandler.java:49)
    	at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_304_GridEventHandler_serverTick_ServerTickEvent.invoke(.dynamic)
    	at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90)
    	at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:185)
    	at net.minecraftforge.fml.common.FMLCommonHandler.onPostServerTick(FMLCommonHandler.java:261)
    	at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:657)
    	at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:471)
    	at java.lang.Thread.run(Unknown Source)

    You can see there're two lines that don't look like they're not vanilla minecraft or forge related:

    	at elec332.core.grid.internal.GridEventInputHandler.tickEnd(GridEventInputHandler.java:91)
    	at elec332.core.grid.internal.GridEventHandler.serverTick(GridEventHandler.java:49)

    A quick google reveals that the mod those methods belong to is (suprise suprise) eleccore.

    I suggest you go to the github issue tracker and report your findings because this looks pretty much like the exact same thing that's happening to you.

     

    Next up... what is eleccore used for and can we temporarily remove it? Well it looks like eleccore is used by Deep Resonance and that mod has worldgen. So removing it is a no-no. Duh....

    So...what can we do?

    Since we know that Deep Resonance is using eleccore, you can try to remove all your Deep Resonance machines and see if you're still able to reproduce the isse. Is it gone? Well... this means that you're no longer able to use DeepResonance without crashing your server... but at least you're no longer crashing the server so that's a start. Additionally go and look for the Deep Resonance issue tracker as well and tell them that using that there're some serious issues with the library they're using.

     

    I hope this somehow helps you. Unfortunately there's nothing more I can do. Those are the joys of modded Minecraft ;)

     

    -XyFreak

  11. Okidoki.

    Status update:

    I just implemented drawing the ends of the bar widgets with block symbols and I REALLY REALLY like it. Look forward to the next release ;)

    Regarding the whole external energy storage, here's the plan:

    Not having any energy storage blocks connected to the computer is having the controller run like it does right now (makes sense, huh?)

    Having energy storage blocks connected is going to change everything:

    • If your total energy consumption can be satisfied by having all reactors run at optimal levels, your reactors will be in PWM mode. HOWEVER the controller will only use as many reactors as neccessary to keep your storage from draining. The reactors which are going to be onlined/offlined are decided by each of the reactors fuel efficiency. I'm going to implement a simple greedy algorithm here that tries to balance out things (having your really small but efficient reactor running all the time and your really big but slightly less efficient reactor turn on and off is not neccessarily what you want, right?).
    • If your total energy consumption can no longer be satisfied by having all reactors run at optimal levels, some (up to all) of your reactors are being switched to LOAD mode. I've not yet decided on how to switch them iteratively but efficiency is key here so I've gotta come up with something. Suggestion appreciated.
    • If you have turbines, those will be used as really efficient reactors (because they essentially are) and thus will have highest priority. I'm propably getting rid of LOAD mode for turbines here and just have them run like PWM reactors (that's more efficient anyways if you have a larger energy storage).

    Since it might be possible that not all of your connected components are connected to the same energy storage, you're going to be able to set passive reactors to "independent" mode like you can do with turbines right now.

    Initially I also wanted to implement multiple grids but configuring those is going to be too hard (remember this thing is supposed to be Plug&Play) so... that's not going to happen ;)

     

    -XyFreak

  12. Hi guys,

    regarding the unicode fonts - i might do that.

    The bigger battery thing has been in planning phase since the start of this year but I wasn't able to find the time to actually do it. It's going to be done at some point. I just don't know when. Sorry.

     

    @sedstr you need all tier 3 ram? holy i think i need to work on that then... >_>

     

    -XyFreak

  13. That's a valid point but from personal experience, once should not mention "minecraft" on your resume. Just putting up "has expierience in programming language x with y, z" works better :P

    But yeah, it's fun. However the fun ends if critical bug reports come in. I released this code to everyone so I feel obligated to fix code-breaking bugs ASAP.

    This was one of these where I essentially stopped doing everything else and focused on fixing this problem.

    It was worth it though ;) (Getting everything back running again is incredible rewarding)

  14. Haha yeah. But this is a game and I've been told I put way too much effort in this already :P

    I mean..comeon...who does that kinda stuff "just for minecraft", right? ;)

     

    EDIT:

    I wrote an entire gui library for this program as well. And there's some secure networking stuff I've been working on but never got around to finish.

×
×
  • Create New...

Important Information

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