The Fate of Luminators (and Switches)

  • I agree... we have lights that burn power... but no switches for them? 8|

    How about you read the change log for 1.337 again?

    Quote

    -Added Detector and Splitter cable


    I think it's safe to assume that this is what you are looking for. Probably works similar to the switch cable

  • How about you try and use the items before you make that recommendation? Because watching Direwolf20's spotlight on the changes, it appears that you have the wrong idea of what these things do.


    What we're looking for is nothing like that. I'm going to assume you live in a home with light switches, so you know what one is. If you'd care to elaborate on how you think these new cables could fill that purpose, feel free.
    Otherwise, remember that your attitude is worth far less than results.

  • This is really, really easy to fix.


    I looked in the code for luminators : there's a MaxEnergy variable set to 10,000. If you reduce that to a smaller number, lights will go out soon after cutting off power instead of running for hours after.


    BUT...that means that if you use a battery, they won't charge up enough.


    So it's really really simple...add another variable to the entity that you reference in "injectEnergy" which is where the luminator takes power from the energy network to keep itself charged. Call it "MaxWiredEnergy" and set it to a low value. If you set it to 1 the lights will turn off in 6 seconds after hitting the switch. Making it nearly instant would require another tweak. The part of the code where it says if(energy <= 0) {shut down the light}. Make it if(energy <= 32) and the lights will shut off instantly.


    For some unknown reason Alblaka and team want machines to be able to store a full packet of energy (32 in this case) more than their maximum storage..I don't know the reason for this, but it's easy enough to work around.


    EDIT : I get it. The reason it is done this way is to reduce CPU load. So, to make the lights instant would increase CPU load. The safest fix would be to make maxWiredenergy = 1 and no other changes.



  • you can make a map that show you how to do?



    Bluemask

  • This is really, really easy to fix.
    EDIT : I get it. The reason it is done this way is to reduce CPU load. So, to make the lights instant would increase CPU load. The safest fix would be to make maxWiredenergy = 1 and no other changes.


    Yes, that type of logic is valid. However I think you're missing a critical use case.


    How do I make a luminator charge up when power is around so that it stays on if the generator is off/etc? This isn't critical for just solar panels, though it is the most obvious use case. It's also key for variable sources like wind.

  • MJEvans : you manually use a battery on the luminator in that case. That would charge it up to the full 10k. Or you just have dedicated batboxes to your luminators.


    I'd post a tutorial on how to do this except that I don't know 2 things : first, I don't know where the battery actually interfaces with the luminator, it must be in the client code only. Second, I don't know how to make it recompile since the MCP addon has not been updated.

  • Alright, I fixed Luminators. Here's the code :


    Summary of changes : Luminators update 4 times less often, reducing unnecessary CPU load. They also take their time adding themselves to the energy net.
    When you charge a luminator with a battery, it takes 11 times less clicks to empty the battery into a luminator.


    Luminators when attached to a wire will turn off within a few seconds after power is cut. However, if you manually charge a luminator, even if it is attached to a wire, it will stay lit for as long as the internal power buffer lasts. The internal power buffer is 10k EU when you manually charge one with a battery but only 20 EU when attached to a wire.


  • MJEvans : you manually use a battery on the luminator in that case. That would charge it up to the full 10k. Or you just have dedicated batboxes to your luminators.


    I'd post a tutorial on how to do this except that I don't know 2 things : first, I don't know where the battery actually interfaces with the luminator, it must be in the client code only. Second, I don't know how to make it recompile since the MCP addon has not been updated.

    Invalid, also condescending (of course I know external storage boosters are an /option/; I don't want that though); candle lighting is not a daily activity; industrial /automation/ is the key. If there /is/ any storage it should be accessible directly. I should be able to stick this right on the bottom of a solar-panel if I want an odd street lamp or any other similar scenario. (Actually, now that I think about it, that /would/ look quite neat and the transparent block effects would prevent mobs from spawning on the panel.)


    I can however think of an alternate suggestion. If the luminator is redstone charged it will behave with the 'max' value of 1eU; otherwise it will try to fill up.


    This would actually be far easier if wires propagated redstone charge an extra (non-wire) block... but since it's /useful/ that would probably take something horridly involved like making wires also carry redstone signal outright... which would have other consequences.

  • What's wrong with dedicated batboxes to your luminators if you want a battery backup? Why should a luminator store 10k power, anyway? There's no battery in the recipe, the only reason for the high storage is because of a nasty bug I found and because of the stand alone mode.


    It would be easy to make them respond to redstone...except that defeats half the purpose of luminators. If you are playing with RedPower 2 Installed, the main drawback to those light cubes is that the redstone needed to activate them interferes with other redstone devices.


  • Uhm, no?
    The reason is I wanted Luminators to be useable on pre-made houses without the effort to put cables into every wall. = Standalone without cables by adding storage.


    Umm, yes? Have you tried running them in SMP with low storage? What happens is that they turn on and off very rapidly and kick clients from the area due to too much network traffic. I've been tweaking them to fix this, but somewhere in your code there's a flag called light that gets set and I can't find where it is. Apparently there's code elsewhere besides TileEntityLuminator and BlockLuminator that sets the flag "light".


    Anyways, this fix lets them be standalone since they have 10k storage when you fill them with batteries but much less than that when you connect them to a wire.

  • Does anyone NOT use RP2 with IC2? I know some small minority is in that camp, but I can't imagine doing so myself. That being the case, I find I treat RP, IC and BC like competing companies. I use the products that I need to fit the circumstances. I use the RP Lights for when I need them to turn on and off. I use the IC Luminators for when I need something that will hold a charge. I use BC for when I need leaky pipes :whistling: ! I know the RP lights don't run off the power grid, but I can simulate that with the new EUD wires.


    Not really trying to make a point, just my 2 cents.

  • It's reasonable enough - and it nicely illustrates why some "overlap" in features is a good thing. Both RP and IC have electrical lighting, but it's done differently and as such, each one is more suitable to a particular purpose.

  • Does anyone NOT use RP2 with IC2? I know some small minority is in that camp, but I can't imagine doing so myself. That being the case, I find I treat RP, IC and BC like competing companies. I use the products that I need to fit the circumstances. I use the RP Lights for when I need them to turn on and off. I use the IC Luminators for when I need something that will hold a charge. I use BC for when I need leaky pipes :whistling: ! I know the RP lights don't run off the power grid, but I can simulate that with the new EUD wires.


    Not really trying to make a point, just my 2 cents.

    I don't use it, I disagree ALOT with RP2, so even though I'm an Rstone geek I won't use it, besides that I think the stuff is a little (lot) costly.

    Quote

    That's a rather cool idea, but a lone tree is suspicious, better plant some more. So really... forget about solar-flowers, solar-trees are the next generation :P

  • I don't use it, I disagree ALOT with RP2, so even though I'm an Rstone geek I won't use it, besides that I think the stuff is a little (lot) costly.


    That strange.
    Generally my server is thinking RP is cheap :\
    We got auto (insert something here) for anything

  • I don't use it, I disagree ALOT with RP2, so even though I'm an Rstone geek I won't use it, besides that I think the stuff is a little (lot) costly.


    A little costly? how's that? the gates are immensly powerful for the cost you put in, I mean they take up one block where some of those would run 5x5 and up to do with torches.
    Other stuff like the block breakers are rather too cheap for what they do.

  • Um, perhaps what we need for SMP is to have a luminator that has been shut off by lack of power only turn back on once it has over 1000EU in its storage, and once on would run through that 1000EU. That way it would not flicker like a crazy person and cause my framerate to drop to 5fps.


    I have a few solar panels charging my luminators through 2 batboxes in series, and what inevitably happens is we go through a night, it rains the next day, and then it becomes night again and by then I have burned through all the power in the batboxes. Then, in the morning, I get massive lag as the luminators eat up everything the solar panels generate, and because some of them in the line are preferred over others, at least half of them continue to flicker until the first set have been fully charged. I'm not sure how to fix this besides putting a solar panel on top of each luminator.

  • <libraryaddict> What about the hook Albaka keeps begging for?
    [2:12:24pm] <@Eloraam> nope.
    [2:12:28pm] <@Eloraam> which one?
    [2:12:33pm] <libraryaddict> Something about lights
    [2:12:47pm] <libraryaddict> For the IC Lamp
    [2:12:47pm] <Lhowon> probably something related to the illuminators then
    [2:12:50pm] <libraryaddict> yere
    [2:12:50pm] <@Eloraam> libraryaddict, i don't know a thing about it... haven't heard word one.
    [2:12:53pm] <libraryaddict> :o
    [2:12:55pm] <@Eloraam> dig me a quote
    [2:12:57pm] <libraryaddict> Sec
    [2:12:58pm] <Lhowon> considering how much grief he's had with them
    [2:13:15pm] <@Eloraam> funny part is that we've had a variable lighting hook now for ages.
    [2:13:21pm] <@Eloraam> i use it for my furnaces.
    [2:13:56pm] <mDiyo> Variable... lighting... wha?
    [2:14:08pm] <absurdHuman> getBlockLight() or something? Uh, pretty sure I'm using it...
    [2:14:27pm] <@Eloraam> i made it so a single block ID could choose its own light level.
    [2:14:28pm] <mDiyo> Yes. There's a way around that?
    [2:14:34pm] <@Eloraam> yes, it's a forge hook :)
    [2:15:03pm] <@Eloraam> Block.getLightValue() :)


    Just curious.
    Has I revealed something or is this the temp fix and Im looking like a idiot?
    Or is the fix yet to come.