NathanKell

I hate to be a pedant (who am I kidding, I love to be a pedant) but what you're talking about is a boattail. While in KSPland we don't make distinction between boattails and actual-butts-of-tanks when talking about Tankbutt-itis, it's worth noting the difference. GregroxMun showed pics of actual tank butts, and bs1110101 showed boattailed enignes. However in KSP we often get a weird combination that is shaped like a tank butt + nozzle, with no room for the plumbing at all...

Another suggestion: consider using HAN as a monopropellant. It offers mostly-similar performance to hydrazine but is not DEATH DEATH TOXIC DEATH, and has a different (maybe more helpful) density.

The point is that, say, Kerbin has mountains 9km high. When you change Kerbin's radius from 600km to 1920km, that means mountain tops are no longer 609km but now 1929km (fine). However, the scaled space model (the static mesh seen from orbit) is just a mesh, so when you scale it up 3.2x that means it *looks* like you have (609*3.2 = 1948.8, -1920 ->) 28.8km tall mountains. That's bad. So RSS regenerates those meshes. GregroxMun, what you need to do is: 1. Delete RealSolarSystem/Plugins/PluginData/*.obj 2. Launch KSP, wait for it to finish loading 3. Include the OBJ files it created with your pack, so other users don't have to wait 20 minutes the first time they play this, or don't have the wrong meshes if they forget to delete them.

And in addition remove your CustomBiomes folder (CB comes bundled with RSS, has for a while, that's where the new biome comes from).

So you still won't explain why engines having varying Isp and TWR isn't *exactly* like wings having varying regimes they're good in?

I believe this has been covered recently in the thread. The way biome textures need to be made changed in .90.

Add an engine, then right-click the tank and try again.

Like what? (Since I'm the one who made both the pruner and the patch).

EDIT: Post redacted, MasterTao pointed out (and I just verified) that at some point recently, the behavior changed such that the decoupler is no longer fake. However, if you use an interstage without fairings, then the joint on the floating node will not be created and thus the interstage will decouple as soon as flight loads. Ok, let me try explaining this one more time. Here is how the procedural interstage works. 1. It has three stack nodes, we'll call them bottom, top, and floating. 2. It has some number of surface nodes, where one attaches fairings or shrouds. 3. It has a fake decoupler in the floating node. That decoupler is there only so that MJ/KER do not get confused. It will not break the joint between the interstage part and whatever is attached to the floating node. 4. When you decouple the fairings, however, those joints are broken. This is how one actually 'decouples' the interstage from whatever one attaches to the floating node. If you attach something to the top or bottom node, you need to add your own decoupler. If you attach something to the floating node, but do not intend to decouple the fairings (or use the fuselage shrouds, which do not decouple), you need to add your own decoupler.* On the contrary, if you have something attached to the floating node, and you decouple the fairings, you will decouple that floating node, even if the 'fake decoupler' attached to it is not staged until later. *How KJR modifies things: KJR turns the 'fake' decoupler into a real decoupler, which means when you stage that fake-decoupler-attached-to-the-floating-node, KJR will itself will break the joints, which means you can decouple the interstage away from whatever was attached to the floating node without decoupling the fairings. e-dog, I think you really need to add something like the above to the OP, it is *not* immediately clear.

Looks like you installed Real Solar System the entire package, not just installing 6.4x and replacing the RSS dll with the new one from RSS 8.5...

Levelord, I *utterly* fail to see why this argument does not apply to Isp. Please, please elucidate. Oh, also, completely-impossible-in-Unity mod does completely-impossible-in-Unity on-rails thrust... >.>

1. Yes, both the Mechjeb one and TriggerAu's TWP work. 2. You can use various real-life tools for calculating them; ingame, yes, patched conics will show your intercepts and ejections. 3. The system is not inclined; your view is. (If we made everything 'flat' then Earth would no longer have the [fake] axial tilt it needs.) 4. Spaceplanes aren't supported by RO yet; when they are, they'll have the correct shielding. Help is always appreciated, though!

Welcome to the forums! Right now Hangar Extender is not updated for KSP 0.90, so you'll have to be patient while Snjo updates it, alas.

Moved to Addon General, since there doesn't seem to be development going on...

klesh, please read all my post: you need KJR, then it does work. I am presuming that Kowgan has KJR installed.

That setting, given further testing, turned out to be less than useful. I rewrote the entire thrust portion for 3.5, though, so when that gets released things should work better.

tater: other than turning on thrust correction, leave the multipliers as they are IMO.

Please see Realistic Progression Zero. It's a WIP, sure, but it's playable, and we can always use more testers (and contributors!).

Bender222, why do you need geostationary commsats? You can launch an LEO/MEO constellation...you even get paid for it, with Fineprint. TheKnave: Here you go!

Uh, why the limit of two? Use as many engines as you need...also, your two-stage method sounds good, but once you get above the atmosphere you won't need more than like .2 Earth TWR to circularize and kick home--especially once you achieve orbit, TWR is nearly meaningless, you can always do your TEI in multiple passes.

Skaku: correct.

klesh: that is impossible with just Proc Fairings. If you have KJR installed, however, that becomes possible, because KJR turns the 'fake' decoupler in the Proc Interstage into a real decoupler.

Turn on biome display in ALT-F12, go to map view, and check?

AccidentalDisassembly: correct. When basemass is not set to (in the TANK_DEFINITION) nor overridden (in the MODULE) to -1, then MFT will set the mass of any part it is added to as: basemass + SUM(for each tank, tank.maxAmount / tank.utilization * tank.mass) When basemass is -1, MFT does not mess with mass. basemass can be set via one of two forms: if it is just a number, that is the basemass in tons; if it is given as some_number * volume, then the basemass of the part will be that product.

I used TACLS and liked it but YMMV obvs. You should definitely use EVE + a visual pack...