Thermal Expansion Status

[MigukNamja]

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 far as energy transfer, it'll be lossless and limitless, simply because of the constraints of the new system. Sorry.

Thanks as always, KL. If I want to better understand BC4 Energy/Power, is this the place to look ?

https://github.com/BuildCraft/BuildCraft/tree/master/common/buildcraft/api/power

If so, I think I can see what you mean. Amazing that one word - final - is so limiting and so frustrating:

public final class PowerHandler

I would prefer an API I could implement myself and override (choose to override) parts as I see fit.

My Java is a bit rusty and may be getting ahead of myself here, but if I'm reading that right, this effectively discourages extensibility, which ultimately encourages competing power systems.

 

[SandGrainOne]

.., but if I'm reading that right, this effectively discourages extensibility, which ultimately encourages competing power systems.

That was the point with the change I believe. To make BuildCrafts implementation of its own power system the rule for how the power is to be considered by other mods and players.

The way I understood it: The Thermal Expansion implementation of BuildCraft power along with many other were in a way different power systems already. They were just called the same. I guess the message from the BuildCraft authors was a little bit like this: "If you want to make your own power system, then do it properly instead of basing it loosely on BuildCraft power." (My words.)

 

[MigukNamja]

But, this create cross-mod power compatibility problems. If I code up an MJ engine and I want users to be able to power something from Buildcraft, Forestry, TE, and MFR, I may have to write separate code for each one of those and then make sure I track their changes to their APIs.

A single MJ power API is far more preferable and if my comprehension of the BC4 API is correct, the TE dev team has to make a tough call whether to go with BC4 MJ power as-is or else have a parallel power system, but then that would make it more difficult for other mods to work with TE and TE would have to keep up-to-date with those mods. BC3 seemed to be the defacto MJ power API, at least from my experience. I don't recall any MJ producer or consumer having cross-mod compatibility issues. It's sad to see BC4 effectively becoming more strict/restricted.

*goes off to look in Forge to see if someone has submitted or is working on a common power/energy API*

 

[INCSlayer]

But, this create cross-mod power compatibility problems. If I code up an MJ engine and I want users to be able to power something from Buildcraft, Forestry, TE, and MFR, I may have to write separate code for each one of those and then make sure I track their changes to their APIs.

A single MJ power API is far more preferable and if my comprehension of the BC4 API is correct, the TE dev team has to make a tough call whether to go with BC4 MJ power as-is or else have a parallel power system, but then that would make it more difficult for other mods to work with TE and TE would have to keep up-to-date with those mods. BC3 seemed to be the defacto MJ power API, at least from my experience. I don't recall any MJ producer or consumer having cross-mod compatibility issues. It's sad to see BC4 effectively becoming more strict/restricted.

*goes off to look in Forge to see if someone has submitted or is working on a common power/energy API*

not if TE supplies a converter block then all you need to do is put it between your engine and the TE power net and it will convert the power you wont have to code any extra bits unless you want to

altough I have wanted a common energy API in forge for some time now since all or atleast most mods use forge

 

[SandGrainOne]

The changes to the BuildCraft API prevents other mods from making their own versions of MJ power. It doesn't prevent anyone from using or producing MJ power. Both Forestry and RailCraft manage to do this this just fine and I'm sure there are other examples.

What Thermal Expansion did was to take it a step further and instead of using BuildCraft power as defined by BuildCraft it had its own version. This will no longer be possible. Mods like Thermal expansion will need to make a choice between BuildCraft Power, another existing power system or to make their own.

 

[Vaygrim]

I would like to direct everyone towards the Power Boxes mod. It has its own mathematics for storing energy, capable of converting EU and MJ to its own system for storage. This means that you can link Buildcraft power pipes to it as well as EU cabling, and have a single central box for storage AND converting power seamlessly. If TE ends up with its own power system, I am quite sure help could be lent towards the Power Boxes author to include this power system to the mod. I really think this could iron out all the bumps in regards to separate power systems and general usability between them.

If you are worried about TE getting its own power mechanics, I highly encourage everyone to aid in cross-communication between the Power Boxes author and KingLemming / Myrathi. (Now I'll stop advertising for another mod and be on my way, sorry!)

Mod Linky

 

[MigukNamja]

not if TE supplies a converter block then all you need to do is put it between your engine and the TE power net and it will convert the power you wont have to code any extra bits unless you want to

Exactly, and that's the problem I'm trying to avoid. Imagine if we spoke, for example, 3 different languages and none of them were in common. We'd had to have 3! = 6 different translation algorithms:

From A to B
From A to C
From B to A
From B to C
From C to A
From C to B

Cut that in half if you assume bi-directional translators, but that's still a lot. Rather, we have what we have now which is English, which makes these forums much easier.

It's a huge burden on the modders and users to have similar, but incompatible power systems. People will typically only use 1 or 2 of them at a time, which is where we're at today with 1.5.2 with MJ and EU. UE is nice, but it's a distant 3rd and by the time I have an MJ power system (my main) *and* an EU power system (for a handful of overclocked IC2 machines) setup, I'm not really eager to setup yet another one, even if the machines that run on that power are great machines and the power gen is cool/fun.

PowerConvertors is mostly optional in 1.5.2, but it works and I predict PowerConvertors or something similar will gain traction in 1.6 .

From a user/player's point of view, which is what this is ultimately all about, they just want to hook up an energy producer to an energy consumer and call it done. Converting power is overhead.

altough I have wanted a common energy API in forge for some time now since all or atleast most mods use forge

Indeed !! Even a basic energy system that nobody loves, but everyone can agree "works" would be nice. This would at least give the devs that code up energy producers and energy consumers the ability to convert to the common energy/power API, even if they had their own APIs that implemented their vision. If I code up an energy consusmer, for instance, I would support (implement) the common Forge API first, and then implement the specific APIs of the dominant energy producers/carriers (pipes) next. This means any energy producer/carrier using the common Forge API would be immediately compatible with my mod.

Note a new concept, mind you. A common API is the cornerstone of Forge, which is why I'm surprised a common (base level) power/energy API hasn't emerged. But, perhaps it's too contentious, what with the majors (IC2 and BC) being at apparent odds and all.

This is one the reasons that PowerCrystal's mods are so popular - they don't care about what kind of power is supplied, they just work.

 

[CovertJaguar]

Would you care to elaborate what you (or anyone who has said they've had issues with the API) no longer find possible with the new API?

Your input was specifically asked for while the API was being designed, we even added several features that you specifically requested after looking at it. If its just the percentage loss on power reception, we can probably accommodate that.

Making the PowerProvider final was done to solve several long standing implementation issues that had afflicted BC power networks for a long time, namely improper handling of direct engine power input and correctly requesting the right amount of power from pipes. Exploding Engines and Machines that would steal all the power from the entire net were common problems with the old API.

I would think Conduits would be excellently suited for the new PowerHandler. Your "network" could have a single PowerHandler instance that all your inputs return, and outputs just bleed power out of it.

 

[King Lemming]

Would you care to elaborate what you (or anyone who has said they've had issues with the API) no longer find possible with the new API?

Your input was specifically asked for while the API was being designed, we even added several features that you specifically requested after looking at it. If its just the percentage loss on power reception, we can probably accommodate that.

Making the PowerProvider final was done to solve several long standing implementation issues that had afflicted BC power networks for a long time, namely improper handling of direct engine power input and correctly requesting the right amount of power from pipes. Exploding Engines and Machines that would steal all the power from the entire net were common problems with the old API.

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 - addEnergy is nice (and I did request it), but calling the Perdition calcs isn't something I need or want done. That's code that I have no interest in calling - I was after direct energy manipulation with a minimum of overhead. A power request from the PowerReceiver forces the Handler to update, which calls the work function, perdition, and validation. Why? That's a lot of extra per tick stuff, and sometimes I just want to know how much energy something needs without forcing it to operate.

Overall, I can see how the new API is an improvement given the paradigm and design vision that you guys have. And it's a good vision, it's consistent. I didn't really follow that vision before, and I don't want to trample it now. I don't want you to kludge it up just to accommodate me at this point - it's easy enough to make a converter, even if less than ideal.

I would think Conduits would be excellently suited for the new PowerHandler. Your "network" could have a single PowerHandler instance that all your inputs return, and outputs just bleed power out of it.

That's how it worked before, I had a PowerProviderGrid class which was basically a redone PowerProvider with some extra functionality, such as %-based loss and overhead-minimized calculations, and dynamic grid resizing. I understand in the generic case that you want to be sure energy levels get validated properly and that there aren't leaks, etc. However, when you have someone who knows exactly what they are doing, the extra forced code calls are just not efficient, I'd like a way to excise them.

 

[CovertJaguar]

The overhead of those validation checks and maintenance updates is minimal, you are quibbling about pocket change while writing million dollar checks.

 

[CovertJaguar]

Flat Taxes are in! https://github.com/BuildCraft/BuildCraft/commit/6c76a9a8d655bd5276a8b5619b16d4339dfafc91

 

[King Lemming]

Flat Taxes are in! https://github.com/BuildCraft/BuildCraft/commit/6c76a9a8d655bd5276a8b5619b16d4339dfafc91

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 one class is just less optimal all around as opposed to just allowing the base class to be extended and flexible.

The overhead of those validation checks and maintenance updates is minimal, you are quibbling about pocket change while writing million dollar checks.

Quibbling about pocket change is how one becomes a millionaire in the first place. Relative to the operation at hand, I don't see it as pocket change, either. The validation and maintenance checks are unquestionably more CPU time than the manipulation of the value itself. If setting the value took 50 cycles and the extra stuff took 10, I could see it, but the situation is likely reversed from that. If Minecraft were multithreaded, I wouldn't care nearly as much, but we aren't there.

 

[ctate]

Look forward to seeing what concept the new engine utilizes, and of course the improved power infrastructure, hope some others will adapt to utilizing your API as well when that time comes.

The revamped machines also have me curious, revamped as in tiers? Or an overhaul of the concept?

As far as I'm concerned, by far the most significant 'win' you get in integrating with BC is gate signaling. As long as TE machines have a rich interaction with BC gates (and to a somewhat lesser extent the material handling), everything will continue to be hunky-dory.

 

[Mevansuto]

It's a huge burden on the modders and users to have similar, but incompatible power systems. People will typically only use 1 or 2 of them at a time, which is where we're at today with 1.5.2 with MJ and EU. UE is nice, but it's a distant 3rd and by the time I have an MJ power system (my main) *and* an EU power system (for a handful of overclocked IC2 machines) setup, I'm not really eager to setup yet another one, even if the machines that run on that power are great machines and the power gen is cool/fun.

Why would you have to set up a 3rd power system. Can't the UE mods run on EU and MJ?

As for TE, I feel it's a shame to see it go. Mods like Forestry, Railcraft and Buildcraft all worked together nicely before but IMO TE unified them and made them tighter. I feel it'd be a shame to lose this feeling of closeness. I worry what it'll do to modpacks like Tekkit that no longer use any power system that's not compatible with MJ, and it's kind of dependent on TE. My server uses only MJ and UE mods, because they're all compatible and I feel having too many different power systems makes it seem like they're from different games that don't really belong together. I'm against TE shifting to a new power system.

As for Multiparts, I feel it's great news, I always thought since FMP came out TE should benefit from them. But I don't think I'll update TE on my server until they're back in as a lot of systems are dependent on liquiducts and conduits.

 

[Zenthon_127]

Honestly, as long as TE machines don't have constant energy drain in 1.6 (one of the Top 5 Dumbest Mechanics in mods IMO) I will be perfectly happy with using BC Kinetic Pipes. Luckily we still have EnderIO in 1.6 for the old Liquiduct and Conduit mechanics.

 

[Azzanine]

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.

Also I don't much like BC's multi colored pipes. I've come to calling them "Clown pipes" as a system full of diamond, redstone, lapis insertion, iron, gold, emerald can look rather multi colored. It gets worse when you use Logistics Pipes too (then again LP can supplant many of those pipes mentioned).

 

[RedBoss]

Why would you have to set up a 3rd power system. Can't the UE mods run on EU and MJ?.

4th, per your reasoning. Universal Electricity is a power system in and of itself.

Whatever it takes to get TE operational is a good thing IMO. The "always on" function doesn't make much sense to me, as was mentioned I can't think of what I use MJ's for besides a quarry anyways. Using the RR pack it hasn't made a difference since energy is just energy to me since UE cables and cubes convert for me anyway.

Thanks for updating us KL.

 

[Yosomith]

4th, per your reasoning. Universal Electricity is a power system in and of itself.

Whatever it takes to get TE operational is a good thing IMO. The "always on" function doesn't make much sense to me, as was mentioned I can't think of what I use MJ's for besides a quarry anyways. Using the RR pack it hasn't made a difference since energy is just energy to me since UE cables and cubes convert for me anyway.

Thanks for updating us KL.

5 if you count Blutricity

 

[CovertJaguar]

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.

I admit some of the calls are extraneous, mainly because it was DEMANDED that support be added for tickless PowerHandlers. Power really only needs to be validated once per tick, but we can't rely on that, so it must be done any time it changes. Same for the doWork() callback.

 

[un worry]

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.

Aren't you guys discussing Requirements and Design? Given the cpu-intensive demands of modded minecraft, wouldn't consideration of key non-functional requirements (like minimizing cpu cycles to perform an operation) be essential before you code/finalize anything?