In a number of mods, there are blocks that require being placed above a block that produces heat, such as the Thaumcraft crucible or the Witchery brew kettle, but vanilla only has two reliable block sources of heat, lava and burning Netherrack, both of which have the inconvenient tendency to set anything around them on fire. Thaumcraft Nitor, and presumably other mod blocks produce heat, but as they are they can only work with things in the same mod that require heat. I think that there should be a dictionary for blocks that produce heat, so that these things can be done more easily.

What is 'heat'

What direction does it go?

What range does it have?

etc..

etc..

etc..

 

This is not a 'Dictionary' thing, we can't just add something arbitrarily like that.

We would have to fully define what 'heat' is and how to use and describe it.

Your 'suggestion' needs to be more fleshed out.

Heat would work similarly to light, it would decrease depending on distance travelled, and certain blocks would decrease it more than others (based on hardness and material) the numbers need to be worked on, and there would have to be some agreement between modders, but the idea itself would be useful

Feel free to start working on it, Suggestions need to be fleshed out not 'I want heat things'

Working on a basic version of this.

Sounds very interesting. I imagine this'd include things like combustable fuels having a heat value, and machines which use them have a minimum heat level? I.e., furnace fuels.

I'd be more worried about the extra CPU load... updating another source set would bring many computers to their knees... Maybe a heat mod/api is feasible but forcing it on the community by incorporating it with forge will just be damaging

I would imagine any calculation would be done when the heat level is checked, so if no mod uses it no processing is done. Not quite the same as light. However if it was implemented alongside light it wpuld allow for a better implementation of ice melting. (Based on heat level as opposed to light level) and wouldnt need to constantly check heat level

I see this a bit far out of forge's intended reach as what can be used as heat is only done in a small collection of mods, it would make more sense for forge to support a macerator dictionary than this and even that sounds crazy. Also there would have to be some heat variable implemented and all the mods that use heat would have to support it and not all may want to use it.

The "not all may want to support it" argument is pointless, you could say exactly the same thing about forge itself. If they don't want to support it they won't, but what reason would they have not to? The macerator dictionary would be useful for a single (or maybe a couple of) blocks from a few mods. A heat dictionary would allow for better control and differentiation between light level and heat for melting blocks like ice.

It would also simplify mechanics such as factorizations furnace heater. And where is the logic in a standard torch being hot enough to heat a crucible but a furnace heater isn'?  This would become a compatibility layer, which makes forge the perfect place for it

I'm not saying this is a bad idea but think of it this way, there are about 8 mods who use this and each uses it differently, the way it is used varies a moderate amount. It doesn't make sense to make an API (implemented in forge, a freestanding one is a different story) to support a varying underused system. There should be more time put into developing other things than this. If you want to take a crack at it I say it's worth a shot but I don't think at this time it makes sense for a forge developer to be doing this.

I think the plan from here would be to create the API then submit a PR. The issue with a standalone API is that no-one hears about it for a long time.

No this will in any given scenario make forge have greater impact on system resources. What you recommend would either require a look-up table to be stored on heat values like the light values, which requires additional RAM to store it and a faster clock rate to keep the ticks up to par for updating the tables. Thereby decreasing the accessibility of Forge.

 

Or it'd be a parsing equation searching for heat sources which you may as well write your own since you'll  have to call for it to be run anyways.

 

Alternatively you could simply add a function into the block class such as 

public int getHeat(Object... params){
return 0;
}

Would be quite simple. But has absolutely no tie-ins to dispersion. Also would mean that you'd need to find a way to encourage modders to adopt and utilize a method that is not required.  And even if you do manage to catch a few peoples' attention with the little added snippet, you then have to question how to make everyone conform to a scale? Enter the Celsius v Fahrenheit arguments? Confuse the masses with Kelvin? Arbitrary numbers? After all that dumbing down of a good idea for a system, you're left with another value like brightness that'll repeatedly get abused the handful of times it is used....

 

It does not really seem to me like a feasible addition for Forge unless integration by vanilla minecraft forces... ahem... adaptation. Not because it won't get used often, which it won't, but because integration would be a nightmare.

The scale and the abuse are two reasons why I haven't written an implementation. However I like the idea, and would use it if it was implemented.