Temperature of Part

[andrey-zakharov]

Is it possible to add kOS field - Part:temperature?

[erendrake]

It is possible. the reason I haven't added it yet is that I wanted to have a conversation about giving the user information that there is a dedicated sensor for. I am totally ok with giving the PART:MAXTEMP because that is a reference value.

As far as PART:EXTERNALTEMP and PART:CURRENTTEMP are concerned i am not convinced that the part would know what temperature it was until it was destroyed because most parts wouldnt have the sensors. That being said i am willing to be convinced :)

[ianjirka]

Maybe not all structural parts (or maybe TL dependent), but all the interesting parts will likely have great telemetry. Rockets launches are expensive, you want the most out of each one :-)

As an example: http://spaceflightnow.com/shuttle/sts107/030309autopilot/

Could start with just engines if you're concerned. That's the most likely use case IMHO* - throttling back long burns on overheat. It's also the part most likely to be instrumented for that kind of telemetry (again IMHO)

*turns out this is also what I wanted CURRENTTEMP for...

[hvacengi]

First, on premise I agree with @erendrake, I don't like the idea of exposing information to the user that you wouldn't practically have access to. The challenges of scripting for KSP should at least some what reflect the challenges that you have with real space craft. That being said, there are some instances where it makes sense to provide access to more than the raw information available via sensors on the ship (and we do).

I'm against the idea of reading the external temperature. This is incredibly difficult to do in re-entry, though fairly easy to do any other time.

As for part temperature, there are some parts that we can safely assume have sensors built in: engines (I'd expect them to have a lot of sensors), heat shields, command pods, and fuel tanks for starters. Since we already have a separate struct for engines, it would not seem absurd to provide a temperature reading their.

As erendrake pointed out, there is an in game thermometer part. However, direct reading from the sensor itself only provides a string value. Reading from the vessel's sensors suffix will provide a value as a double, but it will only return a value from a single sensor on the vessel. I want to say that @ZiwKerman said he was having an issue with one of these values lagging too.

Has anyone tested out how quickly the thermometer updates it's temperature based on the new thermo model? It may be that the sensor reads that part's temperature instead of the temperature of the part it is mounted to. That would mean that it would have to lag behind the temperature of the part it is attached to since it has to absorb heat from the parent part. This could be another point of complication.

After working that all out in text, I think that my suggestion would be that we make a means of exposing sensor data numerically, and add a temperature suffix to the engine struct (most engines do not allow radial attachment).

In slack, space_is_hard has also recommended using MM to add a partmodule which would enable temperature sensing. This would let the kOS team provide a default configuration which could then be overridden by the final user with another MM patch. That would have a lot of advantages.

I wish that the KSP editors (VAB/SPH) would let you make part modules optional, that way you could enable upgrading a part for a cost. I suppose we could maybe implement the partmodule (or extend the existing name tag module) with a bool value for "Temperature Readout" and then that module could update the part's cost and mass. That way the user gets to "install" the sensors where they want on the ship. You would need to use the name tags anyways to have any serious chance of knowing what part you're reading the temperature of.

[space-is-hard]

That way the user gets to "install" the sensors where they want on the ship

We've also got to keep script sharability in mind. We don't want to make the author of an otherwise one-size-fits-all script have to say "This script only works if you install temp sensors in your engines"

[blnk2007]

"As for part temperature, there are some parts that we can safely assume have sensors built in: engines (I'd expect them to have a lot of sensors), heat shields, command pods, and fuel tanks for starters. Since we already have a separate struct for engines, it would not seem absurd to provide a temperature reading their. "

I agree with this. Why wouldn't engines have temperature reading? Doesn't your car?

[Dunbaratu]

Bumping this with a new comment : in KSP1.0.5 each part will have two different temperatures - core vs surface.

[andrey-zakharov]

each part have two different temperatures - core vs surface in 1.0.4

[kosstarter]

Currently, KSP has version 1.1.3. I've read all of the previous comments. Personally speaking, i would like to be able to determine what parts become (over-)heated during a flight. During the ascent and descent of a craft in the atmosphere KSP already displays warning bar's which provide information that the parttemperatures are high. During testing of a new aircraft the aircraft has a very large number of sensors. Even when an aircaraft has been deemed flightworthy, there are still a lot of sensors in the aircraft. The same thing applied to the spaceshuttle(s) and every rocket ever launched (or will be launched). In my case, i would like to determine what the best pitch is during a flight, given a variable load placed at variable locations in the craft (an SSTO). Only considering the fuel consumption is just too limited i.m.o..

[Lookerksy]

In next version, would you mind add part's temperature data (current temp & max temp) into fields the part struct? I think it's necessary, like SHIP:ALTITUDE. Without temperature data, I don't dare to make any vessel working at high speed in atmosphere. Because I have no idea about avoiding overheat explosion.

[jmurrayufo]

This would be great to have. Recently been playing with a ship that is prone to exploding if run at too high a throttle for too long a time. My first response was to build a controller to handle the balance only to find KOS doesn't support reading the data from KSP.

[bilts]

most parts wouldnt have the sensors. That being said i am willing to be convinced

If there are parts that are known up-front to need temperature monitoring, those parts absolutely would be built with sensors. In my case, I want to trigger staging at a certain part temperature because it's simpler and more precise than going off of burn time, altitude, etc. Realism-wise, this would likely just be a thermostat in early rockets, where a circuit gets completed when a certain temperature is reached: simple, reliable, cheap.

This would be a very helpful enhancement. I can't imagine any game-breaking implications, but I'm a relative novice to kOS. Even if it could somehow allow unrealistic things, it's a question of whether to enable realistic things that also allow unrealistic things or to disable both. Given this is KSP, where we all choose our own level of realism, I'd strongly favor adding it. If you're concerned about accidental unrealism, maybe a line of documentation on the property about the pitfalls could help?