[Suggestion] Rethinking EUs, EU/t, EU/p, and cable quality

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.

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.

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.

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.

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.