Fraz86

Very interesting! What if the heat sink piping of the reactor was intentionally connected to the structure of the spacecraft? That is, could the reactor be engineered to use the spacecraft itself to radiate some of its heat? In the context of space flight, in which you don't want to bring a single kilogram more than necessary of dedicated radiators, is such a thing at all plausible? I'm asking mainly because I'm curious if the current behavior - in which a non-trivial portion of reactor heat is radiated through the spacecraft - can be rationalized. Yes, it's an offline MX-1 reactor sitting on the launchpad with four "Streetwind-mode" GR-1 radiators attached and fully deployed. The screenshot illustrates that this setup reaches a steady state with the radiators hovering around 422K and the reactor stable at 4K. These findings seemed a bit extreme .

After toying with them for a while, I do like the ease of use of the Streetwind radiators, though their ability to cool things to near absolute zero feels a bit silly. Perhaps ambient temperature would be a reasonable lower limit? Or make it such that the "active cooling" function of radiators can only remove the positive internal temperature flux of the part they're attached to, but cannot actually induce a negative flux. With either type of radiator, I noticed some odd behaviors with high time warps (I believe it was x1000 or greater), such as dramatic instantaneous temperature changes (e.g., 750K -> 300K) even though nothing else changed. Also, now that we're using nominal temps, is it necessary to keep reactor and radiator maxTemps so low? It feels a bit counter-intuitive. Especially radiators; I would have assumed they would have higher temperature tolerances than most parts. As it is now, reactors and radiators are quite likely to explode during re-entry. Lastly, it would be nice if the right click display for reactors provided information regarding nominal and critical temps. A "Current Heat Output" field would also be nice, corresponding to the radiator's "Current Heat Input."

Fair enough, and thank you for the thorough explanation, but doesn't the above statement assume that the reactor an appropriate array of radiators installed? Without those radiators (or if the player is choosing to use his/her entire spacecraft as a radiator), then I would imagine the reactor would get a bit warm, no? This is really the scenario that I was speaking to. It does seem intuitive that - with proper heat dissipation through dedicated radiators - I wouldn't need to I should insulate crew capsules and fuel tanks from the heat of the reactor. I only meant that this insulation would be intuitively necessary if one was using the structure of the vessel to radiate the reactor's heat, which is basically how it currently functions. Thanks again for the detailed information; it really is interesting to learn how these things work in the real world! Edit: This is an interesting consequence of the "Streetwind" radiators (compare the radiator temperature vs reactor temperature):

The link doesn't seem to be working for me.

I wouldn't be so sure that Squad will ever significantly revamp heat management. They created the current heat system primarily to provide a reasonable model for re-entry heating. It sufficiently accomplishes that purpose (or, rather, it will once they fix the problems they created with changes to the aero model in 1.01/1.02). Beyond this limited scope, it would be very difficult to implement comprehensive heat management mechanics that make for fun gameplay (see Streetwind's posts for some of the reasons why). I strongly doubt that Squad will ever dramatically revise the current heat mechanics.

Perhaps you could show red lines only when a vessel has no connection. I propose showing red lines for two "potential" connections (when a vessel has no connection): 1. The closest out-of-range non-occluded receiver, with some graphical indication of how far your maximum range extends along the line. 2. The least occluded in-range receiver. That is, the receiver which is closest to not being occluded.

Expecting users to sift through different heat dissipation rates for different temperatures in different reactors is overly complex, I'm afraid. I think the reactors should be tuned to all share the same nominal temp. That way, all radiators can specify "Heat dissipation provided at nominal reactor temp," which can be intuitively matched against a "Heat dissipation required at nominal reactor temp" for the reactors. That said, I'm still not convinced that the nominal temperature concept is a good gameplay mechanic in the first place. On the one hand, it does offer an incentive to keep one's spacecraft cooled to a reasonable temperature. This is good, in principle. On the other hand, it means the nuclear reactor is now the most heat-sensitive part of the spacecraft, which is completely counter-intuitive, unrealistic, and not believable. Intuitively, I would assume that a reactor would be quite hot, and that I should insulate things like crew capsules and fuel tanks to protect them from the heat of the reactor. Instead, the opposite will be true if this mechanic is implemented. Placing insulators to protect a crew capsule provides no benefit (because the Kerbals don't mind being roasted alive), and would in fact be disadvantageous because the insulator would prevent the reactor from utilizing those poor Kerbals as the convenient radiators that they are. Basically, if a gameplay mechanic is implemented to encourage keeping a reactor cooled to a reasonable temperature, we need similar mechanics for other parts that should also be heat-sensitive. Otherwise, you're incentivizing players to facilitate the propagation of a reactor's heat throughout the entirety of the spacecraft, which is contrary to intuition. However, introducing consequences for over-heating other parts would be a sizable task (possibly out-of-scope for this mod), and may ultimately result in a gameplay experience that is frustrating and confusing (for reason's outlined by Streetwind). Therefore, perhaps it would be best for NFE to largely extricate itself from this dilemma by making it impossible to effectively use one's spacecraft as a giant radiator, which could be accomplished through Streetwind's proposal (reactor conductivity near zero, thus requiring the "active cooling").

This would be a marvelous solution, though I imagine rather difficult to implement.

I think Streetwind makes some good points. His proposed solution (i.e., representing active cooling by allowing radiators to take on the positive internal flux of the part to which they are attached, up to X per radiator) would certainly allow for straightforward and predictable heat management from the perspective of the average user, and it would effectively isolate NFE from the silliness of the stock everything-is-an-excellent-radiator behavior (by making reactors' conductivity very low). Alternatively, if you go the route of embracing the stock heat system, I think there needs to be consequences to super-heating parts for minutes/hours at a time. The stock maxTemp numbers are surely meant to represent the maximum temperature that can be transiently tolerated during re-entry, with most of the heat in the hull/casing, and with the sensitive internal contents protected by insulation. I can't imagine that Kerbals are meant to survive in a capsule whose temperature has equilibrated at 3000K.

Minor bug report: In the VAB, MechJeb's "Vessel Info" window does not include physics-less parts when calculating the vessel's mass. The 1.0 update changed physics-less parts such that their mass is now imparted to their parent part, and should therefore be included in the vessel's mass calculations.

Awesome, that sounds like a great solution!

Did you make new tanks specifically for LH2/O? Or are you adding FuelSwitch functionality to your existing tanks? I hope that NFP includes an [optional?] MM patch to add ISRU conversion options for not only LH2, but also Xenon and Argon. Edit: Perhaps NFE could even include an ISRU conversion process for Ore to DepletedUranium, which would be interesting because it would make the centrifuge much more valuable.

I'm a bit torn on the "crew utilize best available activity level on vessel" issue. On the one hand, I'm glad I don't need to micromanage constant crew transfers; it's reasonable to assume that my Kerbals move around the spacecraft on their own. On the other hand, it seems cheesy that I can achieve a "neutral" comfort status for the entirety of a large crew by installing a single Cupola somewhere on the vessel. Ideally, I would like KeepFit to track the number of seats available at each comfort rating, and automatically assign those statuses to crew based on level of need. For example, with 2 Kerbals on a vessel composed of a Mk2 Lander Cabin and a Cupola, one Kerbal would be "comfy" and the other would be "neutral," regardless of where the Kerbals happen to be located within the craft. The neutral status would be assigned to the Kerbal with the lower fitness level.

No problems yet, but I do have a few questions: 1) The OP says "The old C3 (now renamed to the Pioneer Module) will have a basic mulcher and greenhouse and can do recycling at 50% efficiency for up to four Kerbals," whereas the Pioneer Module's in-game description mentions "a modest greenhouse (25% efficiency) that can help replenish the initial supplies of your expedition." Which is correct, 50% or 25%? 2) What are the actual supply consumption and mulch production rates per Kerbal? E.g., 0.0001 units/second? 0.00005? 3) I noticed that the Pioneer module does not have any mulch storage. Is mulch storage unnecessary for the mulcher to function properly? 4) You mentioned that the Mk-IV modules will have different efficiencies for surface vs off-world. How is this accomplished, in regard to config code for the ModuleResourceConverter?

This looks great! I have a few technical questions for modding purposes: 1) The OP says "The old C3 (now renamed to the Pioneer Module) will have a basic mulcher and greenhouse and can do recycling at 50% efficiency for up to four Kerbals," whereas the Pioneer Module's in-game description mentions "a modest greenhouse (25% efficiency) that can help replenish the initial supplies of your expedition." Which is correct, 50% or 25%? 2) What are the actual supply consumption and mulch production rates (in terms of the "ratio" units used by the ModuleResourceConverter)? E.g., 0.0001? 0.00005? 3) I noticed that the Pioneer module does not have any mulch storage. Is mulch storage unnecessary for the mulcher to function properly? 4) You mentioned that the Mk-IV modules will have different efficiencies for surface vs off-world. How is this accomplished, in regard to fields for the ModuleResourceConverter?

I understand this much, but I'm curious how exactly exactly it works. For example, does a workshop having a ProductivityFactor of 5 mean that each kerbal inside the worship has an output equivalent to 20 kerbals inside a command pod with a ProductivityFactor of 0.25?

Three questions: 1) What are unskilled vs skilled workers? 2) What is the distinction between "can work" and "is always productive"? 3) What does productivity factor do, aside from defining fully equipped workshops? Is it a multiplier for the work done by all kerbals working inside that part, or a maximum total output for the part, or something else?

It would be great if this were fixed, because currently, if I want to add a built-in short-range (5km) transmitter to all probes, I have to give it a range of 605km, but that gives them way more range than intended in other capacities (e.g., as a relay).

Contracts.cfg in GameData/Squad/Contracts includes "Antenna = ModuleLimitedDataTransmitter" as a module definition, which ought to provide support for AntennaRange.

I apologize if this has already been addressed, but do we have DRE support for the new parts in 0.90 (i.e., Mk3 and the fuel-containing 2.5m/1.25m adapters)?

Any chance of getting USI Shipyards as a separate pack? MKS/OKS isn't my cup of tea, but I would love to have a pack of attractive parts to overhaul EPL, utilizing resources obtained with AMT.

I agree with everyone opposed to nukes. I don't think nukes would add anything interesting, and I don't think they belong in this mod. Regarding futuristic weapons: personally, I'm primarily interested in additional "near-future" weapons intended for use in orbit, along the lines of the HE-KV-1 and Airborne Laser, as opposed to Sci-Fi weapons like seismic bombs.

The cluster bomb and Mk 82 bomb were not loading properly for me. I investigated the problem and found that the part.cfg for both of these weapons was actually named "part .cfg" (with a space after the "t"), which apparently prevented them from loading properly. Deleting the space solved the problem.

I used FAR for a long time prior to the creation of NEAR. Honestly, I haven't noticed much difference. I use NEAR mostly because I don't want to bother with Mach effects and other complex issues; I just want "intuitive" (to a layperson) aerodynamics, which is essentially what NEAR provides. I don't want the game to be a realistic flight sim, but the stock drag model is just moronic.

Should NEAR users try this as well?