Black-Talon

Really great stuff here! Needs to be Stock for sure - tell all your friends to use this when they first get started! "Just got KSP, must have mods?" KSP Tips! - - - Updated - - - Ok I guess I do wish the little ? box, and the tips themsevles, were movable so they didn't overlap the stock UI. But otherwise this is the best!

+1 Well said. Interacting with humans is the best and worst part of gaming (life?) - the crap gets so tiring

This is working wonderfully, thank you!!

I get the impression that is what RoverDude is doing. Though it currently appears that the only thing FAR gets upset with is the Command & Parachute Modules being on the same part. In FAR v14.6 it *seems* like I can manually add drag to parachutes without creating an issue. So nosecone (with parachute) on top of a "Gyroscopic Guidance Package" (with command module) would work perfectly AND both parts could have FAR drag on them!

I also added a time delay to the DropTank - It was pretty simple to add a configurable time delay and once I was in the code so I added that feature to my copy. It makes the drop a little cleaner since the forces on the parts are kinda going crazy at that moment of engine cutoff. Happy to share suggestion though if for any reason you want it. I should probably figure out this GitHub thing in order to suggest code...

RoverDude, what do you think about the approach below for a DropTank that drops even when it has a little fuel left in it? The issue being that the tank shouldn't be dropped until the fuel can no longer be burned but we don't know what exact amount could be left unburnable and sitting in the tank. Your current implementation allows for fuel to be left in the tank and still drop by setting a "threshold" of fuel remaining which is considered empty. It has the drawback of requiring a fixed amount of fuel to be defined as empty, and as was the case with my test cases, the threshold may be set too low and prevent the tank from decoupling. But set the threshold too high and the tank will decouple while a Solid Rocket Motor is still burning. With the approach below the fuel remaining is checked, once the threshold is crossed, to verify that fuel is no longer being consumed from the tank prior to decoupling. This allows the threshold to be set higher without risk that the tank will drop before being empty. In turn, this solves my issue of the tanks not decoupling because the threshold is set too low for a particular tank/engine. Your thoughts? public class USI_DropTank : PartModule { //tank decouples when out of resources. May have hilarious results. [KSPField] public bool explode = true; [KSPField] public float threshold = 0.01f; private Dictionary<String, double> previousAmounts = new Dictionary<String, double>(); public override void OnUpdate() { if (!HighLogic.LoadedSceneIsFlight) return; if (vessel != null) { bool drop = true; double previousAmount = 0; foreach (var res in part.Resources.list) { if (res.amount / res.maxAmount > threshold) { drop = false; } else { if (previousAmounts.TryGetValue(res.resourceName, out previousAmount)) { if (previousAmount != res.amount) drop = false; } else drop = false; previousAmounts[res.resourceName] = res.amount; } } if (drop) { if (part.parent != null) { part.decouple(); } if (explode) { part.explode(); } } } } } - - - Updated - - - Sounding Rockets + FAR I have more or less completed the testing on the ModuleManager Configs I made for Sounding Rockets v0.1.1 to better work with FAR and I'm pretty happy with them! Data if you want it - https://docs.google.com/spreadsheets/d/1K9UVrXre7bIuG8vGBbowGKdB5ZK6XZxiga1wa1N4vmM/edit?usp=sharing Short Story: With these configs the performance of Sounding Rockets is inline with the performance of stock boosters/parts when using FAR. It adds drag to the Nosecone and correct lifting surfaces and thus drag models to the fins. You should expect the performance of Sounding Rockets while using FAR to be enhanced to the same degree that Stock parts performance is - thrust/isp of the rockets was not adjusted. Known issues: FAR and Sounding Rockets don't work well together because of the Nosecone with a command module and a parachute in the same part. This results in: - FAR Flight GUI is not able to be opened when the Nosecone is on the craft - When applying drag using my configs, a Revert to Launch with a craft equipped with the Sounding Rockets Nosecone will cause FAR to freak out and no drag will be applied to the craft for that next flight. Reverting to VAB/SPH instead prevents this. I believe this is fixed in FAR v0.14.6. Download Configs (these are identical to those I shared previously): https://www.dropbox.com/s/6kgtqncsyxuui3a/FAR%20ModuleManager%20Configs.zip?dl=0 And it sounds like RoverDude will Soon have a new version of Sounding Rockets that avoids the FAR Flight GUI issue! *cheer* -Talon

I'll also likely drop in a mini decoupler given that we already get decouplers at 5 science anyway.I now see that USI_DropTank does have a "threshold" value set in the part. Adjusting this should at least let me test my theory. - - - Updated - - - Setting the USI_DropTank threshold = 0.015 does the trick for me. Setting it to 0.01 did not. Fuel in one of my test cases was frequently cutting the engine with 0.01 units shown in the UI as remaining in the tank. I have some ideas on how USI_DropTank logic could be changed so threshold can be set higher by default without negative impacts. But one thing at a time... Going to finish these darn test cases even though they may not be all that useful with the new version (which looks super awesome!) in the works!

Awesome!Any leads on what causes FAR to be upset with the current parts that you've been able to avoid in the new modular parts? And any thoughts on the belief that booster ejection fails in those rare occasions where a fraction of SolidFuel is left in the tank unburned?

Update on Failure to separate booster issue - Tested with FAR & Module Manager Only - Issue Persists Given that I've also experienced the issue with and without FAR with no change, I'm left suspecting ModuleManager or the root cause to be in the behavior of USI_DropTank Module. New Theory!! - Since I'm using ModuleManager to add the USI_DropTank Module to my stock RT-10 Solid Booster AND I'm cutting the fuel down to 216.5 liters I happen to notice that my solid rocket booster sometimes flames out with 0.2 liters left in the tank. I have no idea if this is normal or why it sometimes happens (or is it always and I haven't noticed?). But hey, it's possible that USI_DropTank is waiting for the Fuel to reach "empty" in order to trigger a separation/ejection/jettison. And it's possible that 0.2 isn't considered empty. And it's possible that my setup of using USI_DropTank on the RT-10 AND cutting the fuel to 216.5 liters (50% of full) exacerbates the chances that flameout occurs with a few drops of fuel left in the tank. Thoughts? - - - Updated - - - BTW - I've tested and confirmed this trick/work-around does not prevent the separation issue in my case. You had me hoping though!

When you say it "works fine with FAR" I feel obligated to point out that you must not be attempting to open the FAR Flight GUI when the Nosecone is equipped. In addition it must not be a problem for you that the Nosecone has Zero atmospheric drag applied to it which causes it, or parts it is attached to, to accelerate through the atmosphere at ridiculous rates. These issues have been acknowledged but "works fine with FAR" is misleading imo. Sounding rockets plus FAR have known, FAR/Game breaking issues. It would be like saying it works but my rockets never run out of fuel and IVA view is unavailable. Just my two-cents...as I don't think we should mislead people about what works and what doesn't.

I'm afraid that isn't it for me. In the tests I am using the StockBugFixModules, Kerbal Engineer.,Editor Extensions, Module Manager to apply tweaks, and my own .dll to remember max surface velocity. I suppose StockBugFixModules has a fix to ejection force decouplers... Let me know if you want any of these tested (though I'm a little tested out!). The erratic decoupling happens both before and after I add FAR to this mix. It can work several times in a row with these mods installed but it just isn't reliable. I tried like crazy to narrow it done to a specific configuration of parts or build order or launch profile but nothing correlated. Sounds like you might already have some ideas on what causes FAR to flip out about that Nosecone - have you been able to eliminate that with your new parts? Or any ideas what is causing it about that darn Nosecone?! I've come to far not to know more hehe. :-) -Talon

RoverDude, I haven't given up on Sounding Rockets + FAR - however, I've hit a lot of snags and bugs. I think it's time for a dump of feedback. FAR Module Manager Configs: The ones I linked previously work well enough if you want to include them (see below though) Nosecone - This conflicts with FAR and appears specific to the Sounding Rocket Nosecone model - any ideas why it doesn't work? I highly suspect something with the model because if I add the entire Sounding Rocket Nosecone config to the Mk16 stock parachute (with appropriate changes to match the Mk16 model of course) FAR doesn't have any issue with it. For specifics, see this post - note however that Ferram's response really didn't seem specific to either of the two issues as both happens ALWAYS and the FAR Flight GUI won't even load with your part. Something is odd with it since no other part has this issue, including ones with identical modules...ideas on your end? Without this working, my conclusion is that Sounding Rockets is incompatible with FAR regardless of the configs - it can't be fixed in the configs. But I think you can fix it if it easily if we knew what the exact issue was. Super minor - Note that your latest .zip erroneously includes the file "\UmbraSpaceIndustries\SoundingRockets\Parts\new 2.txt" Nosecone drag - I think you want it to be less than your other parts (in stock). Currently, despite the nosecone being shaped like a bullet, it has more drag than the booster body with fins attached causing the booster to ride into the nosecone after separation. It looks weird if nothing else. Parachute attachment point to Nosecone - I think the parachute attaches at the CoM which makes the part dangle funny if you don't have any other payload - since this isn't that big of a deal, is it easy enough to move the attachment point up a bit? It would just make it look better when falling on it's parachute. USI_DropTank Module - Oh man has this thing been grinding my gears! I reported earlier that this does not work (separate) if the booster is the root part, turns out that's the least of it's issues! I don't mind that it separates from root. BUT, it works so inconsistently! There must be some fluke bug with it or perhaps you can enlighten me. In order to test the drag of many parts with the intent to compare them to the drag I was adding to Sounding Rockets (to balance it with others), I added the USI_Droptank module to the RT-10 Solid Booster. At first this worked wonderfully! I saw separations of payloads in a nice consistent manner. Every now and then it would fail and relaunching would see it work perfectly again so only a small amount of time wasted. I'm not certain, but perhaps the update to 0.1.1 (with the USI update in it) exacerbated this issue because suddenly I've launched rocket after rocket to just see separation fail and ruin the nice clean test cases I was trying to get. So I'd start over. Some times with no changes it would just begin to work. Other times it would never work again. Other times I would adjust the orientation of the rocket, then back to the same position, then launch and it would suddenly work. Sometimes it would work, then I'd save, launch again and never get it to work ever again. I'm so fed up right at the moment...can you take a peak at it and see if something might be causing the action to be missed randomly? I hacked together a .dll to measure/display maximum surface velocity today in order to continue my testing that I realized was invalidated by the bug in KSP where Highest Speed Reached doesn't display anything over 750 m/s. It's working well enough but 75% of my test runs were blown up by the bug above. These other things are my observations through this testing time. Nosecone - doesn't orient itself with airflow when the parachute is not deployed, but given it's shape it sure seems like it should. I was going to look into config changes to address this but didn't get through the baseline testing. It doesn't orient itself when the parachute is deployed either but I noted above that I believe the cause of that to be the attachment point of the parachute. Fins - have you considered adding the stock parameters for winglets to the sounding rocket fins? Not control surfaces of course, but make them function like stock fins do by adding the smallest amount of lift. It's some aging stuff in the game but see the AV-T1 Winglet for an example. This is again something I was hoping to take for a spin and see how it play tested but didn't get to it. As you know the fins job is to provide stabilizing forces through drag and lift. And currently they stabilize but have no lift and have less drag than the Nosecone. Booster TWR - did you get a chance to compare this to stock? I was going to take a peak but didn't get a chance. Nosecone - while I love how tiny it is, the more I've played with it the more I think it might be slightly too light considering it's a tier 0 part and has a lot inside of it. Thoughts? breaking forces - I wondered if adjusting the breaking force/torque on the Sounding Rocket parts would be a decent nerfing method to prevent them from being used to bring larger payloads to orbit. Given they're made of cardboard this seems to make sense and the description could be improved to tell the player to lower their expectations of what cardboard tubes can support. Had you already looked into this? Booster fairings - I didn't get to test this but it appeared the fairing weight was higher than the booster's dry weight? I didn't test to see exactly how the fairing mass is applied...for all I know it isn't and thus doesn't matter. Booster Isp - for what it's worth I think you should have atmospheric and vacuum at least a little different - for realism, for fit with the other boosters, and other reasons too. Anyway, I've been having fun with Sounding Rockets (I think) but I seem to have gotten caught up in improving it in a small way only to discover so many things that probably need to be improved as well! I'd just like to get unstuck by finding how to get FAR to not blow up on the NoseCone and the DropTank module to work more reliably! Thanks for reading and the fun mods! -Talon

OMG It's Christmas! =) Thank you!!

Thanks for the info; It's interesting that I haven't seen the NRE issue (not that I've been looking) but it happens every time with those reproduction steps. I do have a suspicion that it could be the parachute + rootpart. Squad parachute models cannot be root parts. If it's KSP causing the root part transform to muck up, does it normally happen all the time? Does Squad already have reproduction steps? I'm always game for reporting issues with the right reproduction steps to the right people but I suppose I don't know what I'm dealing with here. Any by ideas on issue 1? Where the Flight GUI won't open when using that specific part? Perhaps related to that other known issue where it isn't opening? This silly Nosecone is killing me. :-(

I'm also hitting what I think might be a real issue - I can reproduce it, but I haven't been able to narrow it down to FAR + Stock yet. Sounding Rockets is definitely involved. It is a two part thing: 1) With Sounding Rockets (and specifically the Nosecone I've been messing around with as seen in my previous posts) the FAR Flight GUI will not appear if that Nosecone is equipped - I was going to try to find out if I can get this to happen with other parts as well but so far I haven't succeeded so it may be specific to that Nosecone part for some reason... Any guesses? 2) When I add the FARBasicDragModelmodule to the Nosecone part the drag works as I would hope - BUT as soon as I crash the rocket and revert flight to launch - the log fills with NullRefExceptions. I can launch again but the drag seems messed up. Perhaps related to #1 since I can't get it to happen on a stock part yet. If anyone wants to reproduce, here is a package containing logs of me reproducing it, the specific part for Sounding Rockets along with it's supporting DLL. My steps to reproduce are as follows: Launch KSP - Dump the ModuleManager logs for reference - Bring up Debug output to watch for NullRefs Create new Sandbox game - Go directly to Launch Pad loading Test07b (Stock) Note - FAR Flight GUI is unresponsive (does not display) Launch rocket - wait for it to crash with no further stages executed - Impact water - Revert to launch Note - if FARBasicDragModel has been added to Nosecone, NullRefs now appear in Debug - otherwise no NullRefs Note - FAR Flight GUI is unresponsive (does not display) Launch rocket - wait for it to crash with no further stages executed Note - Debug log is filling with NullRef exceptions Note - Right clicking on Nosecone part shows no drag or FAR values are applied (all are zero in flight) Impact water - Exit game 1st Zip - Logs and all files to reproduce WITHOUT applying FARBasicDragModel - This will reproduce Issue 1 but not Issue 2: Test SR Nosecone1 - FAR Flight GUI Fail.zip 2nd Zip - Logs and all files to reproduce WITH FARBasicDragModel applied - This will reproduce BOTH Issue 1 and Issue 2: Test SR Nosecone2 with BasicDragModel Applied.zip Note first NullReferenceExcpetion is: NullReferenceException at (wrapper managed-to-native) UnityEngine.Transform:INTERNAL_CALL_TransformDirection (UnityEngine.Transform,UnityEngine.Vector3&) at UnityEngine.Transform.TransformDirection (Vector3 direction) [0x00000] in <filename unknown>:0 at ferram4.FARBasicDragModel.RunDragCalculation (Vector3d velocity, Double MachNumber, Double rho) [0x00000] in <filename unknown>:0 at ferram4.FARBasicDragModel.FixedUpdate () [0x00000] in <filename unknown>:0

@ferram: This sounds perfect, I wasn't aware of the feature. I will figure that out and give it a try. One concern I have is that I have previously removed the parachute module and loaded it in game to discover that the model is then in the game with the chute partially deployed. Which I think I recall might be exactly why FAR doesn't automatically attempt to model drag of parachute parts... But I'm going to try a few things and see what I can come up with. "why is [The Nosecone/Probe/Parachute] being detached from the lower booster anyway?" - This is a feature of Sounding Rockets boosters. The purpose of which (I believe) is to make staged sounding rockets at Tier 0 Career availible without providing staging to the other more powerful rocket parts at that stage of the game. An interesting idea imo - not sure it isn't exploitable but no worries on my end.

To cut through some of my windy posts - These are the FAR Configs I am currently testing - you can test them too! [WIP]FAR ModuleManager Configs for Sounding Rockets v0.0.1.0: FAR ModuleManager Configs.zip I think they can be improved, specifically the Nosecone drag. I don't understand those parameters for FARDragModel, I just copied some. TODOs - Nosecone performance is realistic & balanced with other command pods - In Testing Ferram suggests: "Load [the Nosecone] up in-game without the parachute module on, then dump the drag configs." - Did this and updated download They should not change anything unless FAR is installed - Not tested I would like it to work with NEAR - Not attempted or tested I'm confident in the fin changes - double check my measurements for FAR? make sure I didn't copy and paste or math error? Update: New download with better Nosecone drag config - I like the performance well enough but haven't been able to test much since with this change something gets really upset and upon Reverting to Launch I get a steam of NullRef Exceptions and FAR drag seems to be mucked up at that point. I haven't been able to pinpoint it yet. It so far *seems* specific to the Nosecone part. Which...I cannot get the FAR Menu to open in-flight when that part is equipped so that seems likely. What I don't understand is why that would be the case. Documented issue here: http://forum.kerbalspaceprogram.com/threads/20451-0-90-Ferram-Aerospace-Research-v0-14-5-1-12-19-14?p=1627099&viewfull=1#post1627099

Grrr - Christmas is ruined because I just now realized/found out that in the "Flight Results" window (comes up after crashing a flight or if you press F3 while in flight) that lists "Highest Speed Achieved" tends to max out at 750 m/s. Frustrating since I didn't catch it while testing - the results that are over 750 m/s are from cases where I couldn't/didn't use the Flight Results window, the ones that list values around 750 m/s are probably wrong.

After some controlled testing I have not been able to reproduced - at least in the case of my issue I'm considering it a fluke. And if it happens again I'll have a new angle to test and report in then.

Seeing your edit, yeah, take a look at that data and let me know if it makes any sense. I've saved each Test (Test01, Test02, Test03) as a separate .craft so you can tweak settings/configs and load the craft(s), fire, write down the results. Nice and controlled. Have at those here if you'd like (perhaps more tests to come later): https://www.dropbox.com/s/w1yp64bxhv9iapk/SoundingRocketsFarCraftTests.zip?dl=0 Also you saw the link for the ModuleManager.cfg I already made? Give that a try it makes a pretty big difference already. FWIW, I follow this https://github.com/ferram4/Ferram-Aerospace-Research/wiki/Deriving-FAR-values-for-a-wing-using-Blender-2.7 to add the FAR values to the fins. This leaves me really confident that those are correct BUT it would be awesome for someone to look over the results and see if I messed up anything. Despite feeling good about the fins, I don't think they're the major problem. That Nosecone is the issue. Since it has a parachute FAR eliminates all the drag except when it's deployed (in fact, even when deployed it may just be using the stock drag model). You can see what I did in the config (which actually has a typo for the "BEFOR" statement - should correct that first!) and perhaps more importantly I asked if Ferram could perhaps explain those values a bit more and how to determine what they should be for a part like this - post here: http://forum.kerbalspaceprogram.com/threads/20451-0-90-Ferram-Aerospace-Research-v0-14-5-1-12-19-14?p=1623648&viewfull=1#post1623648 So once that's all done right I'd like to re-compare stock performance of tier 0 sounding rockets (and stock parts) to tier 0 with FAR installed. We could surely be concerned about thrust, mass, Isp if we want...but from my perspective we don't know if it's really that big of a deal until we get the drag working correctly. In general I'd rather not change the thrust/mass just for FAR...because once we do that we might as well adjust the thrust for all the other engines in FAR as well and that's just out of scope here. :-) Thanks for offering the help - feel free to PM me or leave questions here - I'm anxious to know what you make of it all!

- I think I was experiencing something similar last night Kolago and I didn't get a chance to find out if it was more than a fluke. Happened right after I updated to ModuleManager.2.5.6 as well so that's my suspicion. I was going to try a clean slate and see if it's reproducible and fixable by reverting to ModuleManager 2.5.4 or not.

Hey Ferram, can you tell me more about how to configure a FARBasicDragModel Module? The readme shows this: Other Drag (not normally needed; only for very strange objects)--------------------------- ``` MODULE { name = FARBasicDragModel S = 1 //Surface Area CdCurve //Drag coefficient at various angles { key = -1 0 //backwards key = 0 0.3 //sideways key = 1.0 0 //forwards } ClPotentialCurve { key = -1 0 //Lift coefficient, decreases with Mach number key = -0.5 -0.03 key = 0 0 key = 0.5 0.03 key = 1 0 } ClViscuousCurve { key = -1 0 //Lift coefficient, remains nearly constant with Mach number key = -0.5 -0.2 key = 0 0 key = 0.5 0.2 key = 1 0 } CmCurve //Moment coefficient { key = -1 0 key = -0.5 -0.01 //keeping angle and moment signs the same results in pitch instability; it will try to flip over key = 0 0 //making them opposite signs results in pitch stability; it will try to angle fully forward key = 0.5 0.01 key = 1 0 } localUpVector = 0,1,0 //a unit vector defining "up" for this part; 0,1,0 is standard for most stock-compliant parts localForwardVector = 1,0,0 //a unti vector defining "forward" for this part; 1,0,0 is standard for most stock-compliant parts majorMinorAxisRatio = 1 //the ratio of the part's "forward" length to its "side" length, used for drag and lift calculations cosCutoffAngle = 0 //cosine of the angle used to determine which side of the part is tapering for hypersonic drag calculations. Use sign to specify which side taperCrossSectionAreaRatio = 0; //the part's tapered area projected on a plane normal to the "up" vector, divided by surface area; used to handle changes in drag at hypersonic speeds CenterOfDrag = 0,0,0 //a vector defining the part's CoD } ``` For both of these, set MaxDrag and MinDrag to 0 Specifically I'm trying to add drag to this part of Sounding Rockets which is a Nose Cone, Command Module, AND a Parachute. The result of which is that this often flown solo part has no drag applied to it causing it to accelerate under gravity to speeds no one wants to open a parachute at! I copied this block from FerramAerospaceResearch.cfg and applied it to the PART[sR_NoseCone] via config and it's working I think...but what would be the RIGHT way to apply drag with the right values? I suppose this will muck up the drag when the parachute is deployed? @PART[SR_NoseCone]:BEFORE[FerramAerospaceResearch]:NEEDS[FerramAerospaceResearch|NEAR]{ MODULE { name = FARBasicDragModel S = 0.254 CdCurve //Drag coefficient at various angles { key = -1 0 //backwards key = 1.0 0 //forwards } ClCurve { key = -1 0 //Lift coefficient key = 1 0 } CmCurve //Moment coefficient { key = -1 0 key = 1 0 } } }

@PDelta - Can we team up on this? See my post with data regarding performance of at least one of the stock boosters. I'd be happy to provide more AND provide some testing. Note that the biggest problem that would make this better inline with stock is if the Command/Parachute Nosecone actually had some drag. Currently it has zero drag and this makes it fly infinitely faster when accelerated by gravity. @RoverDude - I'm always a fan of tweaking TWR. :-) But am I hearing you correctly that you wouldn't be interested in putting the FAR Modules into the configs of your download? Or alternatively providing ModuleManager configs (that would only be applied IF/WHEN FAR/NEAR was installed) as part of the Sounding Rockets package? I would really like to urge you to consider differently; currently it is accurate to say that Sounding Rockets does not work well/correctly with FAR specifically because the Nosecone part has Zero Drag applied to it in FAR. This is fixable with configs that I, and I presume others, would be happy to create and test. These configs (with the ModuleManager option) wouldn't even be in the stock configs or otherwise conflicting with the stock game (in either option). It seems a lot of people in the thread would desire this, and the primary cause for concern is a broken physics issue (no drag on the return capsule), which is fixable as I demonstrated. I'll leave it at that, thanks for hearing out my two-cents. In the meantime do you have any concern with me posting links to ModuleManager configs that allow Sounding Rockets to work with FAR without this zero drag issue? -Talon

I too have been loving Sounding Rockets! Or at least the concept of having the option of unmanned test flights for the early career! Unfortunately, as we all already know, FAR is also wonderful and tends to really mess with the early game quite a bit. But with that said, I became interested enough to investigate what would be realistic performance within FAR for the Sounding Rockets. One thing I did first was read a lot of wikipedia about Sounding Rockets and early rocket tests. It turns out, that for a test rocket to reach high altitudes isn't/wasn't all that unrealistic. It makes sense (and RoverDude has been telling us this in several posts) that having small unmanned rockets, with little care about their potential fiery doom, leaves a lot of room for high altitude sub-orbital test flights. ESPECIALLY multi-stage sounding rockets. In our real rocket history, test flights of Sounding Rockets reached apoapsis altitudes of over 200 km fairly early. If you consider the V2 as one of the earliest real rockets (which it was), note that in a vertical launch, it could reach a maximum altitude of 206 KM. Sounding Rocket performance over the next 10 years followed suit and some tests far exceeded this altitude. This history of rocket flights might be interesting to you, I know it was an enjoyable learning moment for me! https://en.wikipedia.org/wiki/Timeline_of_spaceflight I was also worried that in career the early missions speak of altitude records. And It seemed a bit cheaty if these tiny rockets would immediately set a record on the first flight that invalidated many future contracts for altitude record setting. But as noted already in this thread, those contracts require a manned flight. Perfect! Now FAR is known to eliminate the atmospheric soup while also rewarding aerodynamic design, which when combined makes it much easier to launch a rocket through the atmosphere. Mods such as Ferram's KIDS (KerbalIspDifficultyScaler) can counter this but it may not be for everyone. What about other concerns such as parachutes not getting a FAR drag model? And the drag created by the fins requiring a wing config in FAR to be modeled with the correct drag? Do those things matter to users of Sounding Rockets who want to use FAR? I compiled to following data from tests to find out: https://docs.google.com/spreadsheets/d/1K9UVrXre7bIuG8vGBbowGKdB5ZK6XZxiga1wa1N4vmM/edit?usp=sharing (not yet complete) Looking at the data, I'm going to go ahead and propose that either Ferram misspoke or there was a miscommunication... The short of it can be summed up with this series of tests: (Stock) Launching East at 40 deg off horizon - basic Sounding Rocket - Peak Altitude: 1,425 m - Speed at Impact: 83.6 m/s ( FAR ) Launching East at 40 deg off horizon - basic Sounding Rocket - Peak Altitude: 12,770 m - Speed at Impact: 1,363.8 m/s (Identical booster/setup to test above) (Stock) Launching East at 40 deg off horizon - stock fins & probe - Peak Altitude: 972 m - Speed at Impact: 94.7 m/s ( FAR ) Launching East at 40 deg off horizon - stock fins & probe - Peak Altitude: 1,306 m - Speed at Impact: 40.4 m/s So we can conclude that FAR doesn't HAVE to drive performance into the OP spectrum... WHY does it do so for Sounding Rockets? I think the CommandPod Parachute is the PRIMARY factor but perhaps the fins not having FAR Aero on them also factors in. I made some FAR configs to fix the fins and (happy to share but they aren't complete - I'm not smart enough) and tested again: (Fixes) Launching East at 40 deg off horizon - basic Sounding Rocket - Peak Altitude: 5,546 m - Speed at Impact: 136.5 m/s Not bad! ...but I have more questions than answers it seems. I'm getting some NullRefExceptions in the logs all the sudden (when reverting to launch). I actually am shocked that the Stayputnik slows to 40.4 m/s in a free fall descent causing me to question what drag is being applied. And I'm using Ferram's FARBasicDragModel Module to apply drag to the Nosecone but am at a total loss for what the values in that module actually mean (I copied some values Ferram is applying to a FASA part). So...more testing to do and I'd welcome some help figuring out the right values to put on parts. I do feel pretty good about the fins...I just don't know how it actually impacts things. [WIP]FAR ModuleManager Configs: https://www.dropbox.com/s/6kgtqncsyxuui3a/FAR%20ModuleManager%20Configs.zip?dl=0 Eager to hear your thoughts! Unrelated...would you consider it a bug that the booster does not jettison itself from the payload if the booster is the root part? I had to set the nosecone as the root part to jettison. It helped me test the drag while falling back to Kerbin by having all the parts still together but I'm not sure that's intended behavior so I thought I would share. -Talon

You need to double click on the zip file, not the py file. Solved everything - THANKS!