N00b EU Question and weather

[Alizel]

hey guys ive looked everywhere and i dont understand what is happening.

i have 2 HV solar pannels outputting power. the cable is long but the loss is normal however when i put 2 or more mfsu's (32) i get a huge drop in power. drops from 1016 eu/t to like 763 eu/t

wtf? is it just a reading error or am i actualy getting drop? is it because of the cable splitting into the mfsu's? they are glass fiber cables

ive searched everywhere.

also my server is brand new but im not getting weather to cycle normaly. i enabled ops on my account and turned rain on. but it justs rains allday every day forever. how do i make weather cycle normaly? like snow n'at.

thanks d00dz.

[Omicron]

Your phrasing is ambiguous. Define "the cable is long". Where are you putting your MFSUs? How and where are you measuring your throughput? How many MFSUs exactly correspond to which exact measuring numbers? Can you provide a screenshot? Have you tried looking if the time that 5 MFSUs take to charge to 100k is the same time a single MFSU takes to charge to 500k?

If you say "weather does not cycle normally", does that mean it does cycle, just not in a way you consider "normal"? How do you define "normal"? Do you expect snow to happen outside of arctic biomes?

[Alizel]

sorry. i dont know how long about 200 blocks. kind of irrelivant, im measuring with an EU meter, ive tested at the length of my cable a single mfsu and measured to see 1016 eu/t so thats acceptable. it seems the problem is when i have multiple batterys in paralell (not sequence/series) paralell.

i have tested with 1,2 and 3 mfsu's in parallel and i see a substantial drop in eu/t from 1016 at the same length, 2 mfsu's the packet size becomes 990 and 3 is , 979

i am always measuring between the battery and the solar array

it seems the only option is to measure fill time. i was hopeing to avoid that. i will see about a screen shot.

as for weather, it hasent rained synce the server went up, and it has not snowed (inside arctic biomes), the server was not an upgrade from previous builds as ive read that can break it its a fresh server about a month old.

oping myself and turning rain on only just makes it perma-rain.

thanks

[Omicron]

Curious. I too have a server that's about three weeks old, and it rains plenty by itself. In fact, it rains ridiculously often. You can't go more than three dry Minecraft days without a new torrential downpour lasting at least a whole day and night. It's extremely annoying for anyone interested in using solar power, so maybe you should consider yourself lucky

My server is just a standard Tekkit 3.1.2 server with EE and CompactSolars turned off, and a tiny Anti-Enderman-Griefing plugin.

As for the readouts, I honestly can't explain that. But, here's an experiment you can try.

Grab a MFSU and some lapotron crystals. Put the MFSU next to the solar arrays (but disconnect the solars for the moment). Discharge a lapotron crystal into it, then make sure you have one empty MFSU on the other side, and connect the glass fiber cable to the output. You should then have exactly one million EUs going down the cable at the same packet size that the HV arrays normally put out. On the receiving end, you should get a number that's a bit less than one million, due to distance loss. Write down that number. Also check what your EU meter what the cable says during transfer.

Now run the test again, except now you put multiple MFSUs on the receiving side. Like, say, 10. Don't forget to make sure all are empty. Once more, you charge up the source MFSU with exactly one million EUs, and let it transfer. Then, check the cable readout,and check how much power arrives on the receiving side. If the readout differs, but total power received is virtually identical to test #1, then the readout is bogus. If the readout doesn't differ, then something is weird with your setup (since the readout does differ when the solars are hooked up). If total power transferred is noticably less, then you probably found a bug.

[gavjenks]

So a 200 block long cable would lose 5 EU per packet, times 2 packets when it is hooked up to one MFSU (one from each solar) = 10 EU lost, which is almost exactly what you see.

When you hook it up to 2 MFSUs, each solar splits its packets to go to each MFSU, so now it is 5 EU lost x 4 packets = 20 lost. You report losing 26, but that might be within measurement error? I'm not sure.

3 MFSUs = 5 Eu lost x 6 packets = 30 EU lost, and this time it is indeed about exactly 10 Eu less between your two measurements.

Pretty sure that's what's going on. Solution is very simple: put your MFSUs in sequence. You will no longer be able to output beyond 512 EU/tick from your batteries, but since you were bending the rules anyway by sending 1016 through a cable that's supposed to handle 512, I don't feel too much sympathy.

If you NEED the bandwidth, then you'll have to suffer the extra losses.

Solution #2: Don't send your power through a completely ridiculous 200 block long cable?? Why is that ever necessary?

Solution #3: Build a second glass fiber wire next to your first one, and have each solar be dedicated to one MFSU. Almost definitely not worth it (power savings would take probably days or weeks to pay off the extra diamond cost)

[GreenWolf13]

Gav, fibre cable handles 512 eu PACKETS. So you can hook it up to as many hv solars as you want and it will be fine. the problem comes when you have over 512 eu in one packet, say from a CASUC Reactor.

[Omicron]

Yeah, the cables are doing perfectly fine and there's no "rules bending" going on here.

But the thing with splitting packets, that's interesting and a very good point. Come to think of it, there's no way the two HV arrays could arrange with each other which of them charges which MFSU when. So obviously each HV array must charge all MFSUs at the same time, which means splitting up its power output. So if each packet loses 5 EU over the distance and you had one receiving device, it would send one 512-EU packet that would arrive as one 507-EU packet. But if there were 32 receiving devices, it would send 32 16-EU packets, which would arrive as 32 11-EU packets. Thus 512 EU/t turn into 352 EU/t.

As gavjenks said, you can put the MFSUs in sequence - at least, have only one receive from the solars and then hook all the others up to that one. But yes, it will limit you to the 512 EU/t output that a single MFSU can do. You might be able to circumvent that with a clever misuse of transformers... I am not sure it will actually work this way, but you can try.

At the receiving side, place a HV transformer that transforms up to EV (2048 EU) packets from the 512 EU ones the solars send down the wire. Then, place a second HV transformer directly next to it that once again transforms the 2048 EU packets down to 4x 512 EU packets. Then, hook up to 4 MFSUs up to that transformer. Theoretically, if the first transformer counts as a single receiving device, it will receive singular 512 EU packets no matter how many MFSUs you want to hook up further down the chain. Then, the second HV transformer will put out the 2048 EU packets it receives from the first one in 4x 512 EU packets if necessary - four times the throughput of a single MFSU. So you would not introduce a throughput bottleneck in this case.

Mind you, this is pure theory that I have never tried out before :p

[gavjenks]

Gav, fibre cable handles 512 eu PACKETS. So you can hook it up to as many hv solars as you want and it will be fine. the problem comes when you have over 512 eu in one packet, say from a CASUC Reactor.

yes I understand how packets work.

What I mean by "rule bending" is that in real life, cables obviously cannot take infinite current. And since industrialcraft is generally set up to be pretty realistic, it feels exploitative to me whenever I have a setup that sends multiple maximum size packets through a cable in a single tick.

Don'tget me wrong, I do it all the time. For instance, instantly lethal 40,000 EU/tick surges through uninsulated HV cable as traps, etc.

BUT I'm also not going to lose any sleep when somebody is unable to make a setup that makes no actual electrical sense. Because it's really not in the spirit of the rest of the entire mod, making it, IMHO, a bonus here and there when it works. Not something to be relied on 100% or to complain about when it doesn't work the way you want.

Note: the transformer thing mentioned above might work. I doubt it (will probably split up each bunch of 512 EUs just like the MFSUs), but worth a try. Maybe test it in SSP first.

[Aeolos]

BUT I'm also not going to lose any sleep when somebody is unable to make a setup that makes no actual electrical sense. Because it's really not in the spirit of the rest of the entire mod, making it, IMHO, a bonus here and there when it works. Not something to be relied on 100% or to complain about when it doesn't work the way you want.

Call me crazy, but I feel like he wasn't asking you to lose sleep over it.

And saying that you don't "rule-bend" based on real-world rules in tekkit makes me laugh. Hahahahahah

[gavjenks]

Call me crazy, but I feel like he wasn't asking you to lose sleep over it.

And saying that you don't "rule-bend" based on real-world rules in tekkit makes me laugh. Hahahahahah

for industrialcraft, not tekkit.

That mod in particular is obviously designed with realism strongly in mind. Thus, it feels exploitative to do things with industrialcraft devices that are blatantly unrealistic. Another example would be using RP machines to push water buckets through a deployer back into an IC water mill automatically. Feels exploitative, because as is clearly explained on the IC forums, water mills are meant to be filled with buckets when "manned," I.e. using your muscle power to lift buckets in (which is vaguely realistic since your character needs to eat food). Whereas getting more energy out of falling water than it took to lift it is not realistic at all.

This logic only applies to industrialcraft. Doing magical things with EE does not feel exploitative, because it is designed to be magical.

[GreenWolf13]

for industrialcraft, not tekkit.

That mod in particular is obviously designed with realism strongly in mind. Thus, it feels exploitative to do things with industrialcraft devices that are blatantly unrealistic. Another example would be using RP machines to push water buckets through a deployer back into an IC water mill automatically. Feels exploitative, because as is clearly explained on the IC forums, water mills are meant to be filled with buckets when "manned," I.e. using your muscle power to lift buckets in (which is vaguely realistic since your character needs to eat food). Whereas getting more energy out of falling water than it took to lift it is not realistic at all.

This logic only applies to industrialcraft. Doing magical things with EE does not feel exploitative, because it is designed to be magical.

So you're saying that UU-matter is realistic?

[gavjenks]

Yes, UU matter is plausible, in an abstract sense. It makes the most sense if you consder UU matter as an abstract representation of whatever a mass fabricator would have made internally in the machine, if it had a much more complex GUI.

If we pretend for a moment that the mass fabricator built all its stuff inside the machine, instead of giving you a generic matter currency, then it is essentially just a reverse nuclear reactor, taking energy and using it to bind neutrons and protons into a more massive complex than what they began as.

This is not only realistic and plausible, but is almost exactly what particle accelerators do in the real world.

In fact, particle accelerators today are already capable of creating desired types of matter, and some of them actually have equipment for generating and storing small quantities of antimatter. Presumably, they could store other things too, if it were economically worthwhile to build and run such massive machines to make mundane things.

A mass fabricator can simply be conceived of as a similar device as a particle accelerator, but with more advanced technology that allows compactness and finer control of exact products produced.

UU matter, then, is simply a gameplay contrivance, meant to abstractly represent the various possibilities of what could be made inside of such a machine, but in a format that allows minecraft players to use the much more intuitive and familiar crafting bench system, instead of a very confusing mass fab GUI.

Similar to how, in Dwarf Fortress, you build a catapult with three "catapult parts," but it isn't specified which one is which part when they exist as parts. It simply saves the player from having to worry about the annoying micromanagement of making the correct number of each type of part, but it is assumed that in "reality" there would be 1/3 of each kind at the moment they were made.

[Alizel]

So a 200 block long cable would lose 5 EU per packet, times 2 packets when it is hooked up to one MFSU (one from each solar) = 10 EU lost, which is almost exactly what you see.

When you hook it up to 2 MFSUs, each solar splits its packets to go to each MFSU, so now it is 5 EU lost x 4 packets = 20 lost. You report losing 26, but that might be within measurement error? I'm not sure.

3 MFSUs = 5 Eu lost x 6 packets = 30 EU lost, and this time it is indeed about exactly 10 Eu less between your two measurements.

Pretty sure that's what's going on. Solution is very simple: put your MFSUs in sequence. You will no longer be able to output beyond 512 EU/tick from your batteries, but since you were bending the rules anyway by sending 1016 through a cable that's supposed to handle 512, I don't feel too much sympathy.

If you NEED the bandwidth, then you'll have to suffer the extra losses.

Solution #2: Don't send your power through a completely ridiculous 200 block long cable?? Why is that ever necessary?

Solution #3: Build a second glass fiber wire next to your first one, and have each solar be dedicated to one MFSU. Almost definitely not worth it (power savings would take probably days or weeks to pay off the extra diamond cost)

this helped alot thanks.

i assumed the packets would split at a cable junction but they dont. i have minimized the loss greatly by placing a HV transformer right befor the junction to all the batterys it measures at 1014 eu/t lol which is acceptable. certainly better than the 763 i was getting lol, its just HV-HV lol the transformer is acting as a capacitor now.