Thermal Expansion Status

Status
Not open for further replies.

King Lemming

New Member
Jul 29, 2019
664
0
0
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.
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 it's a server drain - absolutely everything contributes to that - the question is should I be using 2-5x the CPU cycles I need to in order to set or check a value? In pretty much any industry, even a 100% increase in efficiency is remarkable, and we're talking about at least that much here. Absolutely everything counts, due to how MC is set up - that needs to be factored into the design at a basic level.

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.
I don't specifically remember that ever occurring with my power provider, especially since we redid all of the BuildCraft machines to behave in exactly the same way as TE machines. However, I can conceptualize why it would have happened - engines completely unused to the idea of something not actively requesting power. At the outset, yes - there's definitely an incompatibility there.

Ultimately, you've hit on the major issue here - you want BC energy to work a certain way. Regardless of whatever issues I may have with the efficiency of the code itself, the fundamental design principles are different. I'm not crazy about having my machines leak. I'm not really crazy about lossless transmission, but I definitely understand why you have that with pipes now.

So at this point, I'm inclined to make the jump, if only because I want to respect the design decisions.
 

l3lackCalamity

New Member
Jul 29, 2019
48
0
0
I have lurked these forums for quite some time but this is the first time I've ever felt the need to respond.

Buildcraft, Railcraft, Forestry and Thermal Expansion are by far my favorite and in my opinion best developed minecraft mods. By sharing the same power network they together provide a sense of unity and wholeness. Personally that is there greatest appeal, pieces of a giant and beautiful minecraft puzzle. Please strongly consider staying with MJ. Otherwise Thermal Expansion becomes less of an expansion, and heads towards the grounds of an IndustrialCraft alternative without addons.
 

King Lemming

New Member
Jul 29, 2019
664
0
0
IndustrialCraft alternative without addons.
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.
 

SuperLuigi10

New Member
Jul 29, 2019
32
0
0
Thermal Expansion and Buildcraft in my opinion go hand-in-hand. I love every aspect of Thermal Expansion, and I like using Buildcraft's MJ due to the fact that multiple mods add engines that create it. In my opinion, the Buildcraft team should work very closely with Lemming. Lemming really knows his stuff and I think that if the two mods combined forces, the results could be phenomenal. With Lemming's new time conflicts to work on modding, having a team he can work with could really help take some pressure off of him. I feel that Buildcraft 100% needs the machines added by TE.

The FTB community is strong and I hope that the two mods will collaborate and put out a great experience for all of us.
 

ele360

New Member
Jul 29, 2019
17
0
0
I honestly do not mind having different types of energy in the game so long as I produce the energy in a unique way. I don't want to have to split the resource I use for MJ or EU just to run an engine for TE. I would rather their be a unique and interesting way of going about gathering my fuel resource so that there is actually an incentive to create a separate infrastructure for said power. A room full of TE engines running on charcoal wouldn't be very interesting imo.
 

LordBlackHole

New Member
Jul 29, 2019
10
0
0
Just like l3lackCalamity, I've lurked here, but never signed up before now.

As a modder myself, I know the feelings going on here. To be a programmer, you MUST care about the tiny details, you have to want the best and you must be a control freak, it's a requirement, since the code isn't very forgiving.

Covert, I see what you mean. You want to make it easier for other people by handling all the hard stuff yourself, believe me, I've been there. But, ...... maybe the reason people were misusing the API before wasn't because it was too open, but because it was too confusing?

I've been looking at the code King has for his energy API. It sure does look a lot like the Fluid Registry, and that's a good thing, because the Fluid Registry is awesome. What struck me was how simple it was. And really, it's all that it needs to be. It defines the relationships between any two energy-entities, and nothing more. One thing I've noticed about IC2, MJ, and UE is that they have different interfaces for power producers, receivers, and cables. The IEnergyHandler can do any of those things. It's up to the blocks that use it to figure out how to do whatever it is they want to do. Those functions defined by it are all super simple and intuitive. Using that same interface, a block could be a generator, a battery, or a machine, or any combination of them, without any fancy fussing about. All the work would be handled by his energy net system, which would't be a part of the API at all. And there is the true beauty of it. Let's say King does create his own power system, and let's say for whatever reason I don't like it. Maybe I don't like his power loss system, or I have an issue with the efficiency of it, it doesn't matter. I could create my own system, with my own generators, cables, storage systems, and machines, but I use that same API. That API only defines how these blocks can put power into one another, it doesn't have any limit or control over how energy actually travels around to them. I could have my own entire system, which to a user would seem totally different, but it would fully compatible with King's devices. His generators could power my cables, and our machines would work together. Even our storage devices would work together seamlessly. It doesn't matter how my cables decide where to send energy, what matters is that at every interface between my cables and anything else there would always be one simple way of passing that energy into or out of the network. THAT is the key element that all these other systems have been missing. They always try to have direct control over the way in which power moves, but it doesn't matter. Once my new mod was out, users would be able to decide for themselves whether they wanted to use mine or his. Maybe I didn't do a good job with the power transmission, but my machines were great, or I had innovative generators, people could mix and match our two systems together without any issues.

Wow, that's a rant right there. Sorry.

..... And another thing!

King is also using the idea from the Fluid Registry of having basic implementations of the interfaces, like EnergyStorage, which reminds me a lot of the FluidTank class. With a system like that, you give modders different choices.

1. A modder could ignore that class and create his own from the interface directly for maximum control.
2. He could extend that class and add more functionality to it. (That's what I did with the FluidTank, my AdvFluidTank can handle filters to define what types of fluids are allowed in the tank, whether it could output or intput, what sides of a block it could use ect.)
3. He could just use that class right there for a simple implementation with minimal effort or understanding of how it works.

And THAT is also beautiful. By giving other modders a choice based on how much work they want to do or how much skill they have. Someone new could use the pre-made class without having to to much work, but someone with more experience could create their own complex version of it. It provides freedom, and only controls what matters most.

Ok. Now I think I'm done.
 

Vaygrim

New Member
Jul 29, 2019
533
0
0
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.
Tend to only make an MJ power grid, almost entirely because of the Thermal Expansion machines. Combine this with the fact that IC2 hasn't been real relevant (to me anyway) in a LONG time (hooray for it getting updates now!) and the only thing I usually end up making an EU power grid for is to power my Applied Energistics network. I use MJ for Forestry machines, Thermal Expansion machines, sometimes Applied Energistics.. and now Ender IO and Engineer's Toolbox machines. What machines to I use from BuildCraft specifically?

The Quarry and... uhm.. yeah, the Quarry. That's it. Every once and a great while I'll make an Assembly Table system from BuildCraft but now that those have constant power draw, I'll never make those again. Gates are nice but I can do without them just fine myself. I honestly think that the future of modpacks will be mods like Power Boxes, Universal Wire and the like: mods that specifically can carry and convert any and all power systems, cross-converting the power as needed. This means you'd pretty much never have to worry about power systems again.
 

Malexion

New Member
Jul 29, 2019
263
0
0
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.
 
  • Like
Reactions: Vaygrim

Vaygrim

New Member
Jul 29, 2019
533
0
0
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.

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.
 

Zenthon_127

New Member
Jul 29, 2019
837
0
0
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?
 

LordBlackHole

New Member
Jul 29, 2019
10
0
0
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.
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.

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?

Yes. Yes it is really hard, at least the way it is now. With MJ and EU at least, the Machine's code is tied to the power system, you can't change the system too much without breaking every single machine. I'm working on my own machine mod, and to add the best compatibility, I had to implement the MJ and EU systems separately, and it was a major pain. Changing these things now would be a major undertaking for any modder who uses them. Not that I'm against the idea, but it would be a tremendous amount of work.
 

CovertJaguar

New Member
Jul 29, 2019
159
0
0
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?

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.
 
  • Like
Reactions: netchip

Zenthon_127

New Member
Jul 29, 2019
837
0
0
Alright, just checking to see if I got the main stuff from your post, since I'm terrible with lots of semi-technical stuff:

-The MJ API expects/expected all machines and wires to work a certain way, but people were able to bypass that to some extent using hacks (an overused word IMO, but whatever), causing bugs
-To solve this the API was restricted in some areas to be more consistent
-While there's an arguably more effective option, it's much more complex and would be a very painful update for everyone
-Basically everything you could do before is still possible with the updated API, but from what I understand somewhat more laggy is some cases (could be wrong here)

Now that that's out of the way: what exactly is this difference in direction between CJ/Sengir(?) and KL I keep hearing about?
 

l3lackCalamity

New Member
Jul 29, 2019
48
0
0
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.

Yes of course there is far greater value in both TE and IC2 then their abilities to smelt and crush. That being said, please don't take offense when I say they're some of modded Minecraft's more compelling features, and therefore compete. From a players point of view it is more efficient to build one system then multiple whose basic machines share similar functions. The same types of comparisons can be made between certain areas of TE and BuildCraft. Liquid ducts vs waterproof pipes, energy conduits vs conductive pipes. However because of there shared power network they haven't just competed but actually supported one another while providing players with options. Establishing an independent power network removes the harmony leaving only the competition.


IndustrialCrafts EU
Buildcraft, Railcraft, and Forestry's MJ
Redpowers Blutricity
Universal Electricities UE
Xycrafts upcoming power network
Factorzations network

I realize everyone modding wants things there own way and I'm in no position to tell them otherwise. You all mod just for fun and I respect that. However from a players perspective maintaining this many networks just ISN'T fun. Other then the forgecraft videos I've watched, I have never seen it done.
 

l3lackCalamity

New Member
Jul 29, 2019
48
0
0
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.



I can't help but feel like there's a lot of negative tension between Minecraft developers, in this case, specifically around buildcraft. I can see based on that reason alone why some individuals would prefer to head off, and do things on there own. As a player its unfortunate but as a human I understand. I have the utmost respect for all the devs work, but as a body I feel as though everyone needs to work on considerate communication.
 
  • Like
Reactions: Flipz

OmegaPython

New Member
Jul 29, 2019
800
0
0
I think that Covert should calm down over this ordeal; if Lemming wants to use his own power system, then that's fine by me, and it seems like just about everyone else thinks the same way. BC, IC2, UE, Factorization and TE's new system are all reasonably different, and each provides its own challenges, and an understanding of how the system works.
In my opinion, the changes to the BC power system have made it seem like, even before this thread, that TE would need to heavily change its power system, or create a completely new one. A universal power system isn't necessary, and, as shown by UE, will never really work.
So, basically, just settle down over this whole thing, and, as I3BLackClamity has said, there is too much negative tension, and this argument his highly unnecessary.
 
  • Like
Reactions: RedBoss

Skullywag

New Member
Jul 29, 2019
217
0
0
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.
I was thinking the same thing, im not a Java Dev but I am a Dev none the less so some terminology makes sense to me. Now this is just me doing my "why cant we just get along" post and im deliberately leaving out "modders choice" here, but:

If there were a unit of something in Vanilla minecraft that equated to 1 of "insert power unit name here" couldnt forge have that defined (im being a little deceiving here as i think i read its based on 1600 coal or something so i know this is done already) and have a hook that mod devs could call to register things like the power units name for their implementation (not needed IMO, its just numbers after all) they are then free to handle how this energy flows though their pipes/blocks and other details themselves in their mod. Forge would define how to pass the power from block to block so everyones pipes/blocks are interchangeable. This doesnt effect the individual mod/modder and everyone would be happy (I think). Im not sure but this does sound a bit like the liquid registry and ive seen it mentioned here and the liquid registry is one brilliant little thing used by lots of mods and no one moans about liquids (they probably do...)

Now theres probably (read: definitely) a load of stuff im not taking into account and dont know. But as other people seem to be thinking along the same lines its obviously a wanted feature (at least by the non modding playing community). I for one would love to produce my power unit anyway i see fit and then use any pipe/cable/block from any mod to feed it to any machine that needed it (from another mod if need be) it gives me the player/modder choice (and we MC'ers love choice!)

Id love to hear some thoughts from some MC devs on why this would or wouldnt work or even better, other better ways of achieving it as again IMO this is something that should be defined by forge (for forge based mods) and not in mods themselves, weve moved on a bit since it was just BC vs IC2. I mean who doesnt want to create a shed tonne of UU using engines running off a peat farm or some such.

If the big players were to get together and agree how the forge part would work the smaller mods would follow and wed all have a perfect harmonious power system.

I know if this were to be done it would mean more time spent updating mods to the next version and Id love to say people wouldnt mind (but they would) and I am in no way stating this is how it SHOULD be done I just dont know enough to say why this shouldnt be the way it is done.

Anyway ill shut up now.
 

CovertJaguar

New Member
Jul 29, 2019
159
0
0
Forgive me for being annoyed that everyone seems to be ranting on something that I've put a fair bit of thought into (and worked on in collaboration with a fair number of invested developers). The intent has always been improving the entire eco-system of mods surrounding Buildcraft. =P

I really shouldn't let it get to me, but I'm not so good at filtering such stuff out. =(
 
Status
Not open for further replies.