NathanKell

Doesn't matter how fast you go. Matters that you start turning at about 100m/s and keep your nose only a few degrees off surface prograde at the most. EDIT: For MJ ascents. Set turn start to the altitude at which your rocket reaches 100m/s. Set turn end to somwhere between 80 and 180, and turn shape 60-80 or so, depending on TWR later in flight.

1. Yes, the planets are in the alignment of Jan 1 2000 on KSP start. I plan to change everything's time-since-epoch to 1950, so you can time-accel and to a grand tour. 2. I'll use your mass figures. I undid the rounding in excel, but it's only as accurate as the info I got (wiki mostly for density, and they use 4 sig figs). All my autogenerated code has spaces instead of tabs (because excel doesn't export tabs), but is indented (I hates it too); for the rest, take it up with Chestburster.

That and a number of other functions too. Although localSol is working on using tangents to get the curve to match for me, so you should get nearly inverse-square evaluations (hey, it uses cubic beziers, you darn well better be able to replicate a parabola!) Re: body order. Yeah, I think that might break other things if I changed Earth to not-body-1.

amo28: If you create your own loader that runs at runtime and applies PartCost() to the cost of each part, all you need from MCE (I _think_) is PartCost.cs. Err, and tools. However, you'll only get the DRY cost. All resource costs are done in the VAB via the MCE gui.

Fractal_UK, I heartily approve the going to planet orbital radius, for obvious reasons. I've been bashing my head against the problem for a while, since I didn't realize KSPI was also changing things. ...Although...could you load the radius from a config file? It'd be nice to just set a value "distance from sun at which multiplier is 1.0 in power curve" and forget about it, especially since at some point I'd like to change Kerbin's body.name to Earth, which may well mess up how you're getting its orbital altitude. Really looking forward to the nuclear overhaul too!

hawkwing: that sounds very strange, and is not something I've ever heard before. Is it just totally random? I know about the issue where parts can overtemp or overG on vessel load (i.e. either when going to launchpad or when switching to a vessel / loading from tracking station, or just when another vessels comes within 2.5km of your own). And I'm working on fixing that. But yours...different? tygoo7: I need to know a bit more about your circumstances. Are you using RSS or stock size Kerbin? Have you changed any of the stock config values for DRE? If you're playing with stock Kerbin and haven't touched any DRE values, you'll probably be entirely fine. Stock Kerbin just ain't that dangerous, even with no heatshield. Just fly a reasonable reentry path.

diablos: when I get a sec I'll use asmi's ECLSS framework to add orbital decay. Regarding solar panels: I'm testing a new fix that's a real "belt and suspenders approach": *Fix all existing SP Modules *Fix all SP module snapshots in unloaded vessels *Fix all powerCurves in solar panel confignodes (what the MM fix does). We'll see if that does for everything. Starwaster: what resources masses aren't accurate in the latest MFSC? I'd be happy to merge your changes into the latest MFSC if you're willing. sephirotic: That's weird. Coulda sworn I did set up Titanilaythe's atmosphere, but apparently not. Fixed for next. Note that you only need to specify *either* a body's mass or its surface gravity; RSS will calculate the other, based on radius. Regarding LAN, meanAnomaly, and AoP: I was unable to find reference data for those, so I didn't configure them for moons; that seems to be because moons' orbits are perturbed sufficiently rapidly by their parent bodies that those values change over time. If you can find that data for moons (I'm using the J2000 epoch BTW) then you can configure them just like the planets' are: by adding the appropriate keys to the Orbit {} block.

MJ Y/P/R is not always engaged, whereas throttle control is (well, it is 99% of the time since it defaults to on, whereas for attitude control you have to be affirmatively in an autopilot mode). Might that have something to do with it?

Oh, is that what's doing it? I got that too but assumed it was from something in RSS since I only noticed it once I made RSS.

Aazard: Divide battery capacity by 4. Leave solar panels as they are (since current draw doesn't change). At all costs don't set solar panels back to their stock values, since they're ridiculously OP in stock. For RT2, divide ranges of antennae and dishes by 10, but leave electric charge use as it is.

Genius Evil: that looks like something broke in your KSP install--it's not finding some _stock_ resources. I'm sorry to say this but the best thing you can do is reinstall KSP and then do a binary search on your mods: put half back in; try it. If it works, put the other half in; if that crashes, pull a quarter out, and so forth. Dragon01: Oops, right.

Huh. I've never had a problem doing that...what's your syntax?

Eh? Everything I've seen says the Apollo CM had 848kg of shielding. Plus the structural backing, presumably. And note that the Mk1-2 pod, when you add parachutes and batteries and a docking port and RCS, is just about even with the Apollo CM minus its shield. (Remember, the Apollo CM total mass of ~5.8t was with lots of extras you have to add on to the 4 ton pod).

So...I just realized. There are now 17 skins for StretchySRB. I suggest that any further skins (and perhaps I will change existing ones to this form) be done as skinpacks. It's very simple. The instructions are in STTextures.cfg for how to write the confignode. However, to make a skinpack, here's what you do. Make a folder in gamedata, call it what you like. In that folder place your texture In that folder make a config file. It should have the form: @STRETCHYTANKTEXTURES { TextureName { // insert your config here } } The docs on how to write the config are all in STTextures.cfg Note that for the textures you add, you will obviously add the complete path to them (i..e MyTextures/MyTextureSides and MyTextures/MyTextureSidesBump if a bumpmap) but if you still use the stock end texture (as most do, since they're usually hidden), then you'll want to reference that, StretchyTanks/Parts/ends Note this will require modulemanager, but everyone should have that by now. And anyway, that's why I designed the system like this: so people adding textures wouldn't be dependent on me. Anyway, then upload your texture zip and post a link here, and show a screenshot, and I'll add it to the OP. EDIT: For the record, here are the docs, and the first texture as a sample: // DOCS // If you're adding a new texture, create a new node. // The name of the node is the name that will be stored in your craft file. // Inside that node, you need two subnodes: sides and ends // sides can have the following keys: // texture = the path to the texture used for the sides // bump = the bump map, if any (shader will be non-bumped if this is left out) // uScale = how many times the texture is tiled horizontally around the tank // vScale = how many times the texture is tiled vertically on the tank sides // autoScale = if present and true, the uScale and vScale will be multiplied by // tank radial and vertical stretch factors respectively. Note that the // scales will round to the nearest (total scale factor / original scale) // so that textures don't have seams. The default sides texture // has uScale 4, so it starts tiled 4x horizontally and when stretched will // be more or less (but always in steps of 0.25) // autoWidthDivide = if present and true, and autoScale is true, divide height // scaling by width stretch factor. In other words, a 2x10m SRB and 1x5m SRB // will have the same texture scaling. (SegmentedSRB uses this) // autoHeightSteps = if present, use steps of (this) instead of (1/vScale) for // vertical tiling of the texture (only use when autoScale is true) // ends can have just the texture key (see above) Original { //by Ancient Gammoner sides { texture = StretchyTanks/Parts/sides uScale = 4 vScale = 1 autoScale = true } ends { texture = StretchyTanks/Parts/ends } }

li7in6, are you sure you've totally uninstalled KIDS? Oh, no, it's Mechjeb. You need the latest development build of mechjeb, that works properly with MFS thrust correction. Your version gets confused about engine thrust and lies about TWR. Once you get the latest dev build, install that. Then, ingame, click "All Stats" and a new column, SLT, will appear. That shoes thrust at sea level. TWR and Max TWR are for vacuum. Also, Atmo Time is then obviously redundant, since it's properly identical to Vac Time. iVG: The point of the engines mod is that, for regular MFS RF (and RFRM) we've felt obligated to use the existing thrust and mass. Well, in my engines mod, I went whole hog, and basically restatted everything. You get realistic mass, TWR, thrust, Isp, and fuel usage for every engine, and proper TL support (most engine start at low TLs). To the best of the limited realism of the models and their limited selections, engines are classed according to what they look like. (Exception: most upper stage engines have too-small nozzles. The LV-909 is a case in point, it should have a bigger nozzle than the LV-T30!) Also, in the soon-to-be-released latest version, I undid the Great Rescaling. Engine sizes are now 0.5m, and then every meter on. This is to go with the latest stretchytanks, which has even meter sizes and displays width and height. You'll be able to create realistic rockets without a dozen lower-stage engines (the largest engine in the rescale is the NovaPunch 1.5 M-50 5x, which is a Saturn V bottom lookalike with 5 F-1 lookalikes. And yes, it's now scaled to 10m diameter and 38MN thrust).

So, I haven't had a chance to track down the SRB-moving bug. But I have done a few fixes. Last call for new textures before release! Tentative changelog: v6 == \/ == *Added height and width display *Changed scaling steps (slightly finer control) *Removed width and height limits *Added even-meter tanks (0.5m, 1m, 2m, 3m, 4m) *Added one new texture by me *Added three new textures by Chestburster *Added three new textures by Dante80 *Resized a couple textures, for hopefully no loss in quality.

It's my alternate history spacerace. The link to the reboot (100% non-Kerbal) is in my sig. KATO was Earth alternate history with a laughably thin veil of Kerbal names; now I'm not even pretending. It's kinda how I got started on all these realism projects. The old KATO is still in Mission Reports, just buried a few pages back; Reaching for the Stars should have a new episode soon. KhaosCorp: I'm about to release that rescale I was talking about. Combined with StretchyTanks, you can make stages as large as you like. (Well, you can now with stretchytanks, you just have to use lots of small engines for your 10m cores). Note that StretchyTanks has a "super stretchy" whose radius as well as height you can scale. Regarding planes: You want the blue of the CoL _just_ on the back edge of the yellow CoM sphere, and you want (via RCS Build Aid) your red dry-CoM sphere inside your yellow CoM sphere. EDIT: li7in6: I believe e-dog is working on that now! For now you have to use the pfairings interstage and place a ST inside. EDIT2: Note that if you aren't using pfairings, it's a must. Note that most stages are cylinders, and instead the interstage adapts beween sizes. And the procedural interstage is just that, procedural, with rescalable base and top width.

For removing MM fields you need to (a) be doing your changes as :Final (if they were adding by MM; if they're in the part, no need) and ( use this syntax: for values: !valuename for nodes: !NODENAME {} See, otherwise MM will think it's a value called NODENAME I'm doing them as 3m rather than 3.05m, that's why I asked about leaving the 3.05m ones as separate parts. And their real performance doesn't quite fit the MFS TL system.* So I'd still like to do separate parts, even if the Real-Titan is 3m. I will give them the -3, -5, and -11 configs for each (Titan I, II, and III/IV). * the -3 is about TL 1.5; the -5 is about TL 2.2, and the -11 is a mildly upgraded version rather than a TL3+ engine.

Hah, thanks ferram! I was going to pm you about this tonight because I figured you'd know, and...you post before I even ask. Thanks so much! biasuz: it should appear near the top of the Structural tab. Did you install this after starting a career save? You have to go back and unlock it (or it might not have unlocked yet). Playful1510: known issue. Working on it. I'm very sorry, but for now, revert to VAB and try again.

KhaosCorp, I (and a number of others) have found making planes in FAR _much_ easier than in stock. I can't make and fly planes for stock, whereas I have yet to make a plane that wouldn't fly in FAR. The simple rule is, in FAR, it'll fly like it looks. Other than the dynamically-unstable planes that in real life require computer assistance, most planes are designed to fly well, so if you clone them you should be fine. And the FAR thread has a ton of guidance and helpful mentors if you get stuck. Regarding large bulky payloads: they actually will fit, because remember how much larger rockets you require. That means you'll need, say, 8m diameter cores to lift your 100ton payloads. And I bet your 100 ton drill + transfer stage will fit in an 8m-diameter fairing! Also, AFAIK, there's nothing about RSS that should break Kethane. Try it and see! Same with EPLP. I'm just rescaling, it's not like I'm changing how planets are made! Oh, speaking of 8m cores...I'm putting the finishing touches on RftS-Engines, the successor to KATO engines. In combination with the rest of my realism tweaks you'll have realistic rocket sizes and support for large cores (the old NovaPunch 1.5 M-50, aka F-1-alike, in its 5x version, is rescaled 10m part). and regarding FAR settings: diablos has it, there are no settings. It's all automatic. Just, and THIS IS IMPORTANT, you have to change your ascent profile. As other others have said, you need to start your gravity turn EARLY, like, at about 100m/s. You should be horizontal by maybe 80-150km, depending on your TWR (lower TWR upper stage = pitch down slower; trying to SSTO, with a 12G burnout TWR, pitch down fast!)

Sorry, haven't had a chance to look at the moving-part issue yet, but it's shortly to be at the top of my priority list. Ratzap: Which version of MFS 3.2 did you install? Make sure you're using RF or RFRM. Make sure that you deleted your old StretchyTank folder first before installing SSRBv5 (and same for MFS before installin 3.2). If all that fails, do the thing that makes it fail, and zip-and-upload your output.log Dante80: whether a part can surface attach to other parts is controlled by both parts. The tanks and SRBs are surface-attach enabled; you can attach other things to them. Most engines, however, are not enabled to surface attach to other things. That requires changing the attachRules and adding a node_attach node with the same stats as node_stack_top (otherwise, if you just change the attachRule alone, they will, IIRC, attach at center of mass rather than where you want them to). TL;DR gotta change the engines involved.

So, I don't claim to know when one can see the curvature of the earth. But I do know that this tangent no longer belongs in this thread. Please take it elsewhere. Thanks.

Well dang. Launch KSP, alt-F4 when it hangs. Zip and upload ksp/KSP_Data/output.log and I'll take a look.

I'm going to enable those values for debug mode, and we'll see. I think (or hope) that the _reason_ you think you're out of danger is precisely _because_ the shield finally starts ablating at high speed. Regarding shockwave: this is because DRE doesn't actually check Cd, reference area, or mass times that to yield ballistic coefficient. So rather than use W/m^2 heating, it just uses temperature. That said, I note that wiki indicates that reentry velocity = peak temperature in K, which does not occur when the velocity is at its highest (IIRC). So...argh. I think you're right after all.

Yes, I saw that you went to the moon; I just want to reaffirm (in my post above--we're now ninjaing each other so you may have missed it) that RM is working by design. Realistic doesn't always mean harder, or rather, it does in toto in KSP, but not for each individual thing.