NathanKell

AbeS, thanks! The procedural interstage supports parts on top of it (at the rescalable-height node) with the fairing panels. To decouple that node (top01) you decouple the fairings. The fact that the interstage has a decoupler itself is only so that MJ and KER can make sense of it. RADM Temple in retirement:

Reverted. Should behave like v3 again.

KSP calculates position in orbit based on period, but speed based on mass ratios and SMA. If one is updated but not the other you'll get that effect.

Apologies. I left up a testing version. I'll replace with a real version ASAP.

Saw that, and yup, can fix some of the rolling-hills issues on rescaled Kerbin that way too. Yeah, been putting that off because it works as is (just not prettily), but I should hit that soon. Nice! Don't think it'll be an issue; looks pretty simple. The harder part is converting the Standard Model of pressure at altitude to a set of cubic bezier points and tangents. Not hard per se, just will take some twiddling. :] Yup. Got it working last night, testing a bit more today and adding tilt.

Using FAR?

Thought it was 1/d^2. And yes, I'm doing that for real solar system.

You're both welcome! It's a known issue in the stock game, it's just that DRE making your ship explode triggers it. To fix: you need to somehow launch again. The way I do it is revert to VAB, launch, and revert again. I've had it from heat as well as G, btw; it's intermittent, because there's some underlying stock issue it's bringing to the fore.

Larger resolution textures. That is not necessarily the same as size on disk. (a 256x256 MBM will take up more disk space than some 1024x1024 PNGs)

Lucius: aw, thank you so much! Do note that I'm standing on the shoulders of giants, especially with DRE which are direct continuations of ialdabaoth's great work with them. Regarding the atmosphere, there was a discussion some pages back, and some discussion in the Realism Overhaul thread too. Basically, using the legacy (exponential) atmosphere model, a planet's atmospheric density is clamped to 0 when the exponential calculation (as shown on the wiki) falls below 0.00001. That means, with a scale height of 7.5km, it hits zero at approximately 104km. I'm currently trying to switch the atmosphere model over to the new pressureCurve system, which will allow a quite-close copy of Earth's atmosphere. However, when density > 0, then time acceleration is disabled (and the game thinks of you as not in space). So it makes sense to formally cut it off at some point. Ferram suggest 135km. However, regarding the thermosphere, asmi (after finishing the other mods they're working on) was thinking of making a plugin to handle orbital drag and stationkeeping, so that would be taken care of too. Regarding career. If you look in the Add-On Development forum, you'll see a thread by MedievalNerd on a realistic tech tree (I'm collaborating with him on it). Career mode is indeed coming part-and-parcel with all this; the TechLevel system in MFSC was designed for it. The idea is to model rocketry from soundnig rockets and WW2 SRBMs to the present day, with the potential of a career stretching from then to now. Regarding Deadly Reentry. I recently posted on that thread suggested configurations, because there was some confusion. Let me restate the relevant one here. I recommend leaving ALL DRE stats as they are when unzipped, and instead increasing heat shield dissipation. Note in particular that the new shockwave exponent and multiplier are only for people who want a deadlier reentry on stock-size Kerbin; the 1.17 exponent I mentioned was to approximate heating on real earth when using 600km-radius-Kerbin. You, who are using a real 6371km-radius-Kerbin, don't need that, and indeed shouldn't use it. If you want a Mk1 heatshield config that works with this mod, and DRE multipliers unchanged, check the DRE thread. You should, on a correct reentry, suffer no more than 9 drag Gs in a Mk1 Pod. I just tested a suborbital launch with it and got Mercury's 11, so that's survivable too. I have also made a custom heatshield for the RealScale Gemini (the set of CFGs for frizzank's Gemini to give it real mass/size/performance, see the FASA thread) and that also reenters just fine. The readme offers suggested reentry perigee (indeed, suggestions for the entire flight).

License, as in OP: http://creativecommons.org/licenses/by-sa/3.0/

Yeah, we'd definitely need to page. And re: geometry, the quadtree system I wrote (bouncing off Sean O'Neil's old demo) for my senior project used that method (I just passed IIRC 9 base meshes to the GPU, then vertex transformed based on shader-calculated noise) but the cards the CompSci department had didn't even support tesselation! (and I didn't have time to do a full geometry shader version--bah, semester projects with illnesses!) Anyway. Do you know how much modern shader support Unity actually grants? Might be worth thinking about a port of your engine.... (DX->OGL is bad enough, let alone wrappers, but just thought I'd throw it out there) The life remark was a rueful one re: ZRM's semester load interfering with writing this, or rather the other way around, and the universality and annoyingness of that problem. That was all. Apologies all around if it was unclear I had noticed. I guess I could add an on-fixed-update check to change navball mode, but I'd hate to force-switch someone who had already switched. And since I'm usually annoyed at the autoswitching, it never bothered me much. But 384km _is_ a bit much!

Haven't used stock subassembly yet. I'll check it out.

Yeah, saw that ref on the Soyuz stats... Re: fairings. For FAR to recognize a fairing, it needs to have Fairing in the part title. Not sure what it could be other than residuals unless they purposefully shut off the stage early and Astronautix reports that figure. I mean, the burn time formula is pretty darn clear. :] Oh, though KSP uses 9.82 (!!!???) m/s as its gravity constant in ModuleEngines when drawing resources, but that isn't enough off 9.806-9.81 to account for 10 seconds either.

According to experiments in the UR thread, KSP/Unity will reject textures over 8x4. I'm thinking we should try out an 8x4 Earth heightmap for kicks, see how that goes. If we're replacing, might as well go whole hog. But you're right, it's a drop in the bucket. We'd get 0.043 degree (~5km) per pixel resolution at the equator. I wonder if there's any way to use the scatter system for Munar craters to generate procedural detail on Kerbin? ZRM...heh, life. :]

The mipmap PNG issue is that Unity won't autogenerate mipmaps for PNGs so you'll get moire patterns and other issues when texel:pixel ratio gets high.

42 miles _is_ Kerbin's Karman line, actually, or near enough. Even if you scale 42 miles (67.6km) to Kerbin altitude--45km--it'll still be 99.99% vacuum (literally, 0.0001 pressure). You still get drag, but it shouldn't make a difference for exhaust expansion, and thus you'd want a vacuum-optimized nozzle. (Though the J-2 didn't even have fully vacuum-optimized nozzle; it still got 200s at sea level.)

Maybe. But compared to what KSP's doing not so much, I guess--or at least I didn't see any performance drop. But YMMV.

MJ already does it ingame, btw, though as we discussed above the engines burn everything and don't leave residuals so the burn time will be for every gram of propellant, and thus longer than reality. The formula's just total mass of fuel * 9.81 * Isp / thrust, though. I mean, I could add lines for thrust and Isp, I guess? EDIT: Added. And added more info.

Yup. Why not just scale the SP chargeRate down? At 1EC/s = 1kW, then batteries need to go up (~7x) and SPs way the heck down. For 20 watts...don't even want to think about it.

Hey, you're already doing it: finding real values. I never have time to play and test anymore. :\ :]

Very little. KSP is CPU limited, and what does the GPU care if it renders a few more particles? Well, I mean, the CPU has to transform them (unless Unity is modern enough to do that on GPU, which I doubt), but that's cheap compared to planet quadtrees or part physics. I mean, heck, I've regularly been playing with about 5x the emitters*, so just increasing a single emitter's lifetime won't do much damage. *smoke looks much better when you copy-paste smoketrail_large about 5 times. Same with flame_yellow. I did that on the Realscale Gemini, if you want to try it and see if it impacts your performance.

FlowerChild, that sounds pretty cool! Like I said, I can try with the next release remove the :Final, and see if anyone complains. If not, you're golden. AbeS: use the same values for the 1.25m heatshield. Use the same values except quadruple the loss rate amount (480->1920) for the 2.5m heatshield. That should work for now, I think. Maybe increase dissipation a bit too, since a Munar reentry is going to be 1.5 to 2x the temperature at the start.

You can edit the particle lifetime in the fx emitter, I'd think.

Good gracious batteries are going to hold a lot of EC then. Sounds pretty awesome though! (As I think I've said before re: that project. )