Yeah, but how would you have a non-TileEntity block that iterates to sky?
You can check if a Block at XYZ has Sunlight or not. Not only the TileEntity, with the Sun shining on it.
So check or iteration? I doubt each zombie iterates to sky.
Yeah, but how would you have a non-TileEntity block that iterates to sky?
You can check if a Block at XYZ has Sunlight or not. Not only the TileEntity, with the Sun shining on it.
So check or iteration? I doubt each zombie iterates to sky.
So check or iteration? I doubt each zombie iterates to sky.
Check. Why the hell would I iterate to sky for something what has a Sunlight-Map in the World.
Check. Why the hell would I iterate to sky for something what has a Sunlight-Map in the World.
Solars did that a while ago..
Solars did that a while ago..
Why not anymore?
Ok, question.
Why do the panels need to check for sunlight? Does Mojang not have some sort of lighting update function like the block update function?
Ok, question.
Why do the panels need to check for sunlight? Does Mojang not have some sort of lighting update function like the block update function?
Torch powered solars anyone?
Torch powered solars anyone?
Yes, but you just check when you get a lighting update if the light is sunlight. As for ENet you just send packets from the world time, and send them in larger chunks (maybe 6 EU a packet which is the upper limit for tin. But really there's no reason why solar shouldn't require glass fiber cable).
something shoud be done to make spamming solars obsolete, what about SINGLE SOLAR PER CHUNK?
what about SINGLE SOLAR PER CHUNK?
what about single Qarmor per server?
Why not anymore?
Checking for blocks above them and not using the light map
what about single Qarmor per server?
I think this suggestion is a good Idea, but there is no reason explaning that.
What I don't get about this discussion: If one were to code a combination of "solar controller block" which emits energy for all connected "panels" (not the standard ones, I mean new ones which only serve to provide area to the controller), you wouldn't have to check for sunlight for every connected panel every time. As I understand, at the moment panels check for light every second?
Have this contraption randomly pick one panel every second and check this one for sunlight. If no sunlight even on this single panel - no energy from the whole system (till the next successful lightcheck).
Probability will adjust the overall output of this system over time (since especially solars are made to be placed and left alone). Have the controller register and save connected panels, so it doesn't have to parse its surroundings for panels every time. Give the controller a range of, let's say 16 blocks - this way it could cover 256 panels at the cpu time of a single one. Uses a bit more memory, though...?
But this sounds to me as if this should massively reduce the lag caused by a big solar array...
EDIT: In addtion, one could use such a system to balance the solars better... make the additional panels cheaper than standard solars (for example, 1/5 of the cost) but have them output comparably less (about 1/4). This way you get a reward for using them (efficiency!), but have to pay with big areas and nifty cabling..
First part math is not bad imho. Probability will level output right.
But second math is terrible. Output power should be proportional to solar energy used. But you suggest 1/4 output from the same size field.
Yes, I suggest exactly that. (Note: but from a field that also costs just about 1/5!) Why is that terrible? Please explain your reasoning.
They just seem too small to me as they are now. The big areas needed are a viable problem of solar energy generation in RL. If you had to use similar big areas to generate power in IC, you'd have to cover all your roofs, or use a big desert area, and actually worry about how to get your energy to the MFSU... I would love such a challenge (it's only a small one, but hey ^^). At the moment they're just... boring. I hope I'm not the only one who feels this way
IMHO Solar is meant to be be balanced by space used. That's why something like compact solars isn't included in standard IC2. It seems to me the balance doesn't work at the moment, so compact solars has to be used by server admins to lessen the lag caused by solarspam. Increasing the area used by solar decreases the convenience of the generator, that's where its main advantage lies at the moment.
Do you want solar fields to be 5 times larger?
Do you want to keep them all in memory?
Don't you think it's just boring?
Problems with lag?
*Installs compactsolars*
No more lag!
I think "secondary" solars should be placed and removed automatically, when "primary" solar is placed. So, it's very much like compact solar, but with "fair" space requirement. You place it, it "unfolds" and start working. Or don't if there is not enough space around.
Technically, the lag is still there even with CompactSolars, but it's substantially less noticeable than 8, 64 or 512 individual solar panels sending out 1 EU/t packets at the same time (Increased number of calculations with more packets versus lower number of Enet calculations with larger packets being sent out). Although in SSP local server, the 'lag from individual panels wouldn't be as bad as if you were playing on a server like Industrial Rage where EVERYONE was spamming the hell out of the solars and takes a toll on the server's CPU (and technically, the client's as well what with processing information sent from the server (at least I believe that this is the case)).