Starwaster

What you can do is edit the powerCurve in the solar panels. The easiest way to do that is with ModuleManager 1.5 and a config file similar to the solar panel fixer I made available for this mod. But you don't want to use that exact file because the distances are calibrated for the mod not stock. powerCurve is a series of keys showing the distances that power is multiplied by given values.

If you're still having problems with solar panels (Kass et al) try placing this file in the RealSolarSystem folder (GameData/RealSolarSystem) If asked if you want to overwrite the existing file, yes you do. And you should be out of the game so you can restart it. RealSolarSystemSettings.cfg (Nathan, the numbers need to be exp notation. Or at least the big ones; I did them all like that just because...)

Ok, Sarbian here's an idea for some re-entry sanity checking. When MJ starts a de-orbit burn or entry course correction it should save the original delta-V requirement. Then, at several points during the burn it should check to see if the required DV has gone up or gone down. If a (to be determined threshold) number of such samples show that DV requirements are going up instead of down then something has gone south. MJ should re-initialise the re-entry. (basically the equivalent of me pressing abort and then pressing either land at target or land anywhere, depending on which I was trying to do originally)

when you slow down enough your orbit is carrying you into the ground. Prograde will point in that direction as well. Pointing retro at tha time will have your aft aimed at the ground eventually.

I was kind of thinking about half would be a good value. It would still be a tiny bit overweight but give a safety margin. But who the heck am I kidding? Re-entry heat isnt even a problem for me; my Kerbals routinely have to be sponged off of the aft bulkhead and their liquid remains squeezed into a bottle because I cant stop coming in ballistic. RSS might be a factor too; maybe I didnt put in the right values formRSS. Or maybe I just suck at re-entry. Yeah, I know. "Jeb raised his hand at the back of the room with a smirk and a sideways glance at Bill and Bob. Uh yeah, I have a question. What did you mean by 'minimum safe distance?'

Doing a bit of research on this... comparing it with the Apollo CM. Apollo's aft heat shield was about 15% of the total mass (848kg shield / 5806kg CM); so 600kg would be the right mass for a 4tn capsule.... WITHOUT DRE Which I assume you are using or you wouldn't have noticed. So yeah, 1.6 metric ton heat shield for a 4 ton capsule does seem a bit much, You could reduce the base mass when DRE is in use with a ModuleManager config file. Maybe base value down to 0.185 and reduce the quantity of AblativeShielding resource (FYI, the density is probably already lower than it would be IRL... at about 31%-38% of the real world density). Here's an example of how it would work. Amounts are left blank because I'm not really sure what a 'safe minimum' would be... @PART[SDHI_2.5_Heatshield] { @mass = 0.185 @RESOURCE[AblativeShielding] { amount = maxAmount = } }

Some of the engines don't always have TL increases, not sure if that's deliberate or not. Which engine were you trying to modify the TL of? Currently yes, you do. I think Nathan at some point intends to tie it into the R&D....

That's BS, I don't have that long!!! I have to wait until 2515? Where's the complaint department?

Let's weaponize it...

Part of the problem there is that some of those planetary bodies had different parents before. Additionally, Alarm Clock uses (IIRC) 100 years of precalculated data which RSS invalidates. (or rather, the data is only valid for the Kerbol star system, not Sol) I don' know about Protractor having any major issues. I have used it to make transfers in RSS so I don't think it's using any data tables such as KAC does.... but it's not by itself accurate enough either. What I do is I use it to calculate my ejection burn. Once that's done and I'm out of Kerbin's SOI... I target the planet and bring up a Target info window (I don't think MJ has it by default, I think I had to make it with the custom window editor) and find out the time of my closest approach. You might have to play with this part a bit... sometimes you really don't have to do anything but tell MJ to fine tune your approach. If it complains (yellow text...) then I abort the course correction. (do not have auto-warp on for any of this until you're sure that you're sure.) If fine tune failed me then I use the 'Intercept Target...' option. The one that lets you define how long after the burn you actually intercept. (default is 0s but you may want to schedule the burn for later, I'll assume you already know when you want to make these kinds of burns). The real question is the 'how long after burn' part. I use the time of my closest approach as a starting point and if I don't like the numbers I play with either the intercept time or the burn time. One caveat with this approach is that MJ might do something foolish and try to put you into a retrograde orbit around Kerbol because it apparently thinks you're piloting a warp driven starship... One possibility might be to use the Rendezvous Autopilot but it really has no concept of time and it basically assumes you've got lots of fuel to spare and lots of time. It might be ok in stock KSP but RSS could trip it up. But it might be worth trying.

I never understand this around here. There's a definite problem with the part, people aren't making it up. They offer feedback and even suggestions; if the suggestions aren't acceptable, fine, no problem maybe if enough people provide enough ideas and feedback, something will coalesce into a viable solution.... do you not want that?

One thing I've noticed is that 106 does roll less but I did have an unwanted roll on descent that stopped when I disengaged the AP and turned off Force Roll in the Smart A.S.S. BTW am I the only person, who when playing KSP alone in their room at night, while clicking MJ buttons, shouts authoritatively at the screen.... ENGAGE THE SMARTASS!!!!

106 testing: (done with MJ + KWR) Occasionally opens throttle to full after executing a maneuver node. landings: 2 out of 3 successful with stock Kerbal X. Failed attempt it turned 90 degrees (approx +Normal) and executed a continuous burn Until it reached eject velocity out of Kerbin orbit. At this point for ****s and giggles I turned on infinite fuel mode to see if it would ever correct the error. Landing status indicated it was making a course correction. The DV of the course correction continued increasing until I got tired and hit F9 for landing attempt #3 All 3 attempts were KSC targeted landings. Edit: During landing, when orbit went hyperbolic, an error was generated by OrbitExtensions.NextTimeOfRadius(). The landing AP should trap errors like that and either abort the landing or correct the orbit. Although realistically, by that time it's probably too late and you're using F9 to get back to your quick save. This isn't really a 106 specific problem, not new at all but probably intermittent. MechJeb module MechJebModuleLandingAutopilot threw an exception in Drive: System.ArgumentException: OrbitExtensions.NextTimeOfRadius: given radius of 603783.286865588 is never achieved: o.PeR = 603796.610583531 and o.ApR = 674048.814738914 at MuMech.OrbitExtensions.NextTimeOfRadius (.Orbit o, Double UT, Double radius) [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleLandingAutopilot.ComputeCourseCorrection (Boolean allowPrograde) [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleLandingAutopilot.DriveCourseCorrections (.FlightCtrlState s) [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleLandingAutopilot.Drive (.FlightCtrlState s) [0x00000] in <filename unknown>:0 at MuMech.MechJebCore.Drive (.FlightCtrlState s) [0x00000] in <filename unknown>:0 [/code}

Are you using KJR? If so , try removing it, setting mass back to normal and testing again. Edit: some clarification on the above. KJR reinforces joints but it ignores parts below a certain mass. I don't know what the threshold is. My thinking here is that reinforcing some parts while ignoring the low mass parts makes those parts squishier than before KJR was used. I haven't had a chance yet to test my own theory and one thing I want to check is if Ferram4 made the mass threshold configurable.

You mean how like when you're approaching from orbit the terrain suddenly changes? I don't know for sure but I don't believe in insurmountable problems. It's probably just a scaling issue that still needs to be solved. I hope.

KSP has atmospheric handlers that you can change properties on through code. RSS will have that soon.

If it never flew I wouldn't call it functional. They had plans for it maybe, just as we did for ours. No more than that. I suggest checking out out the RF config in my signature. It was designed primarily to beef up the NTR a bit, including alternate fuels. They're not limited to hydrogen. (keep in mind though that the MFSC version isn't fully tested, it was finalized for MFS and converted to MFSC and might have mistakes)

Bottom line is, you need multiple or bigger tanks of H2. Thats common sense really, I think you even answered your own question. Yes that is how it would be IRL. No, not everyone agrees nuclear is the way to go, (IRL. Zubrin for example) Regardless, you cant expect a fair comparison using a single tank. An NTR vessel wouldnt have the same design, not with H2; its Isp is double that of a chemically fueled rocket; Isp governs how much thrust you're getting per kilogram which is mass. but at a fraction of the density of course you need to compensate with more H2. Keep in mind, too that the nuclear engines are still using stock values which in turn are based on prototypes that never flew. Production versions would have had better performance, both Isp and thrust. Edit: @Nathan, 111 and 333 KNt of thrust are well in the capabilities for NTR and somewhat higher Isp too. (NERVA figures for both were based on 2500K - 2700K chamber temps. If you go a bit higher to about 3000K it gets better)

Probably because overheating was toned down. If they don't heat up there's nothing for thermal animationnto grab onto

I'll check it outs an hour or so.

I've seen that in older versions, I thought it was fixed.

Suggest you use the AG editor to look at the tank's dry mass and fuels. Sounds like it's not updating fuel properly. Use the editor to remove all fuel from the tank then reconfigure for the attached engine. That should serve as a workaround.

It's not about making lighter rockets. It's about making lighter stages. Look at the Saturn V. The bottom stage used kerosene (RP1) & liquid oxygen (LOX). The upper two stages used H2 & LOX. Did that lower the delta V available to those stages? Yes, it did. But by lowering the mass of the upper stages they increased the delta V of the lower stage because it had less load to bear. Or it also let them increase the payload that could be lifted to orbit. The point at which you would consider H2&LOX is the point at which you're looking for ways to lessen the load being carried by the stages underneath.

You can also rate the thread with an Exxxxxcellent

Physics time warp x4!!!!