NathanKell

Ralathon: you're editing a file from my mod (RSS) and it's CC-BY-SA, so posting is fine.

Ah, but these fairings aren't only used for actual fairings, they're also used for fuselages for rockets and (air/space)planes too. Hence the desire to have fuselage textures for them.

Very easy to make compatible. Add Ablative Shielding (and reduce mass to compensate), copy the ModuleHeatShield from an appropriate DRE heatshield. Angara looks great!

When are you starting the turn? That's usually a symptom of starting it way too late. Start it when you're at less than 100m/s, which is usually 0.5-1.5km.

drtedastro: Yep! Also, check your PMs for clarification if you haven't already.

Apologies. I'm not done with MFSv4 yet. Thanksgiving week was a bad time to expect I could get lots of coding done. Zander: I will be reassessing MFS after .23 and tweakables, and I will likely move to m^3 as the units; we'll see. Ralathon: Thanks! (Though apologies for delay, per above). Firov: We'll do our best.

Yup, v6 fixes that. Regarding attach nodes. So, I promised a fix this weekend. I was wrong. Apologies. I'm not even done with MFSv4 yet. Thanksgiving week was a bad time to expect I could get lots of coding done.

Good to see this posted, with source! You still need a license though. http://forum.kerbalspaceprogram.com/threads/44738-License-Selection-Guide

9300 Earth ascent. ~3200 TLI. ~900 LOI. ~2000 DOI and landing. ~1800 ascent. ~800 TEI.

It's what you're forced to do when you have a single anemic RL-10 at <100kN pushing like 40 tons of Centaur and payload.

No, it's the exact opposite. Ferram just said if you increase scale height, you've just scaled everything, so the pressure that once was at 20km will now be at 25km, and so forth. Re: your latest: yes, intentional. It's a closer fit to Earth's actual pressure curve.

KSP has two atmosphere models: legacy and pressure curve. Pressure curve uses the same floatcurve mechanic that solar panels, engine specific impulse, velocity curve, etc., use; legacy uses an exponential equation that appears to work like this: base pressure multiplier := (e * staticPressureASL) ^ (-altitude_in_km / scaleHeight) if base pressure multiplier < 0.000001, base pressure multiplier = 0 return base pressure multiplier * atmosphereMultiplier This means that when the formula yields < 0.00001, even before the final multiplier is applied, the pressure function will return 0. That's why there's a cutoff. Note that maxAtmosphereAltitude does precisely zip; it's only for reference in the encyclopedia. The scale height for Earth is about right; when I get a chance I want to switch to pressureCurve, though. For now, you can try increasing the scale height, but note that your pressure (and density, because KSP annoyingly has density in linear relationship with pressure) will then be greater at lower altitudes than it should be.

jrandom: I apologize for besmirching your FAR-honor. :] If you fly with something like Centaur upper stage-level TWR (or even S-IVB) then you'll need a quite gradual curve that doesn't flatten until quite late and you'll still circularize after apogee. If you fly with something with reasonable TWR in the upper stage, you can get away with something that flat. If you pull it off right, you can circularize for about 50-100m/s The 9400m/s estimate is presumably not including dV losses due to burning in atmosphere (i.e. it's for if you're just looking at vacuum dV required) rather than actual dV required? Or it's based on assuming a wimpy American upper stage? Dunno. But anyway, I've always heard 9.3 for a 300x300 orbit, and that's with a realistic trajectory where they accept gravity losses from going straight up longer, in exchange for not having to have stronger PLFs for the higher aerodynamic stresses / heat of a flatter trajectory. Frederf: (not you specifically, but) what is it with the terminal velocity fixation? It's ~400m/s at sea level and you need one _heck_ of a TWR to even approach it after sea level. Seriously, you _will not_ be overspeeding in atmosphere with FAR. The real issue is burning so far from apogee that all you're doing is raising your apogee, not perigee.

And ninja'd, so: Yikes! You want to be turning nearly as soon as you clear the tower, though you needn't be horizontal before a good 100km or so (depends on upper stage TWR really). You shouldn't be using that much dV though (is it MJ's dV used, or "starting Vac dV - ending Vac dV"?) You can get Gemini-Titan up with <9100m/s vac dV btw.

jrandom: you want liftoff TWR between 1.15 (or so ) and 1.5 (or so). Low liftoff TWR means cheaper, but more limited launch options (asmi is the source for this; the main concern is wind shear--low TWR on liftoff requires picture-perfect weather). Higher liftoff TWR means you can launch when/wherever. SpaceX has ridiculously low liftoff TWR and is therefore incredibly limited in their launch conditions. Regarding TWR after launch, terminal velocity really isn't a concern in FAR (400m/s at sea level, goes up fast from there). You do want to be careful about dynamic pressure (and thus heating), but if you do a gradual turn (as you should--look up what a _real_ gravity turn entails) you'll be fine, even with high acceleration. The main issues people run into with FAR are about flying their rockets as if it were stock: not pitching over until 10km up (rather than starting turn when velocity <= 100m/s, as you should), and flying with high AoA/sideslip (i.e. having nose pointed well away from surface-prograde indicator). If you keep AoA/sideslip -5 < x < 5, you should be absolutely fine.

Frizzank: that is SO cool! Mu said he's redoing engine FX for .23, so we won't be limited to just the current half-broken system.

Yeah, well, it means more work for _me_, so screw you

Amount of resources in a part has diddly to do with physics lag: 10000 * 0.0043 isn't really faster than 100000 * 0.0043 (which is what happens: physics mass = part.mass + sum(resoucce_qty * resource_density) )

This is due to attach nodes not updating onLoad() (but proc fairings needing them then), and is being fixed this weekend.

Use rbray89's texture compression mod. That will help. Also, BobCat is redoing the Soviet Pack, and part of it will be to finally share textures to save memory. Other "real parts" packs: KOSMOS: TKS (VA/FGB) and Salyut parts FASA: American historical craft (Gemini, Advanced Gemini, Mercury, Atlas soon) Component Space Shuttle (has issues...) Lionhead Aerospace (Viking, Voyager, MSL...) lovad's World Space: Saturn 5, Japanese launchers, etc. Space Factory: Vostok, N-1, PPTS Real-looking parts: Sumghai's Fustek Station Parts Expansion and SDHI Service Module KW Rocketry Though they're not parts (except stretchy tanks [which feature real-rocket-looking textures]) you might also want the mods in my sig. And FAR, obviously!

I did fork the code. I'll put in the new params when I get a chance.

Check RftSEngines.cfg; that has mucho rescaling. Note that there are basically four cases, where the part.cfg: Doesn't include rescaleFactor, doesn't use MODEL node. Use rescaleFactor = 1.0 Includes rescaleFactor, doesn't use MODEL node. Use @rescaleFactor = 0.8 * old_resacle_factor Uses MODEL node: add or change the scale = line in the MODEL node to be scale = 1/rF, 1/rF, 1/rF, and (3) change/ (4) set rescaleFactor as desired. Then you need to copy/paste the two attach node lines and add @ in front, and change (or add if missing) the seventh number [node size] as appropriate. Note that rescaleFactor does change the position already, so all you have to edit is the size.

jrandom: attachRules determine how the part can attach, and what can attach to it. Right above attachRules is the comment describing them; they're bitmasks (1=true, 0=false) for allow stack attachment, allow surface attachment, allow stack to the part, allow surf attach to the part, allow collisions (I forget the exact order). Node sizes are, as mentioned above, only used by FAR to determine the drag of unfaired parts (the detection is based on the node not having anything attached to it); this drag is scaled by node size. As ferram said, you determine node side by the last number of the node_xxxx_yyyy lines (if there are six numbers, add a seventh; if seven, edit the seventh). You should also, if you have not already, make these changes to FAR/Plugins/PluginData/FAR/config.xml : change node size from 1.25 to 1.0, change incompressible drag to 0.01, change sonic drag to 0.2 (per ferram in the FAR thread for "made for RSS" settings).

You can see what I did for the masses of the fairing bases I added. Also, they now all have 2x symmetry (even the big ones) since that's most common in real life. (big exception being the S-IVB SLA.) It's probably still overestimating mass, but we'll see. (the changes to existing bases are in RO/pFairings.cfg; the new even-meter fairings are in RO/Parts/ProcFairings/) RO also adds a 2-sided interstage, btw.

jrandom: oh, you want the base rings rather than the custom fairing base? Sorry...I only rescaled the custom fairing base. I'll just include yours in the next RO then if you don't mind.