Frederf

I would definitely use this mod if there was a transparent version that was designed to sit on top of the navball to combine its data with the navball as layers.

I find MFS indispensable for creating "test masses." These are basically configurable inert objects of the desired mass that won't be considered in any KER dV calculation. You get a simple fuel tank that's big enough (or even better a stretchy) and fill it full of some weird mass of fuel none of your engines use (e.g. Aerozine). Then by manipulating the fill or stretchy height you can make an exact test mass. Saving these test masses as sub assemblies allows them to be referenced later. I use them for reserved fuel quantities, landers, satellites, etc. Properly shaped test masses can be flight test articles. You can even use test masses to provide allowances for designs yet to be conceived (lander will be 7MT or less) and then build that assembly later to spec limit.

OP suggests that the docking ports are enforcing an alignment. Unless something has changed recently in v .23 the docking ports do no enforce an alignment at all. Any rotational position is possible.

404 on the download link

Is the AblativeShield resource tweakable as to amount/max in VAB?

I call my Jeb/Bob/Bill contraction the "visitor's center" where little Kerblings can visit their space heroes. Meanwhile the ol' whitesuits are doing the heavy lifting.

I have hope that this is the future of KSP resource gathering.

If you go through the math of TWR vs maneuver cost the optimal solution is generally a very small TWR. Spreading a maneuver over minutes or even hours takes sophisticated planning in many cases that few see as worth it. The difference between 30 kN and 1 kN engines in terms of dry mass on a ship of 5+MT is rather tiny if the Isp s are the same. For reasonable space maneuvers I keep TWR between 0.1 and 1.0. For landers you want to tailor TWR for controllability relative to the surface gravity at destination. Too low will burn excess fuel in the transition as well as make timing the retro burn difficult. High TWR will make touchdown tricky.

The two sentences agree. One way of thinking about the Oberth effect is that you add more orbital energy when going fast (per m/s added) so burning is most efficient energy-wise when fast. You are the fastest when your kinetic energy is high. Your kinetic energy is high when your gravity energy is low. Your gravity energy is low if you are down in a gravity well (falling down speeds you up). Kinetic energy is non-relativistically 1/2mV^2. Going from V = 1 m/s to V = 2 m/s and from V = 999 m/s to V = 1000 m/s both require 1 m/s delta V. However the difference in energy in the first case is 3 units (2^2 - 1^2) and in the second case is 1999 units! (1000^2 - 999^2). By going faster you got 666x the energy from the same 1 m/s delta V! Even if you can't hit planetary transfer exactly from LKO it's much better to guess and get close and do some fine adjustment in solar SOI. Also that is a very very very VERY cool graph which shows the difference wonderfully.

I'm going to try adding a lot of empty stages to my craft when I apply a subassembly so that the subassembly stages land in the empty slots (say 2-10) and leave the existing stages (say 11-20) unmolested.

You want to do A. You want to do as much burning as possible in the deepest gravity well possible. Your orbital energy is either gravitational or kinetic so kinetic is maximized when gravity is minimized. Co-planar interplanetary transfers are most efficiently done by adding escape velocity+enough more to achieve the transfer orbit. You can think of being stuck at Kerbin's solar orbital speed while in its SOI. To do an interplanetary transfer you need to escape the SOI just to get to square one. All your velocity inside Kerbin's SOI is worthless because it's captured so you might as well use it for an Oberth effect boost to puncture through the SOI boundary and keep going. Oberth savings are non-intuitive so you'll have to do a few math problems until the pattern becomes familiar.

That's how it works now? I can break up a collapsed group with a single click then adjust highlighting with other clicks and then drag the subset of the collapsed group.

Is there anyway to close the ECLSS map scene GUI? It's undraggable and unclickthroughable.

I tried Utilization = 13.0 and it didn't seem to like it. I wonder if 0-1 is the acceptable range. Utilization is supposed to be how much of the total tank volume is usable for the useful volume. 1-Utilization = Volume dedicated to structure

Hmm, since ECLSS doesn't use volume in its calcs it should be a simple matter to adjust the density of the Oxygen resource to tune how much of it fits in MFS volumes, right? I have to be careful because it looks like "density" is already taken by the mass/unit value. It looks like MFS assumes one "unit" is a certain "volume" and ECLSS is not made in that convention. Unless I'm missing a way to change mass-unit-volume relationship completely independently I'd have to scale the unit counts to make it all work.

Something is amiss with MFS and the Oxygen resource. To hold the equivalent of the small O2 tank (400U) you need to use the FL-T400 Squad tank which could be the house the former lives in and have done rather well for himself. To achieve the 1200U in the Mk1-2 pod the entirety of the pod would need to be devoted to it (one and a half X200-8s for comparison). The closest container to the small O2 ECLSS is the KSPX StratusV at 40 units of volume and is roughly 25% bigger. To get parity about 13x as many units need to be packed in to the standard fuel tanks. I do wish there was a smaller O2 tank. The smallest is quite big. Something akin to the bottles above the hatch on the ALCOR lander body would be dandy. This life support mod also follows the pattern of previous by putting excessive amounts of oxygen internal to the pods. 400U per Kerbal is something like 7.5 days which is enough to orbit from Kerbin to the Mun 12 times before the thought of an external support supply even enters the mind. Why would I bother with extra? I figure how you balance this thing is by taking three cases: A Internal supply mission B External supply mission C Interplanetary regeneration mission Find what's a reasonable limit for mission A and tune internal supplies for that. Construct a craft that looks like a reasonable O2 burden for Kerbin-system travel and compare it to the duration of mission B to tune what parts hold what quantities. Finally make a reasonably burdened craft for Interplanetary travel and this time your free variable to tune is the regeneration efficiency so that X units last Y time. If successful the tuning should yield short mission duration on internal, local planetary system mission duration with enough external tanks to be a design consideration but the regenerators aren't mass-justified, and interplanetary mission duration where regeneration is all but mandatory with a significant but not ridiculous appended supply.

Check my math here to make sure I got it right. Kerbal is 93.75kg. Monopropellant is 4kg/U. Assuming Isp of 100. EVA Pack provides 600 m/s dV. dV = Isp * g0 * ln(Md+F/Md) 600 = 100 * 9.8 * ln (93.75+F/93.75) 0.6122 = ln (93.75+F/93.75) 1.8446 = 9.75+F/93.75 F = 79.18 kg of monopropellant F/4 = 19.8 U of monopropellant === If the above assumptions and math are right a full EVA fill up should take about 20U which seems more reasonable that the roundified tank holds 40U. I still think it's silly that the EVA pack holds 600 m/s dV. At 1/5th that much it would hold 4U. I really like the feature and would rather it stay in until Squad's change comes about. Having the EVA fuel matter would be a welcome change. If you modify the exchange ratio after double checking the arithmetic it improves. What would be nice however is an ability to select your fill. If I want to use my 50U MP to partially fill two EVA packs on simultaneous missions it would be welcome. I've found that RCS is mostly worthless apart from docking because all the reaction wheels are so OP.

Is it possible to make a "lite" version of this mod only for the purposes of transferring crew within a craft? I have no interest in managing crew outside of the astronaut complex or at the prepare launch screen. I was thinking a third button on the portraits "IVA" "EVA" "XFR" and then clicking the destination part. It would be very slim and minimalistic.

I believe 100% EVA fuel is 100 units of mono-propellant which I think is too much. Based on a certain ISP assumption and mass of kerbal I believe someone's worked out what 100% EVA fuel equates to in MP units and it's near 1.0.

I think the control system should be applied to the engineering the aircraft end of the problem and leave FAR to the modeling of the environment itself. I'm a firm believer in keeping environment modeling apart from usability aids. If it were up to me FAR would be split into mandatory environment interaction and optional support. It should be possible to fly in a 1910-style setup where everything works as it should mechanically but without any graphs and readouts if desired.

Welcome to the joys of vector addition! For the most part you simply burn a heading which matches your desired inclination. East is 0, West is 180, North is 90. There is a correction angle you need because you're already moving eastward on the launch pad. I use this site as a simple tool but you could do it with paper and pencil if you like. http://www.mathsisfun.com/algebra/vector-calculator.html If I type in 174.5 length vector pointing right (eastward, aka 0° in math land) and add 2300 length vector pointing up (north, aka 90 in math land) then I get a resultant vector of 2306.6 at ~86°. Remember that that's 86 degrees counter clockwise from math-zero which is 4 degrees clockwise from navigation-zero (aka north). So if you aimed heading N from the launchpad at KSC you'd miss to the east (right) by 4-5° and end up in an 86 degree inclination orbit. The quick answer is to aim west (left) of north by that same margin to cancel this effect. More exactly you should adjust your traveling vector so the resultant ends up in the direction and length you want. I used 174.5 because that's the surface rotation at equator and 2300 because that's about horizontal orbital speed added to get 70x70. Now if you want to change the RAAN which is where the ascending node is, then it comes down to timing. If you're burning northerly and want RAAN at 0 then you take off at midnight (solar antipode) delaying up to six hours if you want a RAAN between 0 and 360 proportionally. If you are burning southward then the ascending node is on the opposite side from launch so everything's shifted 180 degrees.

Actions on the Fly mod version 1.1.1.1 or the newer similar mod that is WIP. http://forum.kerbalspaceprogram.com/threads/24882-Actions-on-the-Fly-Edit-your-action-groups-in-flight-mode http://forum.kerbalspaceprogram.com/threads/60593-WIP-ActionGroupManager-%28AGM%29-initial-release No way to do it stock.

Is the IVA supposed to look unfinished in 0.6 or did I screw up and not install the necessary props, textures, whatever?

For those that want EVA-able struts I point you toward the KAS mod.

Cd is C coefficient for d drag. It's a ratio of your drag vs. a reference plane of the same cross sectional area and would only be a number you'd have access to if using FAR. I recently came across buggy situations where my Cd and thus total drag was super low so I spent forever at high speed during DRE reentry which was practically impossible to survive. Since you're not using FAR and/or procedural fairings I doubt that's what's happening to you.