Posts by FunnyMan3595

Actually, the CropCard addons are really simple. The annoying part is keeping them up to date. I may merge my CropCards later on and just enable individual pieces with config switches, just so there's only one mod to maintain.

Multiplayer just arrived. As far as Bukkit goes, I'm not sure what needs to be changed. If someone else wants to port it, go ahead, the code's part of the usual download. I haven't bothered to apply a specific license yet, but as long as you give me credit, I won't mind.

And I've offered to do said rewrite. So you've *still* missed something.

I sent you a PM on the subject for a reason. I believed that you had made an honest error, and offered advice quietly. I didn't see a reason to chastise you in front of others. But since it seems you'd rather continue the discussion in public, I'm willing to accept that.

The heart of my complaint is that of four threads I have posted between Bugs and Submissions, I have seen you reply to two. In both cases, your reply has been uninformed, abrupt, and dismissive. This thread is by far the worse of the two, because your reply makes it clear that you read absolutely nothing save the title. If you had skimmed the first post even slightly, you would have noticed that the bug I was reporting was a problem with the code, not a simple difference from expected behaviour. The code was objectively wrong, because it used invalid data. Had you taken thirty seconds to examine the code in question, you would further have noted that its documentation stated the intended behaviour, and that this behaviour matched my interpretation, not yours.

After that first contact, you can imagine my lack of surprise when the second time you reply dismissively to me, it's in the middle of a series of replies sent at a rate of over one per minute. I will grant that it's possible you had read previously and then replied en masse, but even so it's well-advised to spend some time reacquainting yourself with a thread before replying. Memory is not perfect; details do get lost.

Between these two occasions, I come to wonder if you are fit for the duties you are performing. On the bug report, I have no evidence to suggest that the bug would have been fixed for the next version of IC2 had I not informed Alblaka of it directly. And a less-determined person would have been disheartened by a member of the IC2 team cavalierly dismissing their suggestion, especially when it failed to communicate the heart of the complaint: not "this is undesirable", but "this is hard". So it seems that you're allowing bugs to slip through the bug forum and squishing good ideas in the suggestion forum. In short, you are failing at your duties in both.

Finally, in reply to your assertion via PM that "I always do oneliners and noone complains.": My objection is not with the length of your posts, except insofar as that it reinforces the impression of them being dismissive. By replying in such general terms (a necessity for a short reply to a nuanced topic) and making a unilateral declaration against the post, you have the effect of coming by with a large "Rejected by IC2 Staff" stamp and using it on the thread. And since the meat of my objection is inattention, you are applying that stamp carelessly.

Quote from RichardG

Would be hard to adapt to the new changes.

I've already addressed this criticism in several forms. The one I believe matches your objection best is this:

Quote from FunnyMan3595

The changes are set up so that they should be straightforward for most people. You might have to rewire your generators a bit to avoid overloading cable (and to make up for the nerf to tin cable distance), but beyond that, you don't normally have more than four packets on a cable in the first place unless you're transforming from HV to LV, and the new setup handles that gracefully. Your mass fabber will take less power if you've been feeding it 512 EU/p on multiple sides, but that's hardly a game-breaking issue. The only people who are going to be facing lots of melted wires are the ones who were (ab)using the lack of a packet limit. But that's a fundamental truth of any balance fix: it harms the people who were making use of the imbalance.

I would like to see direct BC compatibility in IC2, but for reasons that nobody else has raised yet: balance, stability, and efficiency.

Balance: Most of the BC<->IC2 mods seem to think that the conversion should be lossless. That is patently ridiculous. You're converting between two very different forms of energy; it should be highly lossy. 20% or more each direction, preferably configurable. Further, recall that Buildcraft's Combustion Engines rely entirely upon non-renewable resources. Attaining that level of buildcraft power should require considerably more resources and/or EUs, or else finding oil becomes unimportant. The IC2 team has shown that they understand balance, so I would very much like to see how they would handle it.

Stability/efficiency: I've run into serious issues with every compatibility mod I've tried. Either one of the converters makes me lag to hell if I'm near it, or one of them is buggy enough to be frustrating. Again, these are issues that the IC2 team is used to, and by handling it themselves, we discard the hydra that is current compatibility mods: what one mod fixes, the next may break all over again.

Quote from allaryin

One does not simply retrofit the innards of something this complex. Even if I had the code, I wouldn't want to touch that particular beastie unless it was a crashing bug. As it is, IC2's power grid is amazingly efficient. Even with some 50 generators talking to a few dozen storage devices powering 0-20 machines at a time in my server's central hub... there is no performance degradation. The game continues to run well.

[...]

The only realistic way to introduce the full scope of changes you are proposing is to write them from scratch.

You overestimate the difficulty. The vast majority of these changes are small tweaks that could be placed on the existing engine easily. The only one of the changes in the original post that's tricky is counting packets per tick for cable. LoTEPs would require some additional changes be carried through the code, but even that's manageable.

Further, please understand that I mean no offense when I say that your idea of large scale is pitifully small, from an algorithmic perspective. A quality energy net should be able to handle thousands of sources and sinks, transmitting over a complex honeycomb of tens of thousands of cable pieces, without making the game noticeably slower. It was not too long ago (and might still be the case, as I haven't tested recently) that IC2 would struggle if you had a solid grid of cable under a smallish solar plant. That we have a working energy net at all is massive credit to Player, but please do not assume that his implementation is excellent simply because it's working well for you.

Yeah, I pretty much get that now, but it's a theoretical and tenuous grasp. By my understanding, it's completely fair to use the definition of current that I gave: the number of packets per tick. That gets more accurate if you allow fractional packets per tick, like I was proposing. 0.25 p/t at 32 EU/p is a completely sensible way to send 8 EU/t. Of course, at that point, the "packet" term is breaking down.

Thanks to you, I finally figured out why my water analogy had been breaking down. I had been trying to treat water as energy (EUs), but water is more like electrons: the medium that carries the energy. If you envision water flowing through a pipe, voltage is pressure (how hard it pushes), current is flow rate (water/time), and power is the strength of the entire water flow. If you run it for a bit, then turn it off, the amount of work you did is energy.

The physics of water start to get in the way after that, as you hit things like flow rate being dependent on pressure and pipe diameter... or is it that pressure is dependent on pipe diameter and flow rate? Or both, depending on what you're controlling for? And does that line up neatly with some property of electricity, or not? It gets to the point that most people (myself definitely) don't understand hydrodynamics well enough to keep trying to draw the comparison. I find it amusing, actually. Like (I suspect) most people, I think I have a pretty good grasp of how water works. I use it every day, and unlike electricity, it's something I can see, hear, touch, and move by hand. And yet in trying to draw a comparison to the fundamental concepts of electricity, I find that I really don't have a full understanding of how it works.

Let's create a new unit to replace packets. For lack of better inspiration at the moment, call it LoTEP: Lots of Tiny Energy Packets. A LoTEP is a specific but undefined number of energy carriers, each carrying some small fraction of an EU. (The specific term is unimportant, but that meaning should remain.) EU/LoTEP is thus our new unit of voltage: The number of EUs carried by a full LoTEP. A cable carrying 0.25 LoTEP/t is sensible now, because while a quarter of a packet is weird, a quarter of a bunch of tiny packets makes sense.

To extend and improve upon earlier terminology, the power of a cable can be stated as, for example, either 128 EU/t or 4x32 EU/t, the latter of which is short notation for "4 LoTEP/t at 32 EU/LoTEP". Since the units cancel out appropriately, using EU/t for this notation is sensible: simply multiplying as indicated gets you a correct result, while 4x32 EU/p had the danger of being converted to the wholly-incorrect 128 EU/p. If your cable is running at less than full capacity, you could have it carrying 2.76x32 EU/t.

Thinking about it, I've decided on a suitable behaviour for the EU meter. It has two modes:

• Verbose mode (default): Average power over 241 ticks: 24.6 EU/t. \n Maximum voltage: 32 EU/LoTEP. \n Maximum current: 4 LoTEP/t
• Terse mode: 24.6 EU/t, max 4x32 EU/t (241 ticks)

Switching between modes is handled as usual.

The tone of discussion: Could we please stop yelling at each other and throwing insults? It's not nice, it's bad for the community, and it makes it harder to find the actual reasoning in the thread. If you think that someone (myself included) is wrong, say so and say why, but don't be an ass about it.

My electrical knowledge: Honestly, I thought the paragraph about "Let's drop the real-world units because they're confusing." would have clued everyone in to the fact that I'm not an electricity person. You know why I sound knowledgeable on the topic? It's because I've been mulling this problem over for weeks, and spent two sessions on Wikipedia. A few hours a couple days previous, to gain an understanding of the basic concepts, and then constantly referring back to it as I wrote the original post. My basic reasoning wasn't "I want EUs to be exactly like electricity.", it was "EUs are behaving in confusing and unbalanced ways; let's compare them with real electricity and see if the comparison can show me where the problem is."

Real electricity is confusing for most people, too, because we don't work with it constantly. But it's self-consistent: when you do understand the rules, it makes sense. EUs could stand to borrow a bit of that. Bonus points if we drop in the real-world terms as extra labels (something like "Power: 128 EU/tick, Voltage: 32 EU/packet, Current: 4 packets/tick" for the EU meter), so that getting familiar with EUs primes you to understand real electricity.

The difficulty of the energy net: I probably know more about the energy net than most people in this thread, because I've decompiled it and skimmed it enough to get a vague idea of how it works. The decompiled code is... messy and ugly. But at least half of that is because it *is* decompiled code. It lost naming and comments that could have made it sensible. At the same time, it's also possible that the original code is also messy and ugly. No disrespect to Player, of course; all programmers write messy code sometimes, especially when they're tackling a hard problem and just trying to get something working.

Thing is, taking messy code and cleaning it is fun for me. I love taking something that's broken, inefficient, and/or ugly and streamlining it into solid, fast, and clean code. I don't care if I have to redesign the entire algorithm from the bottom up. If that's what it takes, I'll do it. The energy net is an algorithm (well, an implementation of one, to be specific), nothing more. I would rather work with the ugliest algorithm in the world than write a GUI. Algorithms are interesting complexity, GUI work is just repetition and minutiae.

So if nobody else wants to implement it, I'm willing. I'll do it without the original source if I have to, though that would make my life much easier.

The correct topic: All of this, however, is completely beside the point. We're not here to discuss "possible", that's for the person implementing it to decide. They'll make adjustments to the idea if they need to. What we're here to discuss is "desirable": Is this a good change? Would it make IC2 more fun, less confusing, more balanced, or some combination of the three?

Specific criticisms:

Quote from Tankman101

Loosing EU when entering a cable? Chance of degredation of the insulation upon entering a oddball area of EU's. Just a cap in increments for the max EU/p per insulation level for me thank you. Too much micro-managing otherwise. If I got that wrong let me know. My brains not working very well atm...

As Fickle mentioned, this seems more complex than it is. What I've given is essentially implementation notes. For the end user, you'd see something more like this:

• Uninsulated copper cables can handle 16 EU/p fine, but are bad after that, and utterly useless above 32 EU/p.
• Insulated copper cables handle 32 EU/p well, can be safely-but-inefficiently overloaded to 36 EU/p by putting 40 EU/p in, but fall apart above 40 EU/p
• Using a downward transformer or four energy storage blocks, you can overload cable to 4x its usual capacity, but only another transformer can use all of it by itself.
• A tin cable can handle 10 small generators safely.

And that's an advanced user. A basic user would be fine with "Insulated copper cable holds low voltage safely, and don't put too many power sources on it or it'll melt." Which isn't that different from the current situation.

Quote from Tankman101

no on the side effects [of HV cable]

Basically, HV cables get special treatment so that they can mimic real-world HV lines. You want them either way up in the air or way underground, or they can kill you. The block breaking emulates arcing damaging nearby materials, and also creates the air-based insulation that an HV line needs. Ideally, I'd have their block destruction radius expand with the entity-damaging radius, but I think that would cause major efficiency issues as IC2 searched for nearby blocks. If it's just watching neighboring blocks, it can catch block updates to tell when a block is placed by it, so it won't need to search constantly.

Quote from FenixR

Because the system works, even if its a bit wonky it still works.

Yes, it does. But we can make it work better

Quote from Kyre

Changing to a system like this would likely ruin a lot of existing industrial setups.

The changes are set up so that they should be straightforward for most people. You might have to rewire your generators a bit to avoid overloading cable (and to make up for the nerf to tin cable distance), but beyond that, you don't normally have more than four packets on a cable in the first place unless you're transforming from HV to LV, and the new setup handles that gracefully. Your mass fabber will take less power if you've been feeding it 512 EU/p on multiple sides, but that's hardly a game-breaking issue. The only people who are going to be facing lots of melted wires are the ones who were (ab)using the lack of a packet limit. But that's a fundamental truth of any balance fix: it harms the people who were making use of the imbalance.

Quote from Tankman101

[Generator packets] would be fine for all generators EXCEPT Nuclear. The nuclear reactors fuel cell based system for outputing EU means that it would have to be the same. If a reactor outputs 1081 (example) EU then I beleave it should output 1081 EU not output, say, 800 EU and wait for the next tick that the storage hits 800.

The point of that change is to make each type of generator cater to its optimum output voltage. The full breakdown goes like this:

• Generates 0-5 EU/t: Optimum output voltage is 5 EU/p, so it stores energy just long enough to output 5 EU packets. (MicroV)
• Generates 6-32 EU/t: Outputs 32 EU packets. (LV)
• Generates 33-128 EU/t: Outputs 128 EU packets. (MV)
• Generates 129-512 EU/t: Outputs 512 EU packets. (HV)
• Generates >512 EU/t: Outputs one packet per tick, with as many EUs as it has. (EV)

If a generator has variable output, like a nuclear plant, it changes its behaviour based on its current EU/t production (provided it produces any at all). If your nuclear plant is running at 500 EU/t (and so outputting 512 EU packets a bit less than once per tick) and you boost it to 600 EU/t, it will output one large packet, with 600 EU plus whatever it had stored, then emit a 600 EU packet every tick.

Honestly, though, this is one area that I'm not entirely satisfied with. If I end up doing the energy net rewrite myself (which is seeming likely), I'll probably take a slightly different approach. Instead of a 2 EU/t generator on a 5 EU/p line outputting one packet every 2.5 ticks, I'll have it output 2/5ths of a packet every tick. That way, if you put 15 solar panels on the same tin cable, they'll output a constant 3x5 EU/p instead of stuttering and possibly overloading the cable. From the outside, this will make the change in generator behaviour completely transparent, except that a solar plant will continue to output beyond the point where its "single EU" packets should die, because they're actually fractional 5 EU packets.

I'm not entirely sure how to handle a machine receiving a fractional packet with 2.7 net EU. Maybe a biased random chance, so that it works out in the long run? It might just be better to force machines to understand floating-point EU input, perhaps with a fallback to the random conversion for addons' convenience. Dunno, have to think on that one.

I'm also not sure how to display this in the EU meter. Fractional packets would be really confusing to the end user, so it would need at the very least a terminology fix. That's an implementation detail, though. It doesn't matter to the discussion at hand, just trust me that the final form will be sensible.

Quote from Kyre

Or at the very least, that some enterprising modder writes an addon to do all this.

A modder turning a suggestion into an addon, you say? Nah, that never happens.

On a completely unrelated note, I should go request a copy of the energy net code.

(Notation: 4x32 EU/p is read as "4 packets per tick at 32 EU per packet")

• The cable losses are backwards, as better cables should handle the same EU/p better. Set the losses to 1 EU per 5 blocks for tin, 1/10 for copper, 1/20 for gold, and keep 1/40 for glass fiber.
• Maximum EU/p should become a soft cap and depend on insulation. For example, uninsulated copper can send 16 EU/p at normal loss, loses half of any voltage from 17 to 32 EU/p (i.e. a 16+4(=20) EU/p packet is immediately reduced to 16+2(=18) effective EU/p upon entering the cable.), and loses all voltage above 32 EU/p. Insulation doubles these numbers (allowing normal transmission at 32 EU/p), but breaks down above 40 EU/p, leading to an effective maximum of 36 EU/p (input at 40 EU/p) with insulation or 24 EU/p (input at 32+ EU/p) without.
• The cable itself should overheat and melt based on the number of packets per tick, not the EU/p. Let tin carry 10 packets/tick, but limit everything else to 4 packets/tick.
• Machinery should only consume as much EU/t as the highest EU/p they receive. So a 4x32 EU/p line can give 32 EU/t to up to four machines, but only 32 EU/t to each. Machinery should still explode if it receives too high an EU/p.
• Transformers will still take as many packets as they receive, but will only accept as much EU/t as their higher EU/p value. For example, an LV transformer will accept 128 EU/t (at up to 128 EU/p) and transmit either 1x128 EU/p or 4x32 EU/p. Further, they should store energy below their target voltage, so that they never output smaller EU/p. (An LV transformer could, however, take 64 EU/t and output two packets per tick at 32 EU/p.) Like machinery, transformers should still explode if they receive too high an EU/p.
• Generators should store power and output it at the next-highest EU/p threshold. Solar panels would output at 5 EU/p (once every five ticks), generators at 32 EU/p, and nuclear reactors at 32, 128, 512, or >512 EU/p, depending on their power. This is especially important for low-power generators, so that they don't lose all power after a short distance.
• HV cable will be handled specially. It loses 1 EU per 5 blocks, like tin cable, but can transmit unlimited EU/p at one packet per tick. Above 128 EU/p, it will destroy any blocks other than itself, construction foam (solidified or not), or HV transformers that are adjacent to it, triggering explosives and exploding machinery. Further, for every 256 EU/p, the loss rate is incremented (to 2 EU per 5 blocks, then 3 per 5, etc.) and the cable deals damage to living things one block further away. Each layer of insulation doubles the EU/p values, raising them to 1024 EU/p (for block destruction) and every 2048 EU/p (for extra EU loss and damage radius) with full insulation. Insulated HV cable cannot be painted (or the paint degrades when the cable starts destroying blocks, but the rewiring that would cause seems icky).
• When transforming up, HV transformers will accept all incoming EU/t and output a minimum of 512 EU/p. When transforming down, HV transformers accept up to 2048 EU/t (at any EU/p), producing up to four packets per tick at 512 EU/p.
• Detector and splitter cables should be considered to be fully-insulated HV cable, but will also not destroy adjacent redstone-conducting blocks (redstone dust, redstone torches, levers, repeaters, and so on).

All of the numbers here could be tweaked, but I think this is a decent starting set.

End results:

Ten solar panels can happily use a tin cable, bursting 10x5EU/p every 5 ticks. (Theoretically, you could get more on the same cable if you somehow staggered them, but if power ever stopped flowing for a moment, they would overload the cable as soon as it resumed.) A single LV transformer would turn this into 1x32EU/p every 3.2 ticks. Note that any other cable type will only take four solar panels safely.

For LV machinery cabling, copper cables can now go 9 blocks without loss, or you can upgrade to gold cables and go up to 19 blocks. And for the rich, diamond cables are still excellent.

An expensive machine, such as a mass fabber, sitting on a 4x32 EU/p grid will be limited to 32 EU/t. Simply transforming a higher current to LV is thus sufficient to limit the machine's input accordingly.

A single transformer is safe to use on its target cable, producing at most what the cable can handle. Trying to supercharge a cable by using multiple power sources will also work up to four packets per tick, but connecting multiple down-converting transformers or more than 4 energy storage blocks to a cable will cause it to fail.

The reduced loss rate on HV cable makes using it for long-distance power transfer more viable. Sending 2048 EU/t 100 blocks will now lose you just 20 EU/t, and you can't make the same transmission with a single line of copper cable. Gold or glass fiber cable would still work, at 4x512 EU/p, but gold and diamond are both expensive compared to iron, and would require a second line if you decided to double the transfer rate to 4096 EU/t later, while the HV cable would just work. (Of course, there's still the problem of exactly why you want to send 4096 EU/t a hundred blocks instead of just generating it at the other end, but that's out of scope for this suggestion.)

Note: Most of this was written as I tackled the problem and tried to figure out what change to suggest. I've left it to show my work, so that you can see why I'm making these particular suggestions. If you're just interested in the suggestions themselves, scroll down to the second post, "Pulling it all together".

----

So a few days ago, another one of these showed up. A post from someone who's confused by a cable carrying more than it "should" be able to. The fact that so many people get confused by it is a pretty clear indicator that the current situation is confusing and needs to be fixed. There are also some balance issues, what with being able to send an effectively-infinite amount of electricity down any cable but tin (and only omitting that one because there's no 5 EU/p transformer).

Problem 1: My copper cable is sending 512 EU/t without melting. Let's say you have a mass fabricator sitting around that is happily consuming all of the 512 EU/t you produce. Nice situation, as you're gaining matter quickly. Except for the small problem that the rest of your machinery is starving. There's a nice easy solution: feed the mass fabber 32 EU/t instead. So you drop in an MV transformer and an LV transformer and... it's still eating all of your electricity. The problem here is that transformers appear to change EU/t, but they don't. They only change EU/p, the number of EUs in each packet. The same problem affects cable: EU/t is obvious, but doesn't affect the cable. EU/p is what actually counts, but isn't shown anywhere. In short, things don't do what it seems like they should.

Problem 2: All cables are superconductors. Say you have five full MFSUs with their outputs pointing at the same block. Meanwhile, a hundred blocks away, you have five empty MFSUs. And, because you spent most of it building them, you only have one diamond left. Getting the EUs transferred is going to be a pain. Either you make one lapotron crystal and spend ages shuffling back and forth, or you lose a bunch to cable loss. Right? Wrong. Use your one diamond to make a single batch of glass fiber cable. That's enough. Actually, you only need one piece. Use it to connect all five source MFSUs to a single MV transformer. Connect that directly to an LV transformer. Add four pieces of copper cable, and then another LV transformer. Continue that pattern: four copper cable, one LV transformer. And at the other end, just wire the copper cable directly to the empty MFSUs. All told, it should look something like this: [...] Hayo, a zero-loss cable that will happily send 2,560 EU/t.

Both of these are symptoms of an underlying problem: the system was designed for EU/t, and converted to EU/p without enough redesign. If each cable could only take one packet per tick, we'd still have the lossless cabling (that one's unavoidable without fractional EUs), but your copper cable would actually be limited to 32 EU/t, instead of having no EU/t limit.

So, since the problem is a lack of redesign, let's do that. And since EUs are based on electricity, let's use that as a measuring stick. Here's how everything matches up:

• EUs are energy, represented by kilowatt-hours or joules (also known as watt-seconds).
• EU/t is power, represented by watts.
• EU/p is voltage, represented by volts (appropriately enough).
• The ratio of EU/t to EU/p, power to voltage, is current, represented by amperes. (With constant EU/p for every packet, this is the number of packets per tick.)
• The quality of a cable (max EU/p) is its conductivity, represented by siemens per meter.
• The amount of EU lost by a cable (EU/b) is a result of its resistivity, represented by ohm-meters. (Ohm is the inverse of siemens, so this is the inverse of conductivity).

Now, if you're anything like me, the real-world units for all for these things have probably flown in one ear and out the other quite a lot. Volts are how "strong" electricity is, watts are how fast you use it, and kilowatt-hours are what you pay for. Amperes and ohms, let alone siemens (yes, that's the plural form, too), are terms that electrical engineers throw around to confuse you. So let's just keep using the IC2 terms, so that we don't confuse ourselves.

So, by current IC2 rules, voltage (EU/p) is limited by conductivity (cable quality), but current (packets/tick) isn't limited by anything, so power (EU/t) is unlimited for any cable. Which leads to the current situation where copper and glass fiber cables dominate, with occasional tin cables for tiny-voltage applications like solar farms: Why make HV transformers and cable when four packets on glass fiber gets the same power with a tenth of the cable loss?

In the real world, there are lots of types of cable that all see practical use. Almost none of them are superconductors. How does that balance work?

Most real-world cables are copper. The wire connecting your headphones to your computer? Copper. The one connecting your computer to the wall? Copper. The wiring of your house? Copper. Your local power lines, the subtransmission lines, and the high-voltage transmission lines? Copper, copper, and copper. Pure copper is just too good a cable material for there to be much serious competition. It's highly conductive, reasonably-priced, tolerates a wide range of temperatures, and is flexible enough to make cables that are very tolerant of stretching and bending. There are materials that beat it in each category, but for all four at once, it's the reigning champion.

In the real world, it's not the cable material that separates cables, it's insulation and wire thickness. Different types of insulation have different advantages: price, flexibility, temperature tolerance, water resistance, longevity, breakdown point, and so on. All of which involve meticulous detail and entirely too much complexity for IC2. A couple of types of insulation with different advantages might be nice, but it's not really an essential part of the cable's quality.

What is essential, however, is the thickness of the copper wire, because that directly influences the quality of the cable. Thicker copper means more expensive cable, but also more conductance and less resistance. In other words, a thicker copper cable in the real world is analogous to a better cable material in IC2. Which points out a major flaw in the current system: With the exception of glass fiber cable, a better cable material means more conductivity (higher max EU/p), but also higher resistivity (more EU/b lost)! Conductivity and resistivity are supposed to be inverses; higher max EU/p should mean less EU/b lost. Even without packet overloading, you'd rather use copper cable than gold, because gold is only better if you're sending at least 64 EU/t, and you often need less than that. In the real world, the only reasons to choose a thinner cable are size, weight, and cost. Of those, only cost is relevant to IC2. So tin cable should lose the most EU/b, followed by copper, gold, and glass fiber. We'll come back to HV cable later, because it deserves special treatment.

So, why do we use particular voltages in reality? Higher voltage means lower current for the same power, and current is what causes energy to be lost in transmission. (In IC2 terms, more EU/p means fewer packets for the same EU/t, and EU lost depends on the number of packets.) Higher voltage also means that more insulation is required to prevent the electricity from arcing and being lost to the environment. This insulation isn't practical inside a machine, so machines fail if the voltage is too high. Low voltage, in contrast, means less insulation, but higher current, and if the current gets too high, the cable will fail. (That is, packet count is what melts real cables, not EU/p.)

Sorry to hear about the hard drive. The good news, however, is that even a total loss is perfectly recoverable, as far as the most recent version of Rocket Science is concerned. The overall state of Minecraft modding means that lots of us are used to working with decompiled obfuscated Java. Repairing and reformatting ordinary decompiled Java is a breeze by comparison. If you don't feel up to it or just want a helping hand, drop me a PM.

Funny that you should ask that today. I was looking at Forge's update progress for 1.2.5 earlier and discovered that Forge is dropping support for MLMP in favor of a replacement called FML (No, really, that's the acronym. Forge ModLoader, or something like that.) that will be integrated into Forge. It looks like a really slick interface, but it's also significantly different from MLMP. So, if I may borrow the mantle of a diviner, I predict that the 1.2.5 version of IC2 (and a lot of other Forge/MLMP mods) will be delayed a bit as they figure out how to convert. That said, once the 1.2.5 IC2 is out, I'll definitely look into updating all of my addons to support multiplayer.

Okay, this one is directly out of the CropCard API, so I'm just going to quote the code for both of you, description included:

/**
         * Default is true if the entity is an EntityLiving in jumping or sprinting state.
         *
         * @param entity entity colliding
         * @return Whether trampling calculation should happen, return false if the plant is no longer valid.
         */
        public boolean onEntityCollision(TECrop crop, Entity entity)
        {
                if (entity instanceof EntityLiving)
                {
                        return ((EntityLiving)entity).isAirBorne || ((EntityLiving)entity).isSprinting();
                }
                return false;
        }

The intent here is PERFECTLY. CRYSTAL. CLEAR. The method description even says exactly what the result should be: The crop can be trampled if the entity is jumping or sprinting. Standing still fits neither of those requirements. As I said, the issue is that it uses a property which IS BROKEN. Replace it with an equivalent check that actually works, and the intent is restored.

If I reference specific code, please grant me enough respect to at least LOOK at the code I'm referring to before deciding that I'm full of it. This is not an "I disagree with the way things work." bug report. This is a specific flaw in the code which produces behaviour that was clearly unintended and which causes problems. Namely, it's nearly impossible to breed crops decently in the current IC2, because even carefully sneaking across the field will randomly destroy your crops.

It's annoying to have an uninformed user spouting baseless speculation, but he has the excuse of not knowing any better. I find it insulting to get the same treatment from someone who actually has the access and the knowledge to read the code I reference for themselves.

You've basically answered and explained the answer to your own question. Actually, if you look back, you'll see that I already skipped 1.2.3 once because it would have been a pain. It hasn't gotten easier since.

In 1.90, standing motionless on top of a crop block will periodically cause the crop under you to be trampled. This is caused by cropCard.onEntityCollision using a variable which MCP has mislabeled as "entityLiving.isAirBorne", but would be better named "entityLiving.hasEverBeenAirBorne" or even "entityLiving.thisIsCompletelyUseless". Minecraft itself never uses the property, and the only time it's set to false is when it's created.

To actually detect whether an entity is airborne, you can use (entity.motionY != 0). However, since jumping on tilled soil already causes it to revert to dirt, and since the tilled soil becoming dirt will destroy the crop block, the check isn't really necessary at all.

Quote from Silver Phoenix

i would just like to say i enjoyed reading the intro, good job

Thanks. I had fun writing it.

Quote from Withmyself64

This is very good! I think that it should be added to vanilla IC2.

It actually started out as a suggestion for vanilla IC2, so including it in IC2 would make my day.

Quote from Withmyself64

Does anyone think that this add-on is unbalanced? Especially once the auto hydration/fertalization/weed killer machine comes out.

I'm honestly not sure how the Seed Analyzer and Seed Library could be considered unbalanced. The analyzer uses half as much power as a cropnalyzer, but that's assuming you don't overclock it, and I always do. Without overclocking, it's painfully slow, which seems to be quite sufficient for balance. And the library doesn't have terribly much practical impact at all; it just keeps your seeds organized so you can find the ones you want without shuffling through chests.

The only thing that seems like it could have balance implications is the ability to sort seeds for buildcraft, and the machine you mention (which isn't one I'll be making) doesn't touch on that. What you'd actually need is a few things I have considered: a planter, a picker, and a crossbreeder. I just haven't figured out how to do that yet. I don't want to take the Forestry route of auto-harvesting each block when it finishes growing, because that seems a bit too automatic for balance. At least not with a single machine. Hmm. I'll have to give it some thought.

The current IC2 version is 1.90, for Minecraft 1.2.4, available over here. The current SeedManager, v1.2, works with this version.

1.81 was for Minecraft 1.2.3, and there is no matching SeedManager version.

The previous SeedManager version, 1.1, was built against IC2 v1.71, for Minecraft 1.1.

Okay, wasn't expecting this update to be as ugly as it turned out to be. Apparently MCP decided to sweep a bit of ugliness under the carpet, and in the process, broke the way I'd been getting a deobfuscated IC2 jar. Took me a while to figure out how to get it again. On the upside, I fixed some of my workflow in the process, so it's no longer anywhere near as messy for me.

Since we're now on a version that in theory supports block IDs up to 4095, I tried boosting the default ID into that range, but discovered that ModLoader had a heart attack when I tried it. It could be that there's some missing support in Minecraft itself making ModLoader die, but I think it's more likely that ModLoader still assumes 256 block IDs somewhere.

The really good news is that I'm not expecting the 1.2.5 update to be anywhere near as painful, because I already figured out how to handle any more meddling that MCP might do.

-FM

The reason a lot of stuff isn't on 1.2.4 yet is that while ModLoader, MLMP, and MCP are all updated, Forge is not yet. I think this commit might be them internally updating to 1.2.4, but there's no official release of that yet. I'll continue to keep an eye on it. If it looks like things are getting delayed somewhere, I'll bite the bullet and make the update. And, thanks to Murphy's Law, grit my teeth in frustration as a new IC2 comes out the next day.

-FM