Search results

The OmniWrench works fine with Greg's changes. At least, it still does in 1.5.2. It wasn't hard to circumvent that requirement. Yeah, I keep hearing the term "modder ego," and I"m thinking that's the crux of the problem - I don't have one. I get why people are proud of their code and their...

They are there yes, though I don't see why addEnergy needs a perdition calculation. I seem to remember it not having that initially. The problem is that it hinges on so many APIs. It's just somewhat annoying, but I'll see what can be done once the dust settles.

Yes, and that's actually an official stance. When BC adds storage, it'll be in the form of leaky capacitors (which do have their uses). The REC flipped the script somewhat. If I release a 1.6.x branch with Conduits and Fluiducts, that creates an awkward situation where I'm not allowed to...

I haven't decided to stick with it, I was only posting that it's technically possible. Internally, that saddles me with somewhat kludgey code for the actual machine operation. At one point during development, the PowerHandler had direct-access functions which were clearly marked "only use these...

Omicron is correct - it's 1000 MJ/t on any given connection. This may change in the future, but the idea is that there is (or was, at least) no legitimate block that actually produces or consumes 1000 MJ/t. The bandwidth of a conduit network is essentially limited to 1000 * N / 2, where N is the...

I'll clarify - if you enable all of the hard mode options, you can't even make TE stuff without another mod installed, because I don't add steel. In the case where you do have RC, that means getting to the nether at a minimum, which is a bit extreme.

Furnace. Pulverizer. Duplication ends there - this is an old and extremely tired argument. Also, energy costs were higher (by as much as 25%) relative to IC2. And, early on - the pulverizer didn't even duplicate - the Smelter was required for that! Tripling ore was never possible. Conduits and...

No - that thread was posted well before any changes were finalized. As I stated at the time, there were some features I was going to ask be put in the new PowerHandler, and they were added. Unfortunately, there's a bit of extra baggage that came with them. That aside, my big hangup here is that...

Hey, your new PowerHandler is absolutely a huge step up in a lot of ways, which I've said repeatedly. But, it's also a huge move away from an API into a plug-and-play system. And that's alright, it's just a bit like moving from a rooted Android to an iPhone. Yeah, maybe the old ways were...

Stop right there. Furnace. Pulverizer. That's it - similarities end there. If that's all you use either mod for, you're doing it way wrong. Sorry, small peeve of mine on that one. I can't fathom the amount of people that view IC2 as nothing but a macerator. It's a fantastic mod for lots of...

I completely agree with you - premature optimization is bad. However, you're only using the 2nd half of that famous quote: “We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil” It's not really a question here of whether or not...

I appreciate you putting that in, but realistically now that just means that everything in BuildCraft, RailCraft, Forestry, and most other BC-based mods has an extraneous call that they don't need which is going to happen hundreds or thousands of times every tick on a server. Making an all in...

Percentage based loss on reception would be nice, the PerditionCalculator class seems a bit strange to be honest, since it has to work on currently stored energy only. Honestly what I need is for PowerHandler to be extensible so I can alter some of the fundamental things for internal use -...

Incorrect. It's 1000.

The API used to be extensible - it was interface driven, so it allowed me to optimize out the parts that were less than efficient, and implement my own mechanics (% based loss on Tesseracts and the like). The 1.6 port will have new Tesseracts, which people are probably going to like, but as...

Everything is Forge-direction capable, yes. Same as the Fluid system. The only dependency will be on CoFHLib, which we might be able to make an auto-download, CCLib style. It would be a temporary loss, rest assured. However, FMP or not, some big rewrites are going to be required. If we do...

Yup. MJ is a good unit. I've never been crazy about the name, but I don't see any reason to change it up. The trick is just making sure everyone using the system understands the base values. Again, not completely convinced that it'll be changing. New engine is a fuel (and other stuff) burner...

32k is just an example. MJ is actually a really good unit of energy, since it is defined by Minecraft itself (1600 per coal), so I don't see any real reason to deviate from that. There's no need to subdivide the MJ - under this system, a machine can store and use energy in whatever amounts it...

Nothing is set in stone, although the system is done and would be trivially simple to implement (which is the point of the system, ease of use + efficiency). Might stick with MJ in the near term for transitional reasons, but it's hard to say. TE doesn't fit in with the new BC paradigm, which I...

Okay, been a while everyone, so I figure I'd drop a few words here on where CoFHCore and TE stand. OmniTools will not be ported to 1.6.x, but there's a reason for that. CoFHCore may be split into a couple of mods and repurposed, I haven't decided on that yet. All of the individual parts...