Thermal Expansion Status

[King Lemming]

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 (capes/skins, head drops, world gen, and other core functions) are all working correctly.

Thermal Expansion itself isn't in bad shape, but instead of porting 2.x up, I'm porting 3.0 backwards to sort of a middle ground. It's just easier and there are too many improvements. Having said that, the new BuildCraft API is causing the vast majority of the issues. CJ's new power system is, on the surface of it, a huge improvement over BC 3's implementation. However, the complete lack of flexibility afforded with the new system means that I can't do the same sorts of things as efficiently or effectively as I used to.

So here's what you are likely to see with the ported release of TE, short term:
-Machines with revamped mechanics
-Engines with revamped mechanics, 1 new engine
-Tiers of Redstone Energy Cells and Portable Tanks
-Tesseract improvements
-Strongboxes *might* make it in
-Panels *might* make it in

Unfortunately, Conduits and Fluiducts are going to be kicked to the curb for a while. We're looking into full ForgeMultiPart compatibility for them and I suspect it'll be a full rewrite from the ground up. Obviously this will also apply to the ItemDucts.

OmniTools is dead. There are too many APIs always in flux for me to want to keep that up as it sits, and pairing the OmniWrench and the Lexicon in such a fashion is sort of silly.

Instead, at some point, TE will get an automated and configurable Lexicon, and I'll bring back the OmniWrench as a standalone mod which is a fair bit easier to maintain.

Alright, and now I've saved the tough part for last, though I already alluded to it above. I'm no longer sold on using MJ as the basis for TE. I've already written a full energy API and I'm discussing with the team if we want to make the switch. Should this happen, we'll try and provide some sort of converter. This isn't a matter of unit disagreement, merely implementation details.

Sorry that I can't give an ETA, life is hectic and I just have tons of other demands taking my time. I also can't completely hand the code over to the new maintainers as it sits, since it's basically a mess.

 

[Pokefenn]

Its ok, take your time ^^
Excited to see this though

 

[Henry Link]

Very cool. I like all of the changes so far. But, please take your time. RL comes 1st. Thanks for all of your hard work on this mod.

 

[MigukNamja]

What Pokefenn and Henry Link said !

RL comes first and take your time ! I and many, many others appreciate the great work you and the other TE devs have done.

 

[Tristam Izumi]

Looking forward to whatever makes it into 1.6.x! Thanks for your dedication to the minecraft modding scene.

 

[Malexion]

Alright, and now I've saved the tough part for last, though I already alluded to it above. I'm no longer sold on using MJ as the basis for TE. I've already written a full energy API and I'm discussing with the team if we want to make the switch. Should this happen, we'll try and provide some sort of converter. This isn't a matter of unit disagreement, merely implementation details.

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?

 

[MigukNamja]

Oooh...just re-read 2nd time for clarity and to read too closely between the lines.

"head drops"
+
"Tesseract improvements"
=
Endermen heads ?

You mean I finally get to lop off an Endermen's head ? Whee !!

I'm totally speculating, BTW.

 

[Vaygrim]

KingLemming, I'm quite sure everyone will be excited and pleased with whatever new changes may come to Thermal Expansion! While I personally do miss Thermal Expansion a great deal right now, I must admit that I am feeling the lack of the OmniWrench in 1.6.2 very badly right now!

 

[Skyqula]

I am interested to see if other modders will use this new energy API or not... Annyway, this all sounds nice and exciting, its so gonna be worth the wait

 

[Vaygrim]

I am interested to see if other modders will use this new energy API or not... Annyway, this all sounds nice and exciting, its so gonna be worth the wait

Well if it is an energy system that is as easy to use and operate as the rest of Thermal Expansion is, I'm quite sure it will become popular.

 

[Shadowclaimer]

Woohoo! Lemming lives!

So glad to see you're continuing the project, rumors were around you had retired and it had quite honestly depressed me. Highly enjoyed working with you in the past and looking forward to continue a working relationship in the future.

I'm honestly really happy you guys are pursuing your own energy system, I'm really interested to see what you come up with and how you go about implementing it.

 

[King Lemming]

I am interested to see if other modders will use this new energy API or not... Annyway, this all sounds nice and exciting, its so gonna be worth the wait

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 do have respect for. So it's not simply an issue of me not liking the new power API, it's also a matter of Sengir and CJ having a comprehensive direction for how MJ should work, and I don't want to screw with their vision.

Woohoo! Lemming lives!

So glad to see you're continuing the project, rumors were around you had retired and it had quite honestly depressed me. Highly enjoyed working with you in the past and looking forward to continue a working relationship in the future.

I'm honestly really happy you guys are pursuing your own energy system, I'm really interested to see what you come up with and how you go about implementing it.

Well, I'm definitely *way* less active now as far as coding is concerned. Weekends are reserved for not coding now. Eventually I'll make my departure from the community, though it may be post 1.7.

As far as the energy system, it's basically just the Forge Fluid system except with energy.

I've modified it a bit since the version on GitHub, and added a reference implementation for EnergyContainerItem, but here it is:

https://github.com/KingLemming/CoFHLib/tree/master/cofh/api/energy

The point is to have something that's extensible like MC. The only relevant details are that something accepts or emits energy. How a given machine does this is *entirely* up to it. BC's new power API is fantastic from the point of view of it being a plug-and-play, but I much prefer the idea of having interface classes and calls, and just providing reference implementations. The interactions are defined, I don't see the real advantage of making a class final to enforce certain behaviors.

 

[Shadowclaimer]

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 do have respect for. So it's not simply an issue of me not liking the new power API, it's also a matter of Sengir and CJ having a comprehensive direction for how MJ should work, and I don't want to screw with their vision.



Well, I'm definitely *way* less active now as far as coding is concerned. Weekends are reserved for not coding now. Eventually I'll make my departure from the community, though it may be post 1.7.

As far as the energy system, it's basically just the Forge Fluid system except with energy.

I've modified it a bit since the version on GitHub, and added a reference implementation for EnergyContainerItem, but here it is:

https://github.com/KingLemming/CoFHLib/tree/master/cofh/api/energy

The point is to have something that's extensible like MC. The only relevant details are that something accepts or emits energy. How a given machine does this is *entirely* up to it. BC's new power API is fantastic from the point of view of it being a plug-and-play, but I much prefer the idea of having interface classes and calls, and just providing reference implementations. The interactions are defined, I don't see the real advantage of making a class final to enforce certain behaviors.

Love the sound of it, it definitely opens up a lot of possibilities for individual machines to creatively implement the system.

I can't offer much in the ways of code, but if you decide you need any artwork you know where to find me.

 

[Vaygrim]

KingLemming, I think fans of Thermal Expansion (such as myself) would be more than interested in testing out potential 'test variations' of TE with the new power system. I personally am extremely eager to try out a new power system that is simple and efficient!

 

[MigukNamja]

Is the new Energy in units of MJ or something else ?

protectedEnergyStoragestorage = newEnergyStorage( 32000 );
...
public EnergyStorage(int capacity, int maxReceive, int maxExtract) {
 
  this.capacity = capacity;
  this.maxReceive = maxReceive;
  this.maxExtract = maxExtract;
}

Given that Redstone Energy Cells store 600K MJ, I take it this is a starter energy storage or else in units of something else entirely. It looks like all the API calls use these same units, i.e. on the scale of 32K 'energy' units for the capacity.

 

[RandomMoped]

ooh, a new power system, are you planning on giving it compatibility with other mods? Aside from the BC converter.

 

[King Lemming]

Is the new Energy in units of MJ or something else ?

protectedEnergyStoragestorage = newEnergyStorage( 32000 );
...
public EnergyStorage(int capacity, int maxReceive, int maxExtract) {
 
  this.capacity = capacity;
  this.maxReceive = maxReceive;
  this.maxExtract = maxExtract;
}

Given that Redstone Energy Cells store 600K MJ, I take it this is a starter energy storage or else in units of something else entirely. It looks like all the API calls use these same units, i.e. on the scale of 32K 'energy' units.

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 wishes, so even though transfer is limited to integer quantities, machines can certainly save that data as a float, or convert it internally to 10 or 100 sub-MJs. Complete interoperability and freedom.

 

[MigukNamja]

Ah, cool, thanks. An Energy block which supports MJ and EU, for example, could implement IEnergyStorage and whatever the IC2 equivalent API is and store it internally in whatever units are appropriate.

I'm a huge fan of cross-mod compatibility and creating as cohesive/integrated set of mods as possible. If/when I get off my lazy duff and write my own mod, I'll want to play very nicely with the major "infrastracture" mods such as TE, BC, Forestry, RC, IC2, ComputerCraft, etc.,. It helps a *ton* when the mod devs have clear, consistent APIs like this.

 

[matpower123]

So the idea is staying with the default values of MJ(Example,1600 per coal)or using exclusive values for the new power system?
Also good to see you are fine

 

[King Lemming]

So the idea is staying with the default values of MJ(Example,1600 per coal)or using exclusive values for the new power system?
Also good to see you are fine

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.

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?

New engine is a fuel (and other stuff) burner. It's a more intelligent (and lower power) combustion engine - only 4 MJ/t. Such a thing is definitely going to be necessary if we do switch systems, in which case I'll be renaming "Engine" to "Dynamo" and maybe redoing the graphics.

Machines are just being revamped in that they don't consume the item before producing the output. While it's a neat mechanic, there's NBT overhead and null checks that I don't feel are worth dealing with.