And people wonder why other people create new power systems, instead of relying on one someone else created.
Seriously, premature optimization is considered BAD practice in programming. Validity, consistency, and maintainability are far more important concerns that shaving off a few extra cpu cycles. You'll have to show me some profiling evidence that these maintenance functions are a significant drain on a server's resources before arguing that they are bad.
The maintenance functions ensure that the PowerHandler behaves as expected under any circumstance, even if the user has no idea what he is doing (more common than you think). Specifically, KL even you implemented IPowerProvider wrong before. BC Engines would explode when connected to your machines. This was a common problem with your (and others) implementations.
We tried trusting people to implement it correctly, it doesn't work. Even Sengir got it wrong more often than not, Forestry machine were notorious for being massive black holes of power. So we standardized it and locked it down. The is no way to standardize it so long as you provide people the ability to create their own implementation, which has been shown be far more common than using the reference implementation.
IndustrialCraft alternative without addons.
LOL the BC universe is going to take a rather large hit if TE goes away from MJs becasue other then the quarry I can't for the life of me think of what I would use to consume MJs.
All my MJ consumers are TE machines, or Minefactory but MFR can run on other types of power.
I know it'd be extremely hard to do, but I think forge should add some sort of universal power API, similar to what happened with liquids. Honestly if you think about it, IC2 ends up being an odd guy out in terms of most power systems in 1.5.2 modding.
That's actually an interesting proposal since many mods are forge dependent already. The question lies in the implementation and who will agree to it.
Well, for one, mods don't like being dependent on one another. For another, well, as Covert and King have just shown, people have different ideas about how to do things. If you'll read at least some of my post above, I think that what King wrote might be an excellent step to a Forge power API, since it would allow different modders to make their own cables and power systems that would all still be compatible. And if it was in Forge itself, people wouldn't have to worry about adding another dependency. If we start now, it might be ready to fully implement by MC 1.8. ....... lol.I am not a programmer so make sure you understand exactly what place of ignorance this comment is coming from: I honestly do not understand why every 'machine mod' feels the need to have its own power system.
This was one of the primary reasons why I always liked the BuildCraft MJ system; it supports and powers my Quarry, my Forestry farms, my Applied Energistics network, and my Thermal Expansion machines. I get SO MUCH usability out of one single power system. Now that Buildcraft has updated their power API, there are several existing mods (not just Thermal Expansion) that are discussing dropping MJ's in favor of their own power system... which just makes me wince in pain.
Honestly.. why can't we just have a Forge-centric 'Universal Power API'? I really do think that it would do wonders for gameplay over all.
We nearly had a centric power API in 1.5 with MJ. Look what happened.
Excuse me if this comes off as ignorant, but: is it SO HARD to just change how the machines and wires work instead of changing the entire power system itself? If everything ran on MJ and/or Steam but the methods of transporting and using the power were different we wouldn't have so many issues, which is what happened to some extent in 1.5. Why are we moving away from this brilliance?
We nearly had a centric power API in 1.5 with MJ. Look what happened.
Excuse me if this comes off as ignorant, but: is it SO HARD to just change how the machines and wires work instead of changing the entire power system itself? If everything ran on MJ and/or Steam but the methods of transporting and using the power were different we wouldn't have so many issues, which is what happened to some extent in 1.5. Why are we moving away from this brilliance?
Alright, just checking to see if I got the main stuff from your post, since I'm terrible with lots of semi-technical stuff:-snip-
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 reasons.
As far as the rest of your post goes, I agree, except that the direction that BC power is taken in - and there is a definite direction - means that there are very intentional design decisions being made and I don't want to rock that boat. It's a matter of respect for the system as a whole. BC is moving away from being only an API, which is a good thing.
Look at it this way, to update Railcraft and Buildcraft to the new power API changes, all I had to do was rename a few things and tweak a couple methods and remove some unneeded code. It was a simple painless update. Forestry was the same, despite some issues caused by increasing the perdition that were not really related to the API changes. The core of the API is nearly identical to the old one, assuming it was used by the mod in the same way BC used it. Its not a complete rewrite, its a mainly just a refactor of the existing API with some minor improvements and forced standardization thrown in. By comparison, KL's own rewrite of the Liquid API was by far more painful.
The original API was NOT designed to be used as a wrapper for custom per mod power systems. It operated under the assumption that only one PowerFramework existed at a time, and that that power framework would provide the PowerProvider implementation. Mods subverted this by ignoring the PowerFramework and hacking in their own PowerProviders regardless of the global PowerFramework setting. That is what it was, a hack. And it caused more issues than good. And god forbid anyone tried actually swapping the PowerFramework as the system was designed. All hell broke loose if you tried that. So PowerFrameworks were removed and along with the ability to hack in your own implementation.
If we really wanted to we could have rewritten the API to support per mod PowerProvider implementation (though the benefit of that is up to debate). But in order to achieve our goal of simplification and standardization, it would have required a ground up rewrite of the API, pipes, and engines. A rewrite that would have made the update exceptionally painful for everyone. It would even have had visible in-game effect on how users used the system because many interactions would have had to have been completely rethought. We chose the less intrusive option of simply modernizing and standardizing the existing API.
Anything you could do before, you can still do now. Look at all the mods that are using the new system. There is no reason to drop features, and in fact the argument with TE isn't even about whether its possible to use the API, but rather about whether KL wants to use it. I'm sure if KL wanted to, the update to the API would be no more painful for him, than it was for any of the other mods. In my opinion its his loss if he does not use it, but its his choice. I just wanted to understand why.
No one has yet come directly to me and shown me a game feature that is impossible with the new API that I haven't been able to accommodate with minor changes. No one. In fact, the new API has enabled several new features that weren't possible before.
Its still the closest thing to a universal power api that MC will probably ever get.
That's actually an interesting proposal since many mods are forge dependent already. The question lies in the implementation and who will agree to it.