ferram4

@iornfence: Setting the shockwave exponent to 1.17 is for real-life-level heating on stock-sized Kerbin. Reset it back to 1 and you will have proper temperatures for RSS.

Well, let's do out the math, shall we? T = 2À * sqrt(a3 / μ) where μ = 398600 km3 / s2 for earth. So let's say your periapsis is at 100 km; you're taking a very shallow trajectory to minimize your dV. So that gives us a semimajor axis of: a = (6378 km) * 2 + (100 km) + (35,786 km) a = 48642 km. Working through the math, it will take you: T = 106,764.86 seconds to complete an orbit, so the time we're after is: t = 53,382.43 seconds. How many revolutions does Earth make in 53,382.43 seconds? Well, it's sidereal day is 86,164.1 seconds. This means that Earth will complete 0.6195 of a full rotation. Given that there are 360 degrees latitude, that means that if you burn at 0 degrees, when you reach apoapsis 223.02 degrees latitude will be under your periapsis. Since apoapsis is on the other side of the planet, 43.02 degrees latitude will be under your apoapsis. If you set your periapsis to be higher, then it will take longer to reach apoapsis, which means that Earth will rotate more. So your answer is that you'll probably end up somewhere around 43 - 50 degrees east of your periapsis burn location.

Oh, that's for the flap settings; I have them set to that automatically. I'll simply change it so they don't get set to defaults then and anyone who wants to use flaps will have to manually set their action groups. I'll have to see if the action can be unavailable if the control surface isn't configured to be a flap.

@Camacha: I was referring to the fact that my only uses of kOS were in conjunction with the Real Solar System mod, which means that if kOS' author made any assumptions about Kerbin being a certain size that might adversely affect the outcome. @ExEvolution: First, you're using the old version of FAR; v0.10 makes pods much more stable during reentry. Second, the reason that the CoL looks like that is because just showing the direction of "lift" or "drag" at any orientation is garbage for stability purposes, since a slight change in orientation could change the amount of lift or drag drastically. Instead, FAR makes the CoL display the direction and location of the additional force that would be added if you pitch up the vehicle just slightly; the stock CoL indicator is far more like a Center of Pressure indicator, which is not useful at all for calculating the stability of a vehicle.

A simpler way to do it would be a pair of radial decouplers and you only decouple one. I honestly don't want to have the CoM offset as a standard thing with FAR, since that will mess up so many people's crafts; you really need to design the orbital module below it to counteract the offset, and the optimal offset depends heavily on what's attached to the pod, otherwise it can tip too much and parachutes can get burned off. Of course, once you start designing things to be offset, there's no reason to stick with traditional symmetry anymore:

@iVG: The reason your g loads are so high is because you're doing a ballistic reentry, as opposed to a lifting reentry; honestly, I'm surprised you could bring the gs down to 7.3. Soyuz, Apollo and pretty much any capsule more advanced than "can with human in it" has a slightly offset center of mass and does a lifting reentry. The current released version of FAR makes it difficult, but in my testing version, having put the mk1-2 capsule CoM offset by ~5cm, I was able to achieve this: G-force maxed at about 4, mostly hands-off reentry. The offset CoM will be something players will have to add themselves, but the next version of FAR will make doing these reentries very easy. As a note, the fuel fraction is because FAR thinks that ablative shielding is a type of fuel. I'll have to fix that.

@KerbMav: I'm going to admit that I don't quite understand what you're asking for. What do you mean by "AG setting?" @Traches: What do you mean that you don't need to see down to seconds of an arc? I'll limit degree settings to 1 decimal place and see if it would be too bad to add comma separators. @Frederf: Well, you have been avoiding extreme aerodynamic stresses and stability issues. @Camacha: You can use the drag coefficient and reference area in the Flight Data readout; it'll change a little bit based on angle of attack and Mach number, but that's the best measure of aerodynamic efficiency. I have noticed that with RSS kOS doesn't seem to pitch down enough for surface velocity, but I think that might have to do with the control system itself. @123nick: It's easy to tell if a winglet is compatible with FAR or not; most mods advertise their compatibility. Writing something to automatically get the proper wing parameters is something that I have planned, but it's difficult to make it work consistently and reliably.

LH2/LOX is very good for getting the most dV out of the mass of your upper stages. Let's say that you're launching two versions of a two-stage rocket, one with RP-1/LOX fueling both stages, the other with a LH2/LOX upper stage. Assuming both upper stages are the same percentage fuel by mass, here's how things compare for the upper stage, depending on the engine you use: RP-1/LOX Isp: 320s - 380s LH2/LOX Isp: 410s - 470s The ranges are based on whether you use a vacuum-optimized or a atm-optimized engine. For the atm-optimized engines, you gain 28% more dV by using LH2/LOX; for vacuum-optimized, you gain 23% more dV. If for some reason you need to use an atm-optimized LH2/LOX engine for your upper stage, but you can use a vacuum-optimized RP-1/LOX engine due to TWR requirements, you still gain 7.8% more dV. An alternative to increasing dV is that you can reduce the mass of the upper stage while maintaining the same dV. That might allow you to use a smaller, more efficient lower stage engine, boosting the dV of that stage. Or you could get rid of SRBs that you needed to get it going. Or you can split the difference and launch a slightly larger payload to orbit, taking advantage of the slightly lower mass of the upper stage to pile more on top of it. If you're using FAR there's the added benefit that LH2/LOX is less dense than most of the payloads you'd be sending up, while RP-1/LOX is denser, which means that RP-1/LOX rockets will be less stable than LH2/LOX rockets. Ultimately, LH2/LOX is unwieldy, but it allows you to do more with less, which is quite dramatic when you consider that mass increases exponentially with increasing dV.

@StarWaster: FAR should detect the orientation of the shape; if nothing else it will put the higher drag part near the bottom which is less bad than what you had going on. I admit to not knowing anything about MechJeb ascent profiles, especially since I run mine based on velocity targets rather than altitude targets until I'm already above the atmosphere and at about 4 km/s. Odds are that starting at 10 km is too high; try instead around ~1 km and see if that helps.

SAS will override any of FAR's control systems, so if you have SAS on while you're using the built-in control systems it will be as if those systems aren't on. The reason that SAS is freaking out is because you have too many control surfaces capable of rolling your plane; reduce the amount of roll control that you have and the problem should go away.

Part of the reason that things feel apart when you jettisoned the fairing is that procedural fairings autostruts the fairing bases and walls to each other, so basically the fairing was carrying the majority of the load. Ultimately, for what you're trying to launch here it would make more sense to keep the payload in the fairing until you're raising the periapsis from ~30km up to 250km, which you use a much weaker orbital engine for. The main reason it seems to have been successful is the very low TWR at launch (it looks like it's around ~1.2, based on the g-Force meter) and the fact that you took such a steep ascent, which meant that you minimized Max Q as much as possible, so... good work I guess? Honestly, if you just flip the station around the other way it will be vastly better aerodynamic-wise, even though something that wide for how tall it is is kind of... bad. Honestly, FAR should backhand it into pieces, but Kerbals are very good structural engineers; their stuff holds together through things that real life rockets can't handle, though it fails more spectacularly.

@Frederf: Believe it or not, an estimated terminal velocity readout will be coming with v0.10.1, along with ballistic coefficient. That said, unless you're reaching ~400 m/s the second you leave the pad and increasing it up to orbital velocity around 20km, you're not anywhere near it. Trust me, trying to match your rocket's terminal velocity on the way up is not something you want to try doing with FAR.

FAR is missing two gigantic features: induced velocities and local variations in dynamic pressure. Without induced velocities there are essentially no negative effects to canard designs and planes are slightly more statically pitch-stable than they should be, but are also less dynamically pitch-stable than they should be. Local variations in dynamic pressure would allow modeling deep stall for T-tail designs as well as better hypersonic modeling. Unfortunately, the only time I tried to model induced velocities in the current framework the lag went through the roof, so that basically necessitates a total recode to make things work better. SQUAD hasn't gotten in touch with me, probably because they either aren't considering how they would overhaul aerodynamics yet or because they're intending to overhaul it to be something different than what FAR is or because they're confident of their ability to code an aerodynamic model without me. They'd also have to look into a complete rebalancing of stock parts, particularly part masses, if they were to switch over to something like FAR, since it's really difficult to make properly stable rockets with the over-mass engines. I'm open to coding something like that for them, but I know that the current priority is career mode, so there's probably no chance they'd even think about overhauling aerodynamics right now.

I believe the engine propellant ratios are for mass flow, not volumetric flow, so if you know the total mass of "Oxidizer" you need then you can simply figure out what fraction of stuff is RP-1, LOX and "Oxidizer" and then you can set the engines to run on those ratios, and then multiply the mass of the "Oxidizer" by the propellant densities to figure out how many units you need in the tank. NathanKell probably knows more, since he's been dealing more with the engine code than I have. Edit: No, it wouldn't be mass flow; that would break ion engines. It has to be "volumetric" flow then. So then you just need to take the mass of "Oxidizer" you need, divide that by the propellant density to get the volume units. Then you know the amount of RP-1, LOX, and Oxidizer; add up the totals, divide each amount by the total number of units and that gives you the ratios for each one.

@Sokar408: The editor GUI will remember its position in v0.10 unless you're trying to shift it too high off of the screen where the minimize button will be hidden behind stuff. If you want to manually set it, go into the config.xml in the FerramAerospaceResearch/Plugins/PluginData folder and mess with it there. @Tharios: It's an issue with the way joints are set up; they don't have consistent strengths for some reason. Use more struts and that should minimize the issue. However, if small attempts at roll control are causing your plane to lose control then either it is only marginally stable in yaw (add more vertical tail) or you have too many roll control surfaces.

Alright, so here are the masses for the Apollo Command Module, from the wikipedia article: So the heat shield is 15% of the total mass, if we assume that the module comes down with full RCS tanks. However, the current pod doesn't have RCS ports or storage anywhere, so we have to remove that, bringing the heat shield up to 16.7% of its mass. And this is on a capsule outfitted with a docking port, science cargo (moon rocks don't weigh nothing), comm equipment and multiple parachutes. Since your design has opted to strip out most of this stuff as being superfluous, the heat shield will be an even greater percentage of the mass being brought down. I'd really like to know what source you used to get a heat shield of only 7% of the capsule's mass, because that is really, really low. You also need to keep in mind that DRE is also intended to be used with RSS and to be able to handle more... aggressive missions than you might find in real life. Sure, a fast hyperbolic entry on stock Kerbin might be lower speed than on Earth, but since Kerbin is so much smaller to actually aerocapture / aerobrake significantly you need to dip down deeper into the atmosphere, increasing the heating much more than would occur in real life.

FAR can only assign control surfaces to specific axes in the editor; it can't do it in flight, at least not right now. I could add a "disable surfaces" button for each control surface, and make them drain electric charge when the deflect to justify doing that.

AtmosphereMultiplier is for pressure; in-game density is related to pressure by density = 1.225 * pressure * (kg/m3 ) / atm.

Extras like... a docking port (0.1 tonne for shielded, 0.05 for unshielded), multiple radial chutes (0.15 tonnes each, at least 2, possibly 3 as a redundancy), and additional stuff between the pod and the docking port (kOS module, 0.12 tonnes; dry RCS tank, 0.15 tonnes; two Mystery Goo containers, 0.15 tonnes each). So let's say you go with an Apollo-style mission, with an unshielded docking port, three radial chutes and a pair of Mystery Goo containers; this means that you're bringing down 4.8 tonnes of stuff without getting to the heat shield. Now add a 1 tonne heat shield and you've got 5.8 tonnes being brought down, exactly what the Apollo capsule had.

All I can think is that your parachute is about to explode. I'll be honest, I do see heating effects on ascent with two-stage rockets, but normally those don't have any solids involved.

Then taking the Titan is a good idea; slap on a pair of long burn SRBs and it'll lift off quite nicely. The first thing to keep in mind is what altitude you're looking for; if you want realistic orbits, you're shooting for 200km-300km orbits. I've generally found that for two-stage rockets, having the velocity vector at ~35-40 degrees above the horizon at ~1500 m/s is generally good (this is due to two-stage rockets generally having higher peak accelerations than three-stage rockets, which means a flatter ascent profile with the two-stage). The thing to keep in mind is you're looking at going for ~7.7km/s of horizontal velocity in orbit, so most of your burning must be done horizontally. If your TWR is high enough at a certain point it just makes sense to burn purely horizontally, but this can kill you if your orbiter needs to circularize and it happens to be underpowered. A lot of it becomes very rocket-specific, so I'd need to know initial and burnout TWR for each stage as well as the burnout velocity for each to give you more advice. Are you using Kerbal Joint Reinforcement? If you aren't the higher masses needed might be causing you issues.

I think NovaPunch has 3.75m to excessive number of 1.25m adapters. I gather you're looking to slap multiple 2.5m engines on the bottom instead? The best option I've found is to use the KW Rocketry fuel adapters to slim it down to a 2.5m engine and then add boosters to bring the TWR up (if necessary).

@dlrk: That rocket looks like it has a very high TWR; you could probably get away with the Titan instead of the Griffon and that would solve your issues. The way that you've attached the B9 RCS tanks will probably add quite a bit of drag, and you don't need the SPS engine for that tiny orbiter; I'd actually say that a good fix would be to replace the SPS with the LV-909, put the RCS tanks under the fuel tank and use a procedural fairings interstage to shield the 909 and the RCS tanks. That should help make the upper bit of the rocket smoother and less draggy, since there's no way you should need that much fin for that rocket. @NathanKell: You can throttle back a little bit, but hovering in the transonic regime too much is a problem. Throttling back to decrease Max Q slightly makes sense, but only if you can still maintain a TWR of ~1.6 through the entire regime.

No, staying in the transonic regime for that long (which is what he'd being doing to keep the Mach number low enough) is the exact worst thing to do. That's where rockets and planes are least stable. @dlrk: The first thing to keep in mind is that a high TWR is a really bad idea; ~1.4 is good, you can go down to 1.2 if you want. The second thing is that you probably don't have enough fins or your rocket doesn't flare out enough near the bottom; this is especially true if you're running a kerolox lower stage with a hydrolox upper stage, in which case you need a lot of fins to stabilize the thing. Make sure to throttle down around Mach 0.7 and keep your throttle near ~75% until the rocket becomes easier to control; this will lessen the aerodynamic forces. Pictures of what you're trying to launch are generally helpful, since we don't know whether your launch vehicles are close to good but with some flaws or if they're completely wrong. Pitch over very slowly at 60 m/s for a TWR of ~1.4-1.5. Wait until ~100 m/s for 1.2. Altitude is whenever you hit that speed.

It should automatically detect that the parts are shielded unless you have changed the "title" field of the fairings so that "payload fairing" is not in the name. Could you show a picture of the problem craft so that I can figure out what's going on? Are you using the most recent version of FAR?