NathanKell

Hah, thanks folks. Due to be able to build, but not really fly (or at least not well enough for good screenshots) I now have, I believe, the craft for the next few posts. I'm still deciding on satellites and the US launcher config, but I believe I can now reveal the JRC Mk III. Here it is on its record-breaking flight, after "buzzing" the German rocket establishment on Pemba Island, Deutsch-OstAfrika. Gerry Sayer at the controls. (Pemba is the farther island; Unguja Island [Zanzibar proper] is the nearer). Breaking Mach 2 without reheat. Supercruise indeed.

I thought they did use game volume, but maybe not. I'll check and try to fix when I get home.

Yeah, saw your post on the SpaceX thread, didn't know if it was spur of the moment or more serious/general. Good luck to you!

OtherBarry: if the part doesn't use a MODEL node, you can just up rescale factor (to 1.6 if it used to be 1.0; or to 2.0 if it used to be 1.25 or was absent). Or 1.2 and 1.6 respectively if you want to go to 3m rather than 4m. If it does use a MODEL node, it's more complicated; check what I do in the FASA.cfg linked in post 2.

You could detect if the assembly is loaded. Easier though if you just detect what the Mac atmosphere altitude of body 1 is, and if > 70k assume RSS. better yet, use a multiplier of max atmosphere altitude / 104. That will be correct for any scale Kerbin.

Ooh ooh even better, TSR has a full article by Dwayne Day on the proposals! http://www.thespacereview.com/article/586/1

I was rather hoping you'd say that. Regarding other Mercury(ish) proposals. Here is the original Langley (Faget) Mercury design. Here is the page for the USAF Project 7969 "Man-In-Space-Soonest" with the overview of all designs submitted and, further down the page, links to each. You can see that both the original Langley Mercury design, and McDonnell's MISS submission, used the "headlight" reentry capsule reused on Apollo D-2 and on the Soyuz (though the Langley Mercury had a cap, and a fairing around the cap and down the sides). For later-on Mercury might-have-beens, here's Grumman's submission to the final competition. You can see that Langley (and Faget) had clearly narrowed down the exact shape; there's little difference (other than the one-step rather than two-step cap, and the (?) drag brakes (?) at the top, between this and the McDonnell bid that was selected and became the real Mercury).

Actually iirc you can. Exception is made for parts.

No, it'd be MFSEngines or StockEngines or RFTSEngines. If any of those cfgs exist, nuke them.

For Photoshop use SuperPNG. Makes life SO much easier. ..

Do you have any *other* set installed anywhere?

Your approach is much better, obviously. Was just mentioning my hacky alternative for the record. That 0.7x thing--why not get it from air density or pressure directly? Then it'll work in any atmosphere. (And even if not--is the 0.7x hardcoded? Hopefully not...hello RSS)

Wow, I thought this thread had died, and instead I'm missing out on awesome stuff for...pretty much a month. Especially that prime Kell-bait from Wallenberg (Have you considered doing the Colliers stuff?) Anyway...a hearty "well done!" to all of you!

Wow, that is...*really* quite impressive. Kudos!

Nope, it's because the bug where rescaleFactor is applied twice to MODEL node scales only occurs on launch, not on revert, to root parts. So multiply everything, and manually change your nodes and other cfg file positions, such that you can have scale = 1.0 and rescaleFactor = 1.0, and any and all scaling is done *inside* the MODEL node. For example, the WAC Corporal probe core should be changed to: MODEL { model = Squad/Parts/Aero/rocketNoseCone/model scale = 0.12, 0.576, 0.12 } scale = 1 rescaleFactor = 1.0 where it used to have MODEL { scale = 0.8333, 40.0, 0.8333 } and rescaleFactor = 0.12 Since its only node is at 0,0,0 it needn't be changed; but if it were at 0, -0.2, 0 then you'd change it to 0, -0.024, 0. ( -0.2 * old_rescaleFactor)

The negative Isp was probably because the FloatCurve had two time=1 values and no time=0 value and freaked out. (@ means modify the first value of this name, so @key twice would modify the first key twice). As you found, when values have the same name, you have to differentiate between them with ,n syntax.

Oh, cool! a__gun: thanks for your patience.

dtobi: wooo, that's a whole 'nother level you got there! Nice!

Yeah, which set of engine configs?

Might you consider some of the alternate Mercury proposals?

a__gun: I'm still on my trip (will be for another week) so no dev work, sorry!

@PART[Mark1-2Pod] { MODULE { name = ProtractorModule } } Probably it was that there was no space between the ] and the { ?

Oh, I see. Hmm, I'd just add a helper object in max, and note its position and direction; it's just the extra step of writing down the transform's position once made, rather than exporting that directly?

Sure! Nothing should have changed regarding that in the last few versions. The main thing is, suborbital reentries *are* high G (if ballistic). The other thing you can do is use a pod with lift, like the Mk1-2 (and offset its CoM, or use RO where that's already done). This will provide a lifting reentry, which lowers Gs a lot. Basically, with an apogee of 185km and a range ("ground distance covered" or whatever) of 500km you're looking at 12 or so Gs peak. With a higher apogee or lower range the Gs go up. ICBM-level reentries are like 30Gs.

carolyn: no worries; apologies if my first response was curt! And help with scaling is *always* needed! For some examples of glorious excess with RSS/RO, see the examples on this subreddit: http://www.reddit.com/r/RealSolarSystem With KJR you do have to be a bit careful how you build (although 2.0 is *really* nice; Ferram added a lot of improvements). In particular, KJR has a hard time dealing with featherweight parts attached to massive ones (like, say, a MechJeb control part attached to a 2500t stretchy tank!), so try to avoid that when possible. Regarding scaling--if you scaled part masses down by the cube, then yes, fuel volume and mass would be correct for the deltaV, and tank density wouldn't change, but then you'd get lower-than-RL ballistic coefficients (vs. the stock game's higher-than-RL). That's fixable by Ferram, say, adding a surface area multiplier, but anyway. You'd get the same TWR (although if Kerbin were not earth-size your ascent would take a different amount of *time*, which would be an issue, let alone the sharper gravity gradient...but let's assume RSS with 64% parts and ignore that)...but the issue with fuel is, if your part is 64% the size and you *don't* scale masses by 1/.64^3 (as you originally suggested), then your fuel density will be wacky. Basically, if you rescale mass by the cube, then ballistic coefficent gets messed up; if you recale mass by the square, then BC stays broadly correct but density goes way up (you're fitting more liters of fuel into a tank than there are liters in the tank).