ferram4

Um... that's not supposed to happen. I'll look into it; the control surfaces probably have the wrong multiplier somewhere. Thanks for the pic with it; helps make things a lot clearer.

@liptaden: Well, yeah. It loses thrust, dropping to zero at around Mach 1. He's really close to the ground, so his top speed will be limited by the atmosphere (particularly since engine thrust doesn't drop off with a decrease in altitude).

@hyperionxl: Yeah, it's really difficult to do. Here's an album of a Soyuz-like mission I did, using the FAR to Real Life, adjusted setting; take note of how large the launch vehicle is compared to the orbiter. If you dispense with the orbital module you should be able to cut down the fuel requirements a little bit. @Miller: Modular Fuels involves changes to tank mass, fuel density, and some Isp changes (I think) to try and make things a bit closer to real life. This mod simply universally scales Isps (primarily) to make things as difficult as you choose. This mod also allows you to have different presets, so that you can have one save where things are ultra-realistic in terms of rocket mass needed to get anywhere and another save where things aren't changed at all. @jpinard: You can try using the FAR to Stock KSP settings, which will make getting to orbit as difficult as it is in stock KSP; the universal one will be less punishing in atmospheres, but will require more dV for orbital maneuvers; the atmosphere only one won't punish you in space, but will make flying deep int he atmosphere very painful. If you'd prefer it to be a little harder than that, you can simply add a new preset that makes things a little bit harder than either of those.

@icecubecookie: Try switching out firespitter parts one-by-one to see if that is an issue; there might be a bug with one of them.

One correction I'd like to make: the 48-7S got a thrust bump and now has a TWR of ~30, making it a superior lifting engine to the Mainsail. I think an interesting thing to look at for comparisons is to calculate the structure ratio and payload ratio for each booster and see how it compares to real life. e = m_structure / (m_structure + m_fuel); structure ratio m_structure = m_drytanks + m_decouplers + m_engines + ... + m_all_other_not_fuel p = m_payload / (m_structure + m_fuel); payload ratio m_payload = m_everything_remaining_in_rocket_after_booster_is_decoupled For a realistic rocket design, these numbers should end up being the same in real life and KSP and would provide a good sanity check for the calculations.

@MAKC: Go with NathanKell's numbers, I think. That should be close enough. @NathanKell: I'm tempted to do that, but then we'll get the fun of rockets that will have similar Isp at the surface and in vacuum, so that might be a problem (particularly for aerospikes). I can do some math out and see if I can find a scalar that makes sense in the context that Isps in atmosphere should be lower than in vacuum by a noticeable amount.

That's correct. You're using the basic jet engine, which loses thrust quickly as velocity increases. It's intended for use on craft that aren't going to be flying much faster than Mach 0.7, 0.8; you should be able to get that up to a decent speed if you fly higher, where the atmosphere is less dense so that the thrust is better at moving it.

@icecubecookie: Make sure that your wings aren't flexing in weird ways; that might cause some of the problems. Another possibility is that (based on where your landing gear is) you're getting some stalling to occur just as you take off, which shifts the CoL around; try moving the landing gear so that it doesn't have such a high angle of attack on the runway and get some more speed before taking off. @Raven Coldheart: Nope, no ground effect; that's just the difference in atmospheric density. @Nathan Kell & Taverius: Another problem with putting fuel in wings is that you'll get the fun of the wings drooping under the fuel weight since the surface attach joints are so flexible.

Or alternatively, the continual increase in the number of parts available in the stock game means that new players have a much harder time figuring out what to do at first, which discourages new players from sticking with it in the first place. Hardcore players are formed when you take a player, show them something difficult, but make it clear that there is a way to accomplish that goal. The current tech tree strips out all of the initially superfluous structural parts so that it is more clear to a new player how to accomplish their goals. I'd love to see more people using FAR or KIDS, but the only people who will stick with the game long enough to try those mods are the ones that don't get overwhelmed with the huge amount of parts when they go into the VAB are stuck sitting there asking "what do I do with all of this?" Career mode clears that up by suggesting (and only doing it through the parts available), "Maybe you should just strap this SRB to the bottom of a Mk1 pod and see what happens." Don't make the mistake of thinking that players are born into being "naive, stupid, filthy casuals"* and "ultra, leet, MLG-pro, hardcore players;"* one can easily become the other given enough time to become familiar with the game mechanics and what works and what doesn't. Don't make the mistake of thinking that a tutorial (and that is what the tech tree is) has to challenge a hardcore player. *Note: mocking the perception of each

Your vertical tails are a little close together; one of the common causes of roll instability is actually a lack of sufficient yaw stability: this is because lower yaw stability allows more sideslip; more sideslip increases sweep on one wing and decreases it on another; more-swept wing makes less lift than less-swept wing; plane rolls like crazy. Another possibility is just unequal flexing in the wings, which is caused by a known joint bug; make sure that the parts are strutted to each other well and to the fuselage well to counteract that. If the roll instability isn't prominent in supersonic flight, try making the plane more pitch-stable and see if that counteracts the roll problems; it might just be pitch instability combined with wing flexing. Consider placing an empty structural fuselage piece in front of your fuel tanks; this will help make the plane more stable as fuel burns by adding more dry mass in front of the fuel tanks, which will help offset the high dry mass at the back due to the SABREs. Alternatively, consider mounting the engines at the wing tips / wing root, similar to the Skylon designs; this will help balance fuel flow, which will prevent you from having to transfer fuel forward during absurd aerobraking.

Yeah, that would work. I'll switch the Isp adjustment system over to using a "CorrectKeys()" method and I'll look into trying to get MFSC to work. I already have an exception to the thrust corrector for jet engines, so it shouldn't be difficult to rig it up to handle MFSC engines as well. I'll look into adding it tomorrow.

Version 1.2 is out, which moves the button to the top right corner of the space center screen so it doesn't conflict with Lazor, accounts for more-complex-than-stock-rocket-engine Isp curves, exempts jet engines from the thrust corrector for balance reasons, and tweaks the default presets.

@MedievalNerd: Noted; I'll move the button somewhere else, probably the top right corner. @Touhou: The "to real life" versions are "realistic" in the sense that getting from the launch pad to orbit requires realistic amounts of fuel. Since the delta V requirements are so low, it nerfs the Isps so that realistic mass ratios are necessary to reach orbit. Basically, it's intended to making SSTO possible, but only if you use a ton of fuel to do it. @a.g.: Yeah, I set the thrust cutoff to 300kN by default rather than 200kN like I intended; that's been fixed in my build now. I also successfully fixed the "losing Isp data" problem, but it may fail on modded engines with absurdly complicated Isp curves, primarily because I can't access the actual points in a FloatCurve (which is very frustrating) so I have to use a limited number of points to avoid swallowing RAM like crazy. Also, jet engines won't be thrust-corrected, since it results in dramatic changes in thrust that don't seem to make any logical sense (at least to me; I don't think that engine thrust should double because you went up a few km).

That would mess up jet engines... ok. I'll fix it.

Not currently; I'll look into adding support for the B9 SABRE engines when NathanKell gets his updated version of ModuleFuels up. Some legacy ModuleFuels engine code is very similar to the module used by the B9 engines, so I should be able to add support for those at the same time.

Have you tried the solution in the FAQ? Delete config.xml and then run KSP?

@Diazo: Aware of that, though I'm not exactly sure what is causing it to be honest.

@Diazo: Found the bug and squished it; fix will be in next release. @velusip: It can add the same exact effects as Arcturus Thrust Corrector if you shut off the "Isp Cutoff" and "Thrust Cutoff" options, which will cause every engine to produce its rated thrust in vacuum, and less in atmosphere. The cutoffs are simply so you can add some real-world sanity to the function: why would the Mainsail (a heavy lift engine) be rated in vacuum? It would be rated for 1 atm since you'd care more about how much it can lift at takeoff than you would about how it does in space.

So the consensus here is that if only FAR would maintain the current delta-V requirements (and hence, drag characteristics) for an "ideal" rocket, everything would be fine. For most of our cases, the Kerbal X would be rather close to ideal; Sean Mirrsen's SRB stack is also fairly "good," in terms of having a high fineness ratio (length / diameter) and a lack of sudden changes in cross-section across the length, with the only significant problems being the lack of a nosecone to smooth out the drag at the top. And then the consensus seems to be that the standard asparagus monsters and wide-bodied pizza rockets should somehow have even higher drag. My problem with this is that an increase in atmospheric density / increase in drag coefficients to keep the delta-V requirements will reintroduce the requirement of a 10km vertical climb before any type of pitch over maneuver can be considered, which is not necessary with FAR's current drag characteristics, since it is possible to begin a gravity turn under 1km up and still reach orbit. I honestly do not understand the gameplay benefits that would come from reintroducing this vertical climb, since I have always taken it as an opportunity to leave SAS in control of my rocket while I get a drink. If someone can honestly explain the gameplay benefits inherent in reintroducing that (IMO boring) segment of launch (which will be a necessary consequence of increasing atmospheric density / increasing drag coefficients), I'll look into adding a switch so that FAR can increase density for the people who want it. I simply don't understand what benefits would come from that that wouldn't be better served by rescaling Isps; the delta-V requirements might drop, but with lowered Isps the same size rocket would be required to get to orbit.

While I understand the reasoning behind increasing the atmospheric density, I myself have always thought of that as the single worst part of stock KSP The worst of part of rocket launches (for me at least) was always the 10km straight climb, which would come back with that higher atmospheric density; I can't be the only one who hated it with a passion. Yes, it does add a measure of difficulty to launches by requiring a specific flight path and adding more delta-V requirements, but when the source of the difficulty is so in-your-face obnoxious every single launch you become aware of just how arbitrary it is; a player who is aware that he is fighting through a stupidly thick atmosphere simply so that it is harder to reach orbit isn't going to have much fun. I switched to MechJeb when it came out solely to get out of doing that boring part of the game and get to the fun space maneuvering. Yes, the nerfed-to-hell Isps are arbitrary, but you don't spend an entire minute every launch having the lowness of the number mashed into your face like you do with the high density atmosphere. Then there are the unintended consequences for FAR users, which would include: Rockets will flip more easily or go full lawn dart (depending on their stability), depending on how stable the rocket is and how much the engine gimballing can counteract the increased forces; this gets worse with larger rockets that may flex significantly at liftoff and would have to be corrected incredibly quickly. Planes suddenly need a lot less wing to get in the air. Larger, quickly varying aerodynamic forces cause really nasty things to happen at higher timewarps / higher velocities, making the simulation less stable and the game less fun. Finally, this doesn't leave me the option to make the game even more difficult, since I like to make things more difficult. With that in mind, version 1.1 is out, which includes a thrust corrector, making Arcturus Thrust Corrector obsolete. When the thrust corrector is active, engines can either be vac-rated (makes rated thrust in vacuum) or atm-rated (makes rated thrust on the pad); by default engines with unscaled Isps below 385 s and max thrusts above 300 kN will be atm-rated; all others will be vac-rated.

@TomatoSoup: FAR has not regenerated a config.xml in your KSP install? Make sure that KSP has the proper permissions so that the OS doesn't interfere with it. @Sochin: Wingtips are more affected by the trailing vortex system than the wing roots are, and that vortex system is where the majority of drag comes from. Winglets increase the lift to drag ratio by (1) taking advantage of the change in the local velocity vector to create a small lift force that is oriented such that it cancels a small portion of the wing's drag and (2) increasing the span of the wing so that while the winglet part suffers from more drag than the rest of the wing parts, the aggregate makes less drag.

@TomatoSoup: Make sure that you clear out the config.xml file that I've specified; it might be that the GUI is offscreen permanently and FAR will need to rebuild the config for things to work properly. @Galacticruler: Based on what you're telling me, this isn't a problem only FAR causes. This is the result of KSP running out of addressable memory; FAR is a little RAM intensive (to save on the processor) but you'd have the same problem if you're using too much of other mods. Based on the other things that you've said and the memory issue, it sounds like you have very little RAM on your PC or there is a lot of software hogging it; all of the problems you've said you're having make sense in the context of KSP using the page file to the fullest extent (which should mean that your HDD is thrashing like crazy) and everything is held up by the speed that you can transfer data to and from the HDD.

@rosenkrantz & dlrk: Should be fixed now; just re-download. Delete the config.xml in your GameData/FerramAerospaceResearch/Plugins/PluginData/FerramAerospaceResearch to make sure that things can restart properly. @GalacticRuler: That's a new one. Make sure that you're running the new KSP 0.22 and the latest version of FAR. What other mods are you using? Can you post an output_log.txt from when that crash was caused?

Well, it depends on what setting you're using, but you shouldn't need 5 mainsails and 4 big SRBs to get going. O_O For context, I have a Soyuz-U style rocket that puts a Soyuz-like thing in orbit with the FAR to Real Life, Adjusted. There are 5 mainsails at the bottom, each moving ~2.5 orange tanks of fuel, so much, much more than you've got going on. Thanks for confirming that Arcturus is incompatible to the extreme with this. I'll add my version of the thrust corrector post-haste with some code to detect if Arcturus is installed and to inform the user of the incompatibility so that other people don't have to suffer.

Looking more closely at Arcturus' source code, it looks like the only way for KIDS to properly function with it is for KIDS to load then Arcturus to load; the opposite will lead to engines making much, much less thrust, even in orbit (which might be the source of CoriW's problems). With that in mind, I'm going to implement an Isp-thrust-corrector feature in KIDS so that the order of operations can be handled properly. I'll also add an option to choose whether the rated thrust is for vacuum or sea level (with a selectable vac Isp cutoff for each one, i.e. vac Isp >380, rated thrust = thrust in vac, vac Isp <380, rated thrust = thrust at sea level). That should help with the lower thrust problems. @MAKC: If you'd like that, do this using ModuleManager: Go through each fuel tank, cut the dry mass in half and add that back in fuel mass. For each engine, cut engine mass in half, multiply engine thrust by ~1.5. Everything else should be about right where it is. Use real life raw. I'm not coding in any boosts to engine thrust (other than the pressure they're rated at) primarily because that strikes me as more of a design problem than anything else; you can always surface attach fuel tanks to the bottom of a stack and use fuel lines to make sure that they keep firing if you need more engines.