[bug 1.337b] Luminator bug: does not accept energy directly from solar panels.

    Quote from Alblaka

    Doesn't make much sense to me, both use the same algorythm for receiving energy (Batbox and luminator).
    Are you sure you didn't just mess up the luminator placment? (only luminators placed upon cables receive energy at all)


    Unless that is a misstatement, I think obvious answer is right in alblaka's post.


    "only luminators placed upon cables receive energy at all"


    If you cant figure out why I think this way, I suggest you read more carefully.


    Just put a wire between the solar panel and the luminator.


    And no, I do not think it should extend to work with non-cables, because ithat would be basically useless with a batbox, and almost as useless with a solar panel.

    It doesn't matter the type of wire*, it still doesn't work (I didn't test with gold, fibre, or HV cable, but did test tin and copper).

    Quote from MJEvans

    It doesn't matter the type of wire*, it still doesn't work (I didn't test with gold, fibre, or HV cable, but did test tin and copper).


    Did you check if the solar panel is getitng power? if it is not, but ought to (no obstruction) you might still have 1.337 instead of 1.337b

    Just tested this myself on 1.337b... Solar panel on top of a single tin cable (showing as powered). Put a luminator on the bottom of the tin cable = instant ton of lag and no light. Breaking the luminator clears the lag. Although the luminator doesn't appear on, a few blocks away (5 or 6) the underside of a few leaf blocks seemed to be flickering slightly... almost to faint to notice, and not sure if it's related - maybe just a symptom of the lag.

    Hmmm... but if that doesn't fix what's going on here... wouldn't luminators just get stuck at 100EU then? That'd probably discharge pretty fast during the night. :(

    If the reason they're flickering is due to them discharging at the same speed (or faster) as they're receiving power, then ... would it not do the same thing at 100EU? Instead of flicking between 1EU and 0EU, it would be flicking between 100EU and 99EU. ?(


    EDIT:
    Thinking about this again... if the luminator did not turn on until 100EU... it would still flicker... as soon as it hits 99EU, wouldn't it turn off again? The only difference would be that the luminator is delayed turning on initially... and then you just lost 99EU that you'll never get back because the luminator will never use it!

    I'm pretty sure he means it will turn on at 100eu, but will stay on til it hits 0.
    That way, if its going to flicker, it will be a slow flicker


    EDIT: seems to work fine if you get the luminator started with an RE-Battery, once its on, it charges up from the solar panel without issue. it seems the act of turning on the luminator uses up the 1 eu that the solar panel sends to it, so it turns off immediately cause its then at 0 before the next eu comes in, but once you get it charged a little, energy usage is as expected. this is just my observation from testing, hope it helps.

    • Official Post
    Quote from Plystire

    If the reason they're flickering is due to them discharging at the same speed (or faster) as they're receiving power, then ... would it not do the same thing at 100EU? Instead of flicking between 1EU and 0EU, it would be flicking between 100EU and 99EU. ?(


    EDIT:
    Thinking about this again... if the luminator did not turn on until 100EU... it would still flicker... as soon as it hits 99EU, wouldn't it turn off again? The only difference would be that the luminator is delayed turning on initially... and then you just lost 99EU that you'll never get back because the luminator will never use it!


    Don't try to understand the mechanics based on the 5% i revealed in here. :P



    The issue is, Luminators use 1 EU every "time % 4 == 0" tick. Which implies the actual first one.
    If now a solar provides 1 EU, the luminator will switch to on, consume 1 EU and then turn off again, because it's on 0 EU, which will as well reset the timer (and cause it to actually eat 1 EUt).
    There are probably better ways to fix this up, but telling it to only turn on after receiving at least will fix this issue without creating new ones.

    Quote from Alblaka

    Don't try to understand the mechanics based on the 5% i revealed in here. :P



    The issue is, Luminators use 1 EU every "time % 4 == 0" tick. Which implies the actual first one.
    If now a solar provides 1 EU, the luminator will switch to on, consume 1 EU and then turn off again, because it's on 0 EU, which will as well reset the timer (and cause it to actually eat 1 EUt).
    There are probably better ways to fix this up, but telling it to only turn on after receiving at least will fix this issue without creating new ones.

    I like the threshold idea, it sounds like it would solve most issues that could cause flickering, especially if someone has more luminators than their power sources can handle.

    So turning on if it has /at least/ 10eU/t in buffer... would solve all of our problems (since all storage devices output in 32eU/t or greater packets, and all non-tin generators output in at least 10eU/t packets).


    Actually 2 eU in buffer would probably be a better check. If you can't deliver another eU before the light consumes the first then you probably shouldn't be on, while if you can you'll either be balanced or eventually grow the buffer.

    Quote from Alblaka

    Don't try to understand the mechanics based on the 5% i revealed in here. :P



    The issue is, Luminators use 1 EU every "time % 4 == 0" tick. Which implies the actual first one.
    If now a solar provides 1 EU, the luminator will switch to on, consume 1 EU and then turn off again, because it's on 0 EU, which will as well reset the timer (and cause it to actually eat 1 EUt).
    There are probably better ways to fix this up, but telling it to only turn on after receiving at least will fix this issue without creating new ones.


    If the luminator should only be consuming 0.25EU/t then find out why it's keeping up with the solar, and fix that instead. If your code is as you say it is, then this is only working around the issue, not confronting it. Not trying to sound mean/upset/pushy or anything, just sayin', if a pipe sprung a leak don't just duct-tape the thing, replace the pipe to prevent further issues down the line.


    Is "time" referencing global time? Or is that a local tick counter?

    Actually, I suspect the issue is that it's using energy level 0 for off and any other energy level for on. Thus the bug is that it constantly wastes the 'last' eU of energy. The correct behavior for this case is, if the energy level is 0 and an energy packet arrives, increment by one, then store the packet.


    Sec -: 0 eU
    Sec 0: + 1eU generator packet (solar/water) + 1eU because energy was 0.
    Sec 0: Decrement energy value by 1.
    Sec 0: eU > 0; Light is on
    Sec 1: eU > 0; Light is on
    Sec 2: eU > 0; Light is on
    Sec 3: eU > 0; Light is on
    Sec 4: Decrement energy value by 1.
    Sec 4: eU !> 0; Light is off



    In the above case handing the special case of energy arriving /while storage was 0/ allows it's preservation as a sentinel value.

    It's not using 0.25eu/t its using 1eu/4ticks
    the thing is, it starts counting the moment it turns on, using 1eu on tick 0, then 1eu on tick 4, and so on
    but when it turns off, that counter resets
    so it turns on and is at tick 0 again, causing it to use 1eu immediately
    the two other fixes i could think of would be to make it wait a tick before turning off,
    or changing the timer to use 1eu on ==1 or ==2 instead, but neither of these would prevent flickering in an out of power situation
    the threshold would. from my limited understanding, it sounds like the best fix, and makes sense in an "power on requiring extra power to exist, even if its not used" kinda way

    Quote from wierd

    It's not using 0.25eu/t its using 1eu/4ticks


    That is how you count decimals using only integers, my friend. If you look at what you just said with just a dash of dimensional analysis, you're repeating yourself.


    1eu/4ticks . . .
    Numbers only: 1/4 = 0.25
    Units only: eu/tick = eu/t
    1eu/4ticks = 0.25eu/t

    Right, I got the second/tick thing wrong this morning (zombie monday), but consistently so such that the same solution works.


    The problem is that it's 'wasting' (loosing/etc) the 'last' eU because it skips from 1 to off instead of allowing that final tick to leave the state on. (Also adding an exception to the likely one for /reaching/ 0 on decrement to turn it off to the on side for if it's /at/ zero to 'add one' fixes the off by one issue).

    Quote from Plystire


    That is how you count decimals using only integers, my friend. If you look at what you just said with just a dash of dimensional analysis, you're repeating yourself.


    1eu/4ticks . . .
    Numbers only: 1/4 = 0.25
    Units only: eu/tick = eu/t
    1eu/4ticks = 0.25eu/t

    AH, but see, I'm not repeating myself
    1eu/4 ticks is this
    tick1 - 1eu consumed
    tick2 - 0eu consumed
    tick3 - 0eu consumed
    tick4 - 0eu consumed
    tick5 - 1eu consumed
    tick6 - 0...
    tick7 - 0...
    tick8 - 0...
    tick9 - 1...


    you get the pattern
    0.25eu per tick would be different
    its all in how its programmed
    the luminators are programmed to work at 1eu consumed every fourth tick, not 0.25 eu per tick
    and since they use an eu on the tick they turn on, it means the eu that comes in to turn them on gets used up before they get a second eu, so they turn off again.
    This apparently happens no matter how many 1eu sized ticks of energy solar panels give it, (i haven't tested using >20 solar panels.)
    unless you use a RE-Battery on the light to give it a small boost, it will continue turning on and off every time it gets that first 1eu