NathanKell

P.S. in Mechjeb, you have to hit "show all stats" for it to show up the first time, I think. I wrote it that way so that it won't confuse people who don't use MFSC (it's only ever available if you fly a vessel with an engine with MFS support).

Are you running that as a partmodule? Or a partless plugin?

You can try adding another ModuleDecouple and set its explosive node to top, not top1? You'd have to not use the movable node, but it should work (adjust fairing height with J) I second the feature request though, it'd be very helpful to toggle whether the payload is released on fairing decouple or on adapter decouple.

asmi, 1. I do put the build number in the filename: this is v3. 2. Based on some issues people were having in the ST thread, I'm going over the whole thing one more time. The heart of the problem is that the stretching is done tiny bit by tiny bit, and Modular Fuels rounds fuel quantities to 4 significant figures. When you start from a rounded base and multiply by like 1.0001 each timestep, the errors compound. I'm trying to figure out a better solution. 3. As was said upthread (and can be seen by the removal of the link to the custom MJ that used to be in the OP) sarbian included my patch in the latest dev build, as Starwaster says. What exact issue are you running into regarding it being wrong about thrust? SLT is correct for sea level, and TWR / Max TWR are correct for vacuum. Is the current reported acceleration wrong?

Then why also decide to leave some cfg patches unexecuted? That's what I'm still not understanding.

Nonono, I greatly appreciate your finding that! I wasn't not being grateful, just not wanting to get anyone's hopes up about it fixing things. Are you blowing up every part in the vessel when that happens? It seems to happen only when the last part is destroyed.

Flowerchild: That shouldn't actually make a difference regarding the clicking bug, because that happens on part.explode() (and happens when you die of heat, not just Gs). But you're right that for cleanness I should stop there, though the next section will only ever run that one time and won't do anything since the crew is already dead. Now, regarding configuring DRE and reentries. Here are the config options, basically: 1. Playing on Stock Kerbin, want traditional DRE functionality: don't change anything 2. Playing on Stock Kerbin, want realisitc levels of heat on reentry (i.e. faking an 8km/sec reentry): set the shockwave exponent and multiplier to taste; I suggest exponent 1.15 to start. 3. Playing on Real-scale Kerbin, want stock-Kerbin-level reentry heat: set _heat_ multiplier to 12 or so. 4. Playing on Real-scale Kerbin, want realistic heating. Change nothing in DRE settings. Again, to reiterate: DO NOT CHANGE ANY SETTINGS if you are using rescaled Kerbin and want realistic heating. In case 2 and case 4, you will also have to use modified heat shields. I will release an addon pack soon. For now, for each heat shield part.cfg, and for all heatshield entries in the DeadlyReentry folder's CFGs (DeadlyReentry, DR_HOME, and DR_B9), replace the second key = line in dissipation {} with 800 and 7xOriginal. Example: Mk1 pod shield in DeadlyReentry.cfg has this: key = 500 180 // maximum dissipation at 500 degrees C replace with key = 800 1260 Note that the Mk1 pod does have a built-in heat shield. You can tell because when you mouseover the part in the VAB part selector window, it says "Heat shield (directional)" The Mk1-2 Pod, however, does not. You will have to add a 2.5m heat shield. sidfu: what do you mean by geforce? There are like six crewG settings. (also, geforce is a brand of Nvidia graphics cards. I think you mean G force) Regarding reentry approaches: First, use FAR. Second, try for a periapsis that will provide you with a maximum of 9Gs reentry decel. You don't want much less than that or you'll be heating too long; you don't want any more than that or your crew will die. Note that it will differ per craft since with FAR your drag will differ per craft. When I was using Realscale Gemini (whose heatshield is configured correctly for real-scale Kerbin) coming in from ~350km, I used a 9km periapsis. That gave me a hair over 9G decel for a few seconds, sustained peak around 8Gs. I ran out of heatshield just as I went under mach 2. I mean, you could try with a very high Pe (like 80km), but my guess is you'll burn up, unless your heatshield is very good.

1. Which of the three available downloads did you install? 2. You do everything from the Action Group Editor mode in the VAB/SPH. Go to AG Mode, click on a tank. You can change what fuels it has. Click on an engine. You can change its mode and tech level.

1. They need to move it to a dir _with another copy of MM_, unless I'm misreading you. And you have that 1.3 problem in either case, because if a user installs an old mod with MM 1.3, then it's going to process confignodes, and so is your version, so you're still stuck. What you're proposing doesn't actually fix the old-MM problem. It just adds complexity. Because if I go and add MM inside my mod directory, and someone still has 1.3 in the root (the problem you're so worried about)...having another DLL in my mod directory will mean those nodes get processed _twice_. Which if they're adding rather than splicing is _real bad news_. I think your adding version checking, and making sure only 1 MM patchrun is run, is a great change. But I don't think you need to also decide to not process some confignodes. I think the best policy is to keep that, and process all confignodes, and make sure that the new MM still sits in root GameData, overwriting old copies. And then, obviously, all mods using MM need to update, but I don't offhand recall any that bundle it whose authors have totally disappeared.

1. I'm working on the bug mentioned. 2. You should only have one StretchyTanks_modularFuelTanks.cfg and it might as well stay where unzipping places it. To make sure. Delete your ST folder. Unzip the original StretchyTanks. Then redownload the patch in my sig. Then unzip it over the original ST folder.

I did not feel I needed to say "anywhere that KSP loads data"--that seemed rather obvious. And yes, it does process a CFG wherever it's placed in that scope, because it doesn't process files. That's the point. It processes confignodes. KSP processes files, and MM cfgs are read just like any other CFG by KSP. It loses a quite chief capability: processing all MM-valid confignodes.

Dragon01, Ah, right. Never mind. :]

That...that's a Saturn V with S-IC strapons!? Good gracious, bigger even than the V-24L. It's Saturn Multibody with S-ICs! EDIT: Wait, those look like Stretchy Tanks, so what's the engines?

sarbian, I still think MM ever not processing CFGs is a terrible idea. If you already are version checking, that's cool, but it's really bad if there's ever a situation that a MM-compliant CFG, no matter where it's placed, will ever not be processed. Why not do your version checking and only run MM once, but still process all confignodes? It just seems such a needless restriction. The bloody _point_ of MM is that it processes CFGs anywhere.

Dragon, the Realscale Gemini has them for Gemini and when I get a chance I'll add Big G and the Titan III.

You sure you have the latest? They sure do have mass in the cfg. And I just checked in my game, and the mass is right in line with my calculations. The Jumbo masses 0.345t dry. Install MFS v3 Continued RFRM again.

I got (m/s dV): 3917.588574 4822.654712 4292.842923 Note that the 3918 is optimistic since you won't get 304s at sea level! It's somewhere between 3918 and 3415. My method: for each stage, the wet:dry ratio is stage gross + gross of all stages above it (including the 45ton Apollo stack) / stage dry + gross of all stages above it. Those numbers are, gross : dry (tons) 2941.923 790.906 655.706 203.976 164.928 58.328

wasmic, shaw is right here. mbm is uncompressed bitmap, and the DXT1 version will indeed take up 1/6th the size (512kb for a 1024x1024, not 3mb). If the mbm has an alpha channel, it'll take up double that (only 1/4 the uncompressed size, which itself is 4/3 as big as the alpha-less mbm) (1mb for a 1024x1024, not 4mb).

Tank mass should have increased, unless I missed a zero somewhere. I'll check cryo. For ~40 tons total mass, you should get a fuel fraction of 0.96 And yes, I do plan on upgrading battery capacity. Right now it's about 7x heavier than it should be for 1950s tech, at 1EC/s = 1kW.

I'm not saying you shouldn't, and I love what you're doing. It's just somebody mentioned an existing one and couldn't find it, so I linked. Please do keep doing the awesome stuff you are.

Dragon: You can use ModuleHybridEngine for those engines. They work exactly like regular modular engines except you can switch configs in flight. Then you can have the three modes.

Then your Isp will change, and the changes made when you increase or decrease tech level will also change.

Yogui did do a CSM/LM: http://kerbalspaceprogram.com/0-18-1-munar-excursion-module-mem-v2-1-2/

ferram, alas it looks like density is in a linear relationship with pressure. Dragon01: Yeah, you can put the RT2 SPU on it now, and set the min crew to 0. Then it will work either crewed, or in network. If you need RT1, you can get my fork here: https://www.dropbox.com/s/16928ut2x37kih8/MyRemoteTech.zip The ejection plugin is Kreuzung's EVA Parachutes: http://forum.kerbalspaceprogram.com/threads/25305 Re: Soyuz engines. Yeah, Gemini is the same with the OAMS. I mean, technically even the "main engines" aren't, they're just two more of the large RCS thrusters. Even a bit less powerful than the side translation thrusters!

First, a chant of praise for the continuing excellent improvements you're making, rbray89! I did notice something, however: all your non-power-of-two textures will be scaled up to the nearest power of two, so the 1200x1200 ones will be taking up double the space they would if they were 1024. I'd suggest either using the full 2048x2048, or downscaling slightly. That might have something to do with the memory issues someone mentioned. Also, the cloud textures themselves--they have both color and alpha. But I thought you were using the detail images for cloud color?