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

Quote from wierd

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

Actually, it's no different - IIRC, an individual EU cannot be "split". From what I can see, there's no way for a machine to draw or produce or use or transport a fraction of a single EU.
Can someone who's familiar with the inner workings shed some light on that?

Quote from Alblaka

The issue is, Luminators use 1 EU every "time % 4 == 0" tick. Which implies the actual first one.

This was Alblaka shedding light on it =)
its a simple breakdown of what is actually happening.

0.25eu/tick is different from 1eu/4ticks specifically because 0.25eu/tick is not what the luminator draws.
i do not know how fractions of eus are handled in IC2, which is a shame, because water generators really confuse me because of it. i know they work, but i don't know how. same with wind turbines.

regardless of whether anyone understands me or not, the simple fact is. until Alblaka thresholds the energy required to turn a luminator on, you can fix the flickering by using an RE Battery to apply a startup charge yourself. as long as the luminator never runs out after that point, it wont flicker.

This makes perfect sense to me. I haven't checked the code but if the luminator is "on" when there is >0 EU stored and the luminator gets 1 EU and consumes it then it will never stay on. Simply making it turn on when it's >1 EU stored and turning it off when it's 0 EU stored and it needs to use stored power, then it won't flicker anymore. Unless of course the time it takes between each EU to arrive is greater than the consumption. Which is once every 4 ticks. (1/5th of a second)

Quote from wierd

-snip-

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

Display More

Didn't need the windy explanation. I can see what it's doing. Do you think if I couldn't see what it's that I could have derived 0.25eu/t in the first place? No. The only reason conceivable for doing it the way he's done it is if EU's are coded as integers (thus, no decimals). In the long run, the result is the same. However, in the short term, there appears to be a problem. I have a suspicion that if EUs could handle decimals, and he DID code it as 0.25EU on EVERY tick, then we wouldn't be having this problem. To answer your previous quandry, THIS is how fractional EUs are handled.

I really should crack open the IC2 source. This isn't a hard problem to solve. -_-

On another note, this does explain my setup. I have a single solar panel powering 3 luminators. This functions, but it doesn't last the whole night (1/3 of the night). And that makes perfect sense given 0.25eu/t. A single solar panel will be able to power 2 luminators effectively through the entire night, in perfect harmony (the luminators draining all power just as the sun comes up for the next day)

[EDIT]

Decompiled IC2 and poked around for a minute... found the code. As I thought, the "ticks" that drive the energy consumption of the luminators are locally handled. It would probably be best if this was changed to check (globaltime % 4 == 0). That way, ticks will continue to pass whether the luminator has energy or not, and they will continue to consume energy at the desired rate.

[EDIT2]

Here's the problem:

As alblaka has mentioned before (elsewhere, probably), luminators are made up of two blocks. The blocks that emit light and the blocks that don't. The luminators that emit light are initialized with "ticker = -1". As soon as you put the luminator down, it executes this code:

ticker++; 
if(ticker % 4 == 0)

Thus, ticker moves up to "0" and the check returns true. That means it must consume 1EU, which has already been passed to it from the solar attached to the cable. Once that happens, energy will equal 0, and it must then turn off. Here's the kicker. To turn off, this luminator is REMOVED and replaced with an "off luminator tile". That luminator tile is then given 1EU, which turns it "on", so it needs to be removed again and replaced with a BRAND NEW luminator, starting at "ticker = -1".

Repeat.

What does this mean? It means what I said BEFORE! The reason for the flickering is BECAUSE of the transition between the on and off state, thus a buffer of w/e EU is not going to fix the problem. Just substitute "0EU' with "99EU" and "1EU" with "100EU" above and you're looking at what would happen if a buffer was given.
The only fix is to fix the root problem here, either have luminators run off of a global ticker, offset the current ticker (to start at 0 and thus make its first check on the fourth tick instead of the first tick), or change it so you're not replacing blocks to turn the light on/off. Or if you REALLY want to use a buffer, make it turn on at something more than 1EU from the "off" amount (Example: 100EU = on, 98EU=off)

Though, if you ask me (and you're not, I know), the easiest way to fix the problem is just to change
this:

ticker = -1;

to this:

ticker = 1;

offsetting the ticker, so that the first check will occur on the third tick instead of the first (could make it "2", but figured a bit of room for the solar to pass another EU would be best)

[EDIT 3]

Last edit, I promise!!!

If you guys need a workaround in the meantime, you can overcome the bug by placing a batbox in between the solar and the luminator, allow a bit of time for the luminator to charge... then take the batbox out and hook the luminators straight up to the solar. Works like a champ!

Quote from MJEvans

Yes, however that still doesn't fix the bug that the luminator is then /consuming/ that eU without providing any lighting duration for it.

Currently:

0eU (buffer) + 1eU (incoming) - 1eU (for on) = 0 eU ==> Luminator off (power evaporates without performing work)

What it should do:

'on for one more cycle' == buffer value of 1eU

0eU (buffer) + incoming + 1eU if buffer == 0 eU (reflecting 'off' to 'on' transition) -1 eU (for on) = incoming left in buffer (which is incoming - 1 lighting ticks)

Display More

There is a clear difference between >1 and >=1...

What i was saying is, it should be enough for the luminator to turn on when it has MORE than 1 EU stored and turn off if it has 0 EU stored.
But there is one issue remaining though, if the luminator is on and the last EU is consumed then it turns off and wastes the last EU.

How about making the luminator ONLY turn off if the luminator is asking for power but there is no power to take from storage?
So you send 1 EU to the luminator, the luminator turns on. The stored EU is now 0 but the luminator will ONLY turn off after it has gone through a light cycle, if one is present.

Quote from Plystire

-snip-

Didn't need the windy explanation. I can see what it's doing. Do you think if I couldn't see what it's that I could have derived 0.25eu/t in the first place? No. The only reason conceivable for doing it the way he's done it is if EU's are coded as integers (thus, no decimals). In the long run, the result is the same. However, in the short term, there appears to be a problem. I have a suspicion that if EUs could handle decimals, and he DID code it as 0.25EU on EVERY tick, then we wouldn't be having this problem. To answer your previous quandry, THIS is how fractional EUs are handled.

I really should crack open the IC2 source. This isn't a hard problem to solve. -_-

On another note, this does explain my setup. I have a single solar panel powering 3 luminators. This functions, but it doesn't last the whole night (1/3 of the night). And that makes perfect sense given 0.25eu/t. A single solar panel will be able to power 2 luminators effectively through the entire night, in perfect harmony (the luminators draining all power just as the sun comes up for the next day)

[EDIT]

Decompiled IC2 and poked around for a minute... found the code. As I thought, the "ticks" that drive the energy consumption of the luminators are locally handled. It would probably be best if this was changed to check (globaltime % 4 == 0). That way, ticks will continue to pass whether the luminator has energy or not, and they will continue to consume energy at the desired rate.

[EDIT2]

Here's the problem:

As alblaka has mentioned before (elsewhere, probably), luminators are made up of two blocks. The blocks that emit light and the blocks that don't. The luminators that emit light are initialized with "ticker = -1". As soon as you put the luminator down, it executes this code:

Code

ticker++; 
if(ticker % 4 == 0)

Thus, ticker moves up to "0" and the check returns true. That means it must consume 1EU, which has already been passed to it from the solar attached to the cable. Once that happens, energy will equal 0, and it must then turn off. Here's the kicker. To turn off, this luminator is REMOVED and replaced with an "off luminator tile". That luminator tile is then given 1EU, which turns it "on", so it needs to be removed again and replaced with a BRAND NEW luminator, starting at "ticker = -1".

Repeat.

What does this mean? It means what I said BEFORE! The reason for the flickering is BECAUSE of the transition between the on and off state, thus a buffer of w/e EU is not going to fix the problem. Just substitute "0EU' with "99EU" and "1EU" with "100EU" above and you're looking at what would happen if a buffer was given.
The only fix is to fix the root problem here, either have luminators run off of a global ticker, offset the current ticker (to start at 0 and thus make its first check on the fourth tick instead of the first tick), or change it so you're not replacing blocks to turn the light on/off. Or if you REALLY want to use a buffer, make it turn on at something more than 1EU from the "off" amount (Example: 100EU = on, 98EU=off)

Though, if you ask me (and you're not, I know), the easiest way to fix the problem is just to change
this:

Code

ticker = -1;

to this:

Code

ticker = 1;

offsetting the ticker, so that the first check will occur on the third tick instead of the first (could make it "2", but figured a bit of room for the solar to pass another EU would be best)

[EDIT 3]

Last edit, I promise!!!

If you guys need a workaround in the meantime, you can overcome the bug by placing a batbox in between the solar and the luminator, allow a bit of time for the luminator to charge... then take the batbox out and hook the luminators straight up to the solar. Works like a champ!

Display More

the Batbox in between to let the luminator charge up seems a lot more work than simply right clicking on the luminator with an RE-Battery to give it a little charge.
The buffer would work because while you are replacing the "1" with "100", you are not replacing the "0" with "99"
it turns on at 100, but still only turns off at 0. so it's once again the same as charging it a little with a batbox or with an RE-Battery.

I'll try to make my posts less windy...

Quote from Alblaka

Nope. If the storage >0 (which is the case with 99), Luminator wont turn off :3

Doesn't matter anyways, though, as the Luminators will be reworked once more. Found a way to use "dynamic" (as in brightness-scale, not colorful) lightning.

Very cool, I look forward to seeing this new implementation in action.

@weird:

True about the RE-battery. I never really use batts to charge up anything, so that didn't cross my mind.

Alblaka:

Yes, true, which fits in with my part about if you really WANT to use a buffer, but what's the point of adding a 5 second "charge up" time to the luminator when you can shorten that to a <1 second fix (change -1 to 1) and a 2/20 of a second (effectively 2 ticks) "charge up" time?

Glad you can make the lights change lighting level without replacing the block itself. I'm glad one of my suggested fixes was used.

And while you're in there can you change "tick % 4" to something more along the lines of "tick % 128"? That'd be boss.

Quote from Plystire

And while you're in there can you change "tick % 4" to something more along the lines of "tick % 128"? That'd be boss.

Wouldn't that make the luminator take up to 6.4 seconds to react to input?

Quote from Cadde

Wouldn't that make the luminator take up to 6.4 seconds to react to input?

it would make the luminator use 1eu every 6.4 seconds

Quote from wierd

it would make the luminator use 1eu every 6.4 seconds

Yes, but the ticker is also used to update the luminator? I could check the source though since i still have it open...

Yep, that would make it not run the code as often. Though making it like this would solve all problems:

TileEntityLuminator.java:58

ticker++;
            if(ticker % 128 == 0)		// Changed to one EU every 128 ticks or 0.0078125 EU tick. Only use this if you want less consumption ofc.
            {
                energy--;
            }
            if (ticker % 4 == 0)
            {
                if(energy < 0)			// Changed to < 0 instead of <= 0, this should prevent flickering.
                {
                    worldObj.setBlockAndMetadataWithNotify(xCoord, yCoord, zCoord, mod_IC2.blockLuminatorDark.blockID, worldObj.getBlockMetadata(xCoord, yCoord, zCoord));
                }
            }

TileEntityLuminator.java:104

if (energy <= 1)		// Added a check to make sure the luminator only takes energy when it needs it from cables (batteries still will feed them)
        {
        	energy++;		// Changed to ++ instead of += i, this makes the luminator only take one EU. When fed from cables it should only have a max of 2 EU stored so it will shut off faster.
        	i--;			// Remove one EU from the incoming energy
        }
        return i;			// Return the remaining EU's of the incoming energy. (Not sure about this, not entirely sure this is how it works, maybe it's the other way around?)

So i changed quite a few lines in the last code section... Now, luminators will be fed by batteries just the same (and they will stay on for as long without the 128 tick change and 32 times as long WITH the 128 tick change.
When fed by cables they should turn on immediately, and turn off in 8 ticks max (0.4 seconds) when the cable stops sending power to it. The cable thus has to send energy at least once every 8 ticks or the luminator shuts off.
Also fixed flickering.

Though I haven't tested the code!

Quote from MJEvans

That last change /still/ breaks my idea design of tin wire with a solar on top and two luminators dangling on the sides as as street lamp. Maybe the EU network could be split slightly so that it can tell the difference between packets originating from a generator and those from storage? That would allow for devices to operate with 'a single work unit' charge level when attached to storage, and otherwise buffer fully if taking from a generator.

Why? Solar output 1EU/t which is enough for my change above? The luminator turns on when it has 2 EU stored and doesn't turn off until it has LESS than 0 EU stored.
The problem though is you can't split the power output from a single solar panel. So it can only light ONE luminator if it's storage isn't full. Simply filling one of them using a battery will make the other luminator turn on.

Or am i missing some odd code path here?

Why not just adding lamps instead of "glowing" cables?