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

  • You mean: have at least a technical level of education with either the electrical industry or a college level understanding of electro-statics from Physics? If you didn't get that from the OP as he was describing Ohm's Law and the nature of conductance, then I highly doubt you have the education yourself to call him a 'moron' in this matter. The science in the matter is very solid. Your logic in the issue, however, is not...

    Just saying, but that's irrelevant to IC2 EU's.


    EU's != Electricity

    ...What? There's no pineapples here.


    GENERATION Pineapple: The first pineapple you see, copy it into your sig on any forum and add sqrt(-1) to the generation. Pineapple experiment.

  • Nope i meant knowledge of the internal workings of the Enet and more importantly, WHY its working like that. Its may be beyond the scope of a simple bugfix, it may be working that way because of a specific reason.


    Great ideas codewise can be cropped off or made more simple for the sake of efficiency


    Quote

    *cuts corner off Man card*...

    Sorry, i guess you mistook my man card with my machoman card.

  • Quote

    Nope i meant knowledge of the internal workings of the Enet and more importantly, WHY its working like that. Its may be beyond the scope of a simple bugfix, it may be working that way because of a specific reason.

    Then enlighten us on that reason then.. or would that violate your Gnostic wisdom that you like to hold over everyone that you do?

    Quote

    Sorry, i guess you mistook my man card with my machoman card.

    You are no where near that if you have to get a kick out of mentally being down others for a hobby...

    Would anyone like to try a Slowpoke Tail?! Only 1 Million Yen!


    Quote

    this isn't about arrogance or ego, I have a block that I put a lot of freaking work into


    Every Mod Author, in existence. And yet, you STILL say otherwise.

  • You are no where near that if you have to get a kick out of mentally being down others for a hobby...

    I meant that i have a REGULAR man (The one that doesn't bother touching his balls and watch sport religiously card instead of a Machoman card. Oh and i don't get a "Kick" out of it, i just do it when im absolutely bored without anything better to do, gotta keep myself entertained.


    Quote

    Then enlighten us on that reason then.. or would that violate your Gnostic wisdom that you like to hold over everyone that you do?


    I know everything you or funnyman does about the Enet workings and purpose, almost nothing.

  • lets see "realistic revamp of already implemented mechanics that are not broken" or "base-in-a-box"? hint: I pick base-in-a-box

    true balance is impossible in video games the best one can hope for is to make it really hard to guess which of 2 choices are better.
    and remember kids "NEVER UNDERESTIMATE THE POWER OF JOKES!"

  • Quote

    I meant that i have a REGULAR man (The one that doesn't bother touching his balls and watch sport religiously card instead of a Machoman card. Oh and i don't get a "Kick" out of it, i just do it when im absolutely bored without anything better to do, gotta keep myself entertained.


    Was this before or after you decided to change yor sig. for: So don't judge a fudging book by its cover alone?
    Sour about you having to make a biased assumption on me to attempt to prove me wrong in this case, cuz me caring about sports is like me caring about organized religion.



    And your high post count displays how 'bored' you actually get.. Pretty sure many other forum users can attest to that...

    Quote

    I know everything you or funnyman does about the Enet workings and purpose, almost nothing.

    a.k.a: "I'm not saying anything because I really don't know/ not sure"... ok, sure...


    These are the primary changes:

    • 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).


    That's 6 variables... 4 of which are already apart of the current system. The other two are based off of properties of the first few. Resistance = Voltage/Amps, and that helps determine current loss. Conductivity can be an independent variable as determined by the materials used in the recipes (Cu, Au, Fe, etc..). That would be, essentially, the MAJOR change to the system current in terms of calculation.

    Would anyone like to try a Slowpoke Tail?! Only 1 Million Yen!


    Quote

    this isn't about arrogance or ego, I have a block that I put a lot of freaking work into


    Every Mod Author, in existence. And yet, you STILL say otherwise.

  • 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:


    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.


    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.


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


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


    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.


    [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.

  • To clarify, obfuscate well. "In the T ticks between EUmeter uses, cable foo passed X EU in the form of Y total packets of Z Eu/p. This means it was averaging K packets per tick, or (25*K)% of its maximum rating." Any confusion caused by K being a non-integer value is handwaved away by that "averaging" claim, and the minutiae of your implementation needn't affect the display at all. Obviously, cut that back from natural language to a GUI presentation, but the point is basically that you shouldn't bother listing anything as EUmeter output that includes the assumption of a flat current. Don't report an endpoints mean as an instantaneous value, and don't bother going into the fact that the fractional values are occurring in transmission, rather than detection. If nothing breaks down because fractional packets won't play nice, it will be irrelevant.

  • Quote

    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."

    Well, the conversion isn't generically hard... The two formulas that I've posted sum up MOST if not all of the nature of current inductance. I actually do have quite a bit of electrical knowledge on this matter, so to compare again:


    Power (Watts, or EU) = Voltage (the size of the EU packet an energy source can generate) * Current (The actual amount of "electrons" traveling down the line)


    Resistance, which is the restriction of the ability of how electricity flows (or in the case of IC: what EU/p a cable can tolerate before frying into bits), can be measured as follows:
    Resistance = Voltage (again, size of EU packet) / Current ( actual 'electrons' being sent)


    Remember, Voltage =/= energy or EU! It merely shows the potential of energy that you can generate. In the case of a standard Generator, it generates 10 watt/seconds of energy max. That means that It has the potential of creating up to 10 Volts times a 1 Amp Current on a power line. In the case of IC, those 'electrons' are meta data values that decrease over time from a high meta-data value down to 1, and merely show the amount of 'charge' an item has in accordance to the off-set of scalar values used to simulate electricity. For simplistic terms, let's just assume that Current = 1 due to how Minecraft handles changes from one meta-data value to the next.


    So in essence, Voltage is the highest EU packet you can generate, Watts are just the EU in and of themselves, and Resistance determines the tolerance of how much actual Voltage a cable or machine can withstand. Conductance (which also needs a bit of a rework) is an individualistic property unique to elements on the Periodic table. This governs Watt/EU loss over a cable line via heat, and rubber helps insulate against the heat loss by keeping a high temp. gradient around the wire. That just means that heat flows from hot to cold, and the 'warmer' a cable is externally, the less chance that there is for energy to 'creep' out of the cable as electrons are moving down it. Technically, EU packets should stack as you are adding more Voltage and Current on the line, and affecting the total resistance of the wire, and the total tolerance and stress being placed upon it within that moment in time...

    Would anyone like to try a Slowpoke Tail?! Only 1 Million Yen!


    Quote

    this isn't about arrogance or ego, I have a block that I put a lot of freaking work into


    Every Mod Author, in existence. And yet, you STILL say otherwise.

  • 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

    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


    Both... See: Darcy's Law for a better diagram example...

    Quote

    And does that line up neatly with some property of electricity, or not?

    Yes. Attributes towards the diameter and surface area of the wire do play a role in how well electrons can flow thru it, as those are factored into Resistance in various respects. As long as we aren't complicating things with magnetic field presence, then electrons do act like water in that respect at least...

    Quote

    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.

    It's actually quite ironic that I have just finished both courses in Physics 2 (Electrostatics and Light Properties) and Hydrology recently, and the comparison between water flow and electron flow is fairly common. Course, it does serve as a bit of a wake-up call that I've taken for granted how smart I've been with both subjects within the past few days. Still, there is no reason to fault yourself for not being able to draw a solid comparison between the two, and many among the general population barely understand how either works on the complicated scale. All they really know is that life sucks ass when either two stops working for them, and they have no way to fix it. Likewise, it's actually fairly hard to teach things like electricity and magnetism without a proper visualization scale of reference.


    Which is really why I love IC so much: it helps show how electricity, in some regards, works as a whole. Sure, it's not perfect, but it works well enough to demonstrate the importance of a proper electrical infrastructure, and how it helps our society overall...

    Would anyone like to try a Slowpoke Tail?! Only 1 Million Yen!


    Quote

    this isn't about arrogance or ego, I have a block that I put a lot of freaking work into


    Every Mod Author, in existence. And yet, you STILL say otherwise.

  • I can't believe I read the whole thing.


    My take: Wow. This is an amazingly thorough, well thought out proposal for a completely new product. If the original IC2 power system had been implemented this way, that'd be awesome. But it wasn't... so, what to do?


    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.


    Yes, the system isn't realistic. Yes, it takes some learning. Yes, using an EU reader on the output of a water mill is humorous. But as far as the players are concerned, the learning curve is not terribly steep.


    I think the efficiency of cabling should be readdressed... and that's all I think we could possibly expect as part of the core module. And really, the only reason cabling efficiency is even an issue is the problem of long-distance transport of power - to which problem there are a variety of lossless options (though, admittedly, none are terribly elegant as the standard superconducting copper/transformer chain example illustrates). The ~20% loss observed when using copper to transmit LV for 20-30 meters only significantly impacts players at the early stages of the tech tree. An ULV transformer would be more than enough to solve that problem for them.


    The only realistic way to introduce the full scope of changes you are proposing is to write them from scratch. Be that in an alternate power grid mod or a fork of the project... that's what it would take - and that's bad juju there. Personally, I am willing to run rail between the nuke plant and the central distribution hub and let energy carts do the trick - it's a more fun solution than just knowing I can string a lot of high throughput cabling all over the place and forget about it.

  • 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.

  • 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:


    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.

  • OP: stop complaining, all those suggestion responses I did in 20 minutes weren't quickshot believe me or not.


    What I meant is that the energynet would need a complete if not partial rewrite to fit in the changes proposed.

  • 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.

  • Dude chill.


    On the bug report: I don't know really, I thought it was intended behavior, until Al corrected me. I bet it was originally supposed to only trample on walking until Notch changed wheat, because the whole agriculture system was designed back in 1.0.0. If it was really unintended behavior I missed, we all make mistakes, no need to hit me with a hammer.


    On the suggestion, first time I'm being criticized for stating the truth. The enet would need to be rewritten yes, and if you want to rewrite it with your changes, go ahead, we're pretty liberal about people decompiling our code.