gruneisen

Additionally, RO used to included a 'descent mode' which could be activated on capsules. It operated by changing the location of the CG so that the capsule could generate some lift as it re-entered the atmosphere. I'm not sure if it's still there - I haven't re-entered a capsule for some time, but if it is, it can significantly reduce the re-entry G forces as well!

You can add the SmokeScreen button via blizzy78's toolbar. From there, you can open up the SmokeScreen dialog and adjust the number of particles. I'm no expert on how these two mods work, but it will reduce smoke and flame together - I believe changing the total number of particles does just that and that the same bucket of particles is used for both flame and smoke...but don't quote me on that. And glad to help!

The easiest way to control CPU load with RealPlume is to adjust the number of particles that are used by SmokeScreen. You can do this during the flight and manually change the number of particles as function of altitude if you like.

I can say that I do not use any of the stock bug fixes. Additionally, the OP doesn't require, recommend, or suggest them, so I would guess that they are not needed or are not incompatible with RO. That being said, it appears as though Nathan gas been AFK for the last few days, and I'd wait for him to come back to answer your question. Of course, you can always install and try them and report back here any bugs or incompatibilities you may find! As a final note, the CKAN metadata for RO does not list any of the stock bug fixes as incompatible, so you should be good to go to try them!

Often times changing the PID constants in the atittude adjustment settings on Mechjeb can help sort some of these issues out. If you are using extremely heavy stages, however, using Mechjeb to change the attitude of your craft may not be reasonable - often times the control signal is completely saturated since the ratio of the control signal to the error signal is so high due to the large mass of the stage and the small reaction forces generated by RCS / SAS. Patience is key when changing the attitude of the spacecraft in RO - it's not like stock where the SAS is so unrealistically powerful that you can move about with no consequence. Giving the spacecraft a small nudge manually towards your desired orientation and then using phyics time acceleration (up to 4x) with the spacecraft just coasting is a way to perform attitude changes in a more reasonable, game friendly amount of time. This is a limitation of the Mechjeb automatic ascent module - what's happening is that once your apoapsis meets or exceeds the target you've programmed in, Mechjeb will want to cut the main engine off and coast to perform a circulization burn. This is completely unrealistic and often physically impossible due to the risk of re-igniting an ascent stage in orbit. Instead, you should be tuning your target altiude and gravity turn end such that all stages will burn continuously until you are circularized (or whatever your target orbit shape is). In Mechjeb, you can edit the ascent path and adjust the altitude at the end of the gravity turn as well as the turn shape - both of these factors are critical to performing an efficient ascent. The target altitude only tells Mechjeb where to perform the circularization burn which and does nothing to change the ascent shape and, as I say above, is not realistic. Personally, I disable the ascent autopilot (if I'm using it) between staging and ignition of my upperstage so I avoid conflicts where Mechjeb wants to kill the throttle (and therefore flameout!) my mainstage engine. I try to tune my gravity turn start velocity, end altitude, and turn shape such that a continous burn of my second stage after first stage completion will result in entering orbit at my desired altitude - this is mostly accomplshed by trial and error, though there are some analytical tools you can use to predict how much time you need to apoapsis at first stage completion in order to successfully enter orbit on your second stage burn. See above about having patience as you adjust the attitude of large stages - in space, time is almost free, so there is no reason to rush anything. Higher reaction forces mean higher accelerations which mean higher structural loads at both the beginning and end of the attitude change which ultimately means, in real life, more mass, which means bigger boosters and greater cost. Granted, this is not really a something we need to take into account in KSP, but it is why RCS and SAS forces are kept low - there is no reason to make them higher and doing so, if anything, has negative consequences! As RO is an attempt to make the game more realistic, all of these issues are taken into consideration. Cheers and happy KSP-ing!

Nathan - I was finally able to sit down last night to try this out, and I already had the most current version of RealHeat (v1.1) updated through CKAN. I re-downloaded the v1.1 release through github and installed just to be sure with the same results. Are there any other mods that might be affecting the way aeroFX are applied? As far as I know, everything I have is up to date - I generally use CKAN and KSP-AVC for mod revision control. Thanks!

I guess as a basic question - why did we loose the temperature display on a part right click menu? Was it a Squad change?

Thanks, Nathan. Will do!

Running RO v10.2, I'm getting 'mach' aero effects starting at very low velocities (~60m/s) and continuing into absoluate fireballs during ascent. I looked at the RO_Physics.cfg changes between v10.1 and v10.2, and several AeroFX parameters have been changed. v10.1 // AeroFX @aeroFXScalar = 0.003 @aeroFXDensityExponent = 0.5 @aeroFXStartThermalFX = 2.5 @aeroFXFullThermalFX = 3.5 @aeroFXExponent = 3.5 v10.2 // AeroFX @aeroFXScalar = 0.00004 @aeroFXDensityExponent = 0.7 @aeroFXStartThermalFX = 2.5 @aeroFXFullThermalFX = 3.5 @aeroFXExponent = 4.0 This appears to be physically unrealistic and may be a bug?

I have a complete installation of 1.0.4 w/ RSS & RO + required, supported, and suggested mods running on Ubuntu 14.04LTS. I'm having an issue where, as my ATLAS V is going transonic, at almost exactly 346m/s, the RD-180 will shutdown saying that there is Vapor in the Feedlines. Is there any reason this would be happening while the rocket is under full thrust and steady acceleration? Is this an intended effect of Real Fules? Cheer and thanks!

I don't know if you should make them last longer - I feel like I may have read / watched / heard something along the lines of what you're saying: that they are good for one re-entry and one skipout, but the reason was they were concerned about the stress (& strain) cycling of the heat shields due to the rapid heating and relative rapid cooling of the heat shields after they come out of the atmosphere. I could be making this up, but this would make sense - my experience / and recollection of other ablative materials is that they are very brittle and could see concern about the thermal stresses as well as just the re-entry aerodynamic stresses building up and compromising the integrity of the heat shield. If this is the case, would it be possible to have two different 'criteria' for heat shields: one being the ablative material and the other being a damage accumulation that is some function of velocity and atmospheric density (so realistically, maybe just drag force) to account for these different performance criteria?

Yes - that is what I meant. I'm used to numerical integration of multiple differential equations being done simultaneously - ie the black body radiation rate would be calculated based on the total temperature of the body from the previous timestep. Same with the conduction and convection rates. Then the total net heatflux of all heat transfer modes would be summed and then that total flux integrated WRT time and then the total energy of the body updated and the temperature calculated accordingly. I was interpreting you saying that the first physics tick, the total conductive flux is calculated, integrated, and the body assigned a new temperature. Then, on the subsequent ticks, the total convection flux is calculated from the previous tick (the conduction tick), then integrated, then temperature calculated and the same for BB radiation. If this is the case, I can see how wild swings in temperature would occur with large timesteps as only one mode of heat transfer is being considered with each tick. On a different note, with respect to the conversation a few days back about the amount of ablative consumed during Apollo re-entries, this NASA publication has some great info on heat shields in general and says that not even 20% of the Apollo ablators were consumed during re-entry! https://books.google.com/books?id=7k1sawDR-kEC&lpg=PA79&ots=w6lb7Z7ZtL&dq=apollo%2011%20heat%20shield%20performance%20report&pg=PA74#v=onepage&q=apollo%2011%20heat%20shield%20performance%20report&f=false Quoted information is from the bottom of the page the link points to.

Ick - So KSP doesn't integrate the differential equations simultaneously based on the total variable values from the previous timestep? It integrates piecwise? Does it do this for all, or just the heat variables?

I'm still hanging on to 0.90 while I wait for the rest of my mods to update and add support for 1.0X. In the meantime, I'm trying to use the Hangar Extender mod and, like many others, when I place the folder in my Gamedata folder, and fire up the game, I cannot re-scale the VAB / SPH. One little glitch is that I'm using Linux (Ubuntu 14.04). There's a well known issue with Unity not reading the 10-key pad on Linux so I've gone into Hange Extender cfg file and changed the function key to '\' since it's not on the 10-key pad and still nothing. Does anyone know if Linux is my issue or does anyone else out there use Linux and the Hangar Extender mod with success? Thanks in advance for the help!

I'm not sure if this is a bug or not, but I'm using the LazTek SpaceX mods w/ RO/RSS, and neither the upper stage or main stage tanks have any Nitrogen in them for the RCS thrusters integrated into those tanks. Nitrogen for the RCS is in the RO config file for LazTek and if I try to add it manually, it is not available in the tank GUI either (Nitrogen is literally not a part of the list for these tanks - I can add it for all other tanks, just not these). I have a feeling the reason for this is that the ModuleFuelTank in the .cfg file is set to 'type = structural' and I don't think that type can handle the Nitrogen gas. Can anyone confirm the same issue and if that is the cause? Thanks! Edit: I went into the cfg file and changed the tank type from 'structural' to 'servicemodule' and the Nitrogen is now showing up and able to be consumed by the RCS.

I've been using RT for a while, but am new to 1.6.2 and KSP 0.90. I've been using 1.4.1 and KSP 0.24.2 but have recently made the jump forward. When using the flight computer, it is failing to keep the orientation as commanded when the craft looses signal with a ground station. Has something changed in RT between 1.4.1 and 1.6.2 that requires a different method of programming the flight computer? As an example, I'm telling the computer to orient towards orbital prograde, and then prescribing a 2,500m/s burn @ 100% throttle. I hit 'burn' and the system starts counting down the dV change and holds orientation only as long as the craft has signal. Thanks!

Using RT v1.6.2, when attempting to use the flight computer, the system will hold orientation and thrust, however as soon as the craft goes out of range, orientation is no longer held yest the thrust continues? I have recently upgraded to KSP 0.90 from RT v1.4.1 and KSP v0.24.2 and am following the same technique that I used with the previous version. Thanks!

[ANSWERED] This is probably a silly question, but I am suing the Realism Overhaul w/ Real Fuels, and I am unable to get any of the upper stage mono propellant engines (like the Aerojet AJ10-118K modified from KW Rocketry), which use Aerozine / N2O4 for fuel / oxidizer. The engine will not light and, when I mouse over the engine in the VAB, it states the engine is pressure fed, and that no tank pressurized fuel tank containing the required resource(s) connected. I understand the fuel tank I am using is not pressurized, but I cannot fill the pressurized tanks (those designed for monoprpellant) with the Aerozine / N2O4. How are these engines used?