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

Ah i see. AFAIK making Energynet aware of the source of the power sent is not possible without a major rework. What if you could place 2 RE batteries, 3 glass panes, 2 coal dust and 1 redstone dust together with a solar panel in the crafting grid to make an "Advanced internal battery solar panel" that, during night time, will switch to battery power. During the day that solar panel will emit 0.5 EU/t and send another 0.75 EU/t into it's internal battery to allow it to have a constant 0.5 EU/t during day/night.
A night is 12,000 ticks long so that means the internal storage only needs 6,000 EU but we give it 18,000 EU storage so the internal battery can be used to survive a full day of rain and another night. It will take 4 sunny days to completely fill the internal battery. Thus, if it rains 1 out of 5 days then you are fine.

Quote from Cadde

Ah i see. AFAIK making Energynet aware of the source of the power sent is not possible without a major rework. What if you could place 2 RE batteries, 3 glass panes, 2 coal dust and 1 redstone dust together with a solar panel in the crafting grid to make an "Advanced internal battery solar panel" that, during night time, will switch to battery power. During the day that solar panel will emit 0.5 EU/t and send another 0.75 EU/t into it's internal battery to allow it to have a constant 0.5 EU/t during day/night.
A night is 12,000 ticks long so that means the internal storage only needs 6,000 EU but we give it 18,000 EU storage so the internal battery can be used to survive a full day of rain and another night. It will take 4 sunny days to completely fill the internal battery. Thus, if it rains 1 out of 5 days then you are fine.

How about keep the recipe the same, but reduce the internal storage to just enough to solve the flicker. Then add an interface that lets you throw an RE battery in it if you want more storage. Would not only give you the choice about storage, but also allow for quickly fully charging one manually. Plus bonus RE battery chargers

AFAIK, solar panels can already charge RE batteries.
And the reason i came up with the concept of an advanced solar panel like that is to account for the ability to operate through a rainy day, until the next morning. Thus making that solar panel better than the original one. (Even though i think solar panels are not balanced yet)

I agree that we could use an 8EU/t tier of power, specifically for stuff like this. Luminators are showing why 32 EU/t is too much for certain applications.

Yup not sure why we have Tin cables but nothing to step it down to the ULV when most of the simplest generators produce more then the cable can handle (minus Wind, water and solar)
I generally survive on Generators myself or a GeoGen (I get worlds with lots of lava it seems), and a step down to ULV would be usefol for keeping a constant power to say, a certain furnace that need 1 EU to stay at max heat or as our problem seems to run long lines of Luminators

Quote from SilvaDreams

Yup not sure why we have Tin cables but nothing to step it down to the ULV when most of the simplest generators produce more then the cable can handle (minus Wind, water and solar)

Because the current implementation of the energy net only limits voltage, not current. If you could step stuff down to ULV, tin cables would be almost as good as glass.

My understanding of tin cables was that they were intended to help build solar/wind/hydro farms without having have batboxes everywhere, not as an actual voltage tier. Only now that we have stuff that uses those tiny amounts of power instead of producing, we have a similar problem that's harder to solve without unbalancing things... One way to do it that would actually be a big improvement would be to have a "lighting transformer" block that can send out 4EU packets, but only to luminators. Also let it send up to 8 packets per tick, so it can support up to 32 luminators on LV.

I have 7 luminators lighting up my house. Initially I had a solar panel for each 2 luminators (I figured 1 EU/t would provide 2x the power necessary to run 2 luminators, so they would have enough to last through the night as well). The first pair I hooked up immediately started flickering and remained that way for 2-3 minutes, while I ran at 5 fps. This was on SMP. I settled on having 4 solar panels hook into a series of 2 batboxes, then copper cabled out to all 7. I figured with 7x10k EU storage + 2x40k EU storage I would have enough energy to permarun the luminators, even through a few rainy days. Unfortunately this isn't the case, they seem to be draining way way more than that. And so if I do not go and refill the batboxes every week or so, I end up with flickering lights that cause some major epic lag (almost as bad as the sound bug).

I didnt really seem to have issues with lag while my luminators were flikering, i love the effect though, im going to use it to make a hallway lit with flickering neon.

I really hope there still remains a way to get the effect after it's fixed.

I have something that might be related in a way.
I just found out, that if I place a batbox directly under a SolarGen, tha batbox can not be accessed anymore, even I use the latest Forge (1.4.1.60)
After placing an insulated copper cable between the two, it worked like it should.
May it be, that SolarGens aren't able to transfer energy to directly adjactant receivers anymore?

EDIT: Now I'm confused... It works in one place, in another it doesn't...

About that flickering light thing -- That almost crashed my client. I was migrating things from an old map to a new one, and one of them had four luminators attached to 150+ solar panels with a massive mesh of tin cable. Plenty of power, but the light would just flicker and the framerate dropped to ... 2 ... If I was lucky. I'm guessing the branching of the 'i need power' seek requests across that much meshed cable really threw the client into a frenzy. Putting a batbox in between the tin cable mesh and the luminator fixed the performance problem and the flickering.

The reason I'm commenting though is that this issue taken to large scales cripples the game engine.

Actually I may be able to shed some more light on the situation. Try building this:

Charged MFSU -> Transform power down to LV through two transformers -> Fiber line -> 35 luminators.

In my case, the luminators are spread out over the roof of a big room I'm building, but I don't think shape matters much. Connect the output of the transformer to the main line last so that all the luminators get power at the same time.

Expected: All the lights should get power, and turn on. An eu-meter will show you massive power being transmitted for a few seconds to fill up the internal luminator capacitor, followed quickly by a low but relatively constant flow of power to keep the luminators topped off.

Actual: the first few closest to the transformer get their charge and the ones behind start blinking. If you disconnect the line halfway down or so, (starting where the lights blink) and wait for it to stabilize and reconnect, it'll charge up the next group. An eu meter *will* show the high current to get the lights charged, and then a low but constant *not pulsing* current to keep them topped off... but see below.

What isn't happening: If you leave the line connected, eventually the internal capacitor on the luminator runs dry, and they shut off, and then go back to blinking like mad. The luminator is *not* charging itself while on! It *appears* to draw a very low current while on, but this could be a glitch with the eu-meter. I just watched half my roof's lights go out, while plugged into a live MFSU. There was power aplenty.

If it's coded the same way the other ic2 machines are, shouldn't it be able to request an eu packet once it has enough room for it in its internal storage? I do not know how a transformer outputting at 32eu is suddenly only sending 2-5 eu at a rather steady rate, and not pulses of 32 like it would to any other ic2 machine.

Edit: Here's some version info for you:
Minecraft 1.2.3
Forge: 1.4.1.59
IC2: 1.81