NathanKell

A favor: Could you replace radius, in the config file, with km height offset, and then calculate the actual radius ingame? If you needed the scalar, it'd be as (body.radius + offset * 1000) / body.radius Then this could be just "dropped in" to work with real-size Kerbin, rather than having to change the radii to 1.00038 and 1.00076. Regarding the layer issue and rescaling--is that related to the render order post you made directly afterwards, or a different layer problem? I wouldn't have thought render order would change the _scaling_ of the clouds...

Macs? Eh. Pull the drive and use it in your PC. Seriously, I have no real idea. Last time I used a Mac it was System 7. Sorry. I'll check the Mun's period. It should be ok, but... Oh, if only I had fewer part mods. Zander, that looks incredible! Also, I'm trying to get rbray89's clouds and city lights mod to work (it looks amazing in stock KSP) but the sphere is coming out wrong. I'll keep people posted. With that, we needn't use the cloudy-Kerbin texture in UR.

Ah, right, the hyperedit bug. I need to fix that. I'll add a check where if gToleranceMult <= 0, g force checks are ignored.

This will support any mod, since the temperature and g-force effects are partless. However, heat shields need ModuleHeatShield modules. I will release configs for more mods, but for now you can copy existing module defines and retarget them. Out of the box it supports B9 and HOME's heat shield. Further, the way DRE checks for shielding is by raycasting and checking hits. So assuming raycasting properly hits fairings (which, AFAIK, it does) then parts inside fairings will be shielded by the fairings. It might be worth considering giving fairings the same non-ablative heat shielding that fuselages have now. Synthesis, try deleting your DeadlyReentry directory and re-unzipping. Let VetTech handle the tech placement for now. See if that works. If it still doesn't, launch the game, go to VAB, quit, and post your KSP.log. Mihara: um, because that's how ialdabaoth made it originally and I haven't done more than add a couple bugfixes. I think possibly because a lot of parts are missing breakingForce entries, and the values seem to make less sense than crashTolerance? Some parts have insanely high bFs...but that's worth thinking about! There are three issues, AFAIK, with parts "being destroyed when they shouldn't." (1) was the explode on launch bug: fixed. (2) is the gTolerance is too low, which the multiplier helps with some (but really, we need a new formula, as you say, although breakingForce is not, I think, quite right for it). (3) is that we shouldn't even be looking at current craft acceleration but the force the part is currently experiencing (a probe core squished between two tanks and two mainsails running full blast will experience 0 acceleration, but tons of force). sidfu, VetTech doesn't actually rearrange the tree *nodes* at all, it just changes the TechRequired for parts. So a part may require a different node. But thanks for stepping in, in my absence!

Look for all sections that begin *MC* (except for the first, which is just calculating prices) in your KSP.log. It will tell you exactly what's going on.

Also, ferram, despite setting altitude the way I did (135000), you don't start registering dynamic pressure until 105km (where scaleheight says it should be). Weird.

Drag officially fixed! pina_coladas, I haven't shot more than 3 ships into orbit yet. Too busy coding. Thanks for the info! Source and zip updated (zip = https://www.dropbox.com/sh/16v210v2vbwv3ov/nmInpsRZ1P and source is https://github.com/NathanKell/RealSolarSystem )

Recompiled from your latest commit and tried on Earthbin. Looks like the scaling is going wrong somehow. Any ideas? I looked and it looks like you pull from a scale factor that should be correct (I correct it at the Main Menu)...

Is anyone but Synthesis running into part troubles? Synthesis, maybe you had an error in how you added the tech requirements--that would kill PartLoader and make the parts not show up. What techs did you use, btw? I should add them. But since I haven't actually played .22 yet, just been modding it, no idea where.

I AM A MORON. FILM AT ELEVEN. I was setting max atmosphere height in km instead of meters. That's why stuff worked up to 105/135m. Oy. Tested, and that fixed it. We now have parachutes! And, for those folks without FAR (I know, I know) we have drag. Uploading fixes.

Oh, apologies. That would have been smart. https://www.dropbox.com/s/fw7oklfkljy827u/ModularFuelSystemCont_v2.zip Thanks for the idea!

Getting there. Fixed atmosphere skydome, and now the barometer is working. But still no flight drag.

Have you checked Kerbin's new orbit?

That said, all these engines were thrust-balanced for stock KSP dVs and masses, and all I really did was scale the mass down to make the TWR realistic. So they probably need another pass.

MFSC engines include their thrust plates in their mass; the actual engine TWR was calculated at 108. But you're right that SL Isp isn't as good as those amazing Russian staged-combustion engines. Interestingly, according to my calcs an engine with that Isp should have a TWR of 84, so sounds like my balance is about right. Here's the sheet I use if you want to roll your own. Just change the stats and go. Set NewName to 0 if you don't want my KATO new engine names. https://www.dropbox.com/sh/16v210v2vbwv3ov/nmInpsRZ1P Docs are here: https://docs.google.com/spreadsheet/ccc?key=0AvHneDAy4k99dDZYOHJraGpQc2VuMUxxU0FjSUp6NXc&usp=drive_web#gid=7 Only changes: TWRG column shows goal TWR. Isp SLM and VM are multipliers. So you can customize Isp per engine; TWRG will scale appropriately for balance. Tweak the Isps too if you want. When done, paste Column AC (from AC3 on) into Engines.cfg and remove the quotes, and IspsOut into RealSettings.cfg and remove the quotes. BTW the largest KW engine is actually the G8D now, rescaled to 5m. The largest in pure thrust is the old NovaPunch 1.0 M50-5x, at 9000 at TL3 (only goes up from there). EDIT: Also you might have the first alpha of v3, where overheat was broken. Re-export from the calcs.xls I uploaded above, the heat should be good now. Or just change the formula in that column and re-export, and heat will not be an issue. Edit 2: Actually, you'll be at near-Vac Isp in about 30 seconds to 1m from launch, I think, and your first stage will probably burn for 2 minutes.+ So even for first stages, SL Isp shouldn't matter that much, although certainly matters more than for upper stages!

You...did set it to TL7? If you do it should give you better-than-present-tech Isp (for whatever fuel type), and near-Merlin-level TWR. Otherwise you'll get bad Isp and TWR. Ah, <3 dat kerolox too, huh?

Yeah, I tried to switch to replacing the values on every scene transition, in case that was the problem, but it's caused more problems than it's solved. Then I had to break for dinner. :} Apologies. I didn't update the DLL yet because I figured it mightn't work.

@ferram, those are the classes that I found and am trying to update. Currently getting some NullReferenceExceptions after I do so though. Yup, confirming 0 drag, I tried with no FAR too.

We really should check for a completed mission and autocomplete it when you hit recover...

I didn't properly update the bodies after changing their stats. That should be fixed, testing. I forgot about the Munar scaledspace issue; the thing is, looks like the SS transforms are set often, so we have to keep replacing them, I think? Since the Mun starts at localscale = 0,0,0! The twitchiness seems to be float precision errors, at least in my experience: you can see the problem with the PQS vertices, if you're coming in for reentry, they slide in and out of the water (now that the waterlevel is fixed). I've found (some of) the problem with parachutes. It turns out the barometer, and anything that relies on its method of finding pressure and density, reports IN VACUUM. Oddly the chutes do seem to deploy correctly, so _their_ method of determining pressure works. (As obviously does yours!) But it seems like what determines drag uses the same method (or hits the same bug) as the barometer. Also, I may have found the atmo lighting problem. We'll see. If worst comes to worst, we can use the new pressureCurve method of setting atmo pressure rather than the function-of-e method. So, TL;DR check the new source.

Play? Heh, not really, no. :] Eat, yes, at least. Yes, this is DRC^2. Regarding g-tolerance multiplier. Thus far I have not changed ialdabaoth's g tolerance formula, which is sqrt(6 * impact tolerance). The multiplier is just a global mult afterwards, so the formula is now gToleranceMult * sqrt(6*crashTolerance) Since gToleranceMult is now 2.5, they have indeed, the limits are 2.5x what they were. So you really needn't worry until, oh, 12-15Gs. I hope at some point to give parts rational G limits, even bearing in mind (see the old thread) that acceleration really isn't what we should be caring about per se, it's force on the part from all angles.

Thanks, folks. Ratzap, except for like a meg or two of parts, it shouldn't take any memory to speak of.

Yup. Still buggy, but yup!

OK, updated. Also, apologies, last time I updated the source but not the zip. Fixed now.

Aw, thanks! A note to anyone playing with Human-size Kerbin: setting temperature mult to 8 (instead of the stock 25) seemed to work just about right for me.