Spricigo

Not the case since 1.2 when parachutes got the (default) option "deploy when safe". Just to be sure I straped a 'pod'(extructure, probecore, parachute and decoupler) in a fast plane, get up to unsafe speed for deployment and staged (decoupler+parachutes), as expected parachutes become 'armed' at decoupling and deployed once the pod slowed enough. Still a good idea to slow down to easily maintain the pod in physical range until touchdown, but irrelevant for parachute deployment.

I'd suggest to stay in control of the carrier, drop the pods, return and recover the carrier and then proceed to the instrument reading. Also, I consider the cargobay a luxury, decouplers attached to the fuselage or wings can do the trick. Alternatively, if you don't mind mods: Another possible approach its using some mod that automagically run science experiment and just briefly touch the desired area for the 'landed' science. But for this you also need to be confident enough you can avoid crash when trying to touch&go.

If memory serve me well, the Radiator will l cool the fuel tank and it's child parts but not the parent part. So if you attached the tank to the converter it may be your problem.

Well, no one drive a rover because its convenient. IF one is paying minimal attention (what usually is the difficult part).

QFT However, worth noticing that KSP's control scheme sometimes get in the way of following a flight plan. Let me say thank you. This very post you linked was a eye opener for me. After that I build a SSTO spaceplane, not my first but the first one I liked(actually pretty similar to your design above). Thank you for convince me that less wing is more. I’m still experimenting with some ideas based in this design philosophy but its already a game changer. Of course your reason may be the challenge or the rule of cool. But, after designing a SSTO you like, notice that drop-tanks by itself aren't a bad thing. Going back to business: if results in lower cost* for mission go for it. *Cost its not always funds. How much you value your time or how much you like doing something in a particular way often its more relevant.

The problem is that the location is moving. Try to predict where the location will be and adjust your trajectory accordingly. Also quick saving before executing the maneuver is advisable.

[ Toque] =[moment of inertia] * [angular acceleration] To maintain your craft pointed in the correct direction you need reduce the torque to 0. If you cant align thrust with the CoM you need at least make it so your reaction wheels and control surfaces can counteract it.

Small correction: torque depends on the thrust and how far from axis of rotation(center of mass) this thrust is. Mass(and how is distributed) is important because it determine how difficult will be to turn your craft. Notice: CoM in range of the gimbals means you can reduce the distance between thrust and axis of rotation to 0, eliminating the torque.

But you are not only pushing against the part of the atmosphere behind you, if fact don’t matter how hard you are pushing against the atmosphere because you are pushing in all directions.

I'd say you should consider (T-D)WR.

I’d say quite the opposite bring less parachutes. While the mass of the parachute itself its not much when you consider the the extra fuel you need to haul the parachute its usually better to rely on a powered landing. Also, as noticed in the attempted landings of the op, parachutes are no good if you don’t slow down enough to deploy it safetly. My suggestion its to get rid of all those parachutes (except the one for landing on Kerbin) and add 2 (to keep it symmetrical) radial Drogue chutes. Use the parachutes to ditch some of the speed and complete the landing with the engines. Also, deltaV depends on engine Isp and the mass fraction (as explained by @Streetwind ). If you cut the total mass of your vessel in 20% it can do the same (e.g. liftoff from duna) with 20% less fuel. However lighter craft will turn more easily and loses speed faster(and more) when aerobraking. Some other pointers: -I strongly suggest to disable yaw, pitch and roll on RCS thrusters and let the reaction wheels handle the rotation. SAS over-correcting itsel and the rotation caused by thruster misalignment waste a lot of monopropellant. If the idea its to prevent the craft from flipping during the reentry design it to not flip in the first place (heavy parts in front, drag parts in rear). -mk1-2 command pod is offensively heavy, consider using a different command pod (or probecore) with crew cabins and reaction wheels for the same result. -When using nuclear engines also use liquid fuel only tanks to reduce the mass and bulk. -coming directly from high orbits means entering at higher speed in the atmosphere, lowering your apoasis to 60km and then your periapsis into atmosphere may greatly improve you chances of surviva.

Another possibility, instead of changing the range on settings use modified antennas. (I suspect configs may do the trick)

No, you don’t need to fix anything if the info it shows is correct. No matter what you do with the graph people will still get it wrong if they keep reading "bananas" when you write "watermelon" (which is exactly the issue there). That said : -the legend, I suppose, is meant to tell "vertical axis is altitude (in meters), horizontal axis is time (in minutes)" but actually says "blue line is time, orange line is altitude". -I think a Altitude vs Speed graph would be a better way to present a flight profile. Another possibility is Attitude vs Speed. Time is not as much relevant IMHO -There is a few ways to read the distance from KSC, some mods may be usefull (waypoint manager, KER, etc). Or you can calculate it from time and speed.

I'd like to also advertise Dmagic's EVA Resource transfer , it requires a engineer to plug the hose instead of docking, but have the same advantage of refuelling all the tanks at once.

Yes, I know it. But I was expecting the trim to be zeroed since I didn't touch any control after launching the craft. AFAIK is not possible to set trim at SPH/VAB (or I’m wrong?) so something else need to be the cause, no gamepads/joystick also. Maybe some mod or a different program (e.g. Steam overlay? Skype?) Anyways, after noticing the unexpected trim, the solution was automatic (alt-X) and, since happened only with this craft, I just cleared it from my mind.

Actually the highest detection rate its the Probodobodyne RoverMate with 100% followed by the MK2 Drone Core with 48%. Granted it have less FOV.

Actually they need to climb like a rocket in the rocket phase, just that at the time a rocket will be going mostly horizontal. Also, I see your point but this is because of people misreading the graph. People will think in distance, while the graph clearly is about time.

Recently I had a plane doing this... I added aerodynamic stability, changed wheel friction, even rebuilt parts of the craft that would be a hair out of alignment and nothing solved it... Then, after a couple hours messing with the design, I noticed my ruder and yaw indicator in a unexpected position. No idea what caused it.

More than sufficient. Actually some problems with rounding numbers may produce a noticeable disturbance on the orbit much sooner.

Since your main concern its how much real time it takes I'd say to get all scientific instruments you can unlock and a scientist and strap it to a big enough fuel tank with a big enough engine. Add a strong reaction wheel and probecore with SAS for convenience. @Warzouz example even have some luxuries I would not bother to add I actually would use a rover since I'm using this mod: But using a rover without it just takes too long to my taste.

I had a few instances recently where the game crashed when recovering a vessel with a rescue. When loaded the game back the contract was gone (didn't check if completed of just disappeared) but the craft was still there. Maybe something similar happened to you.

I'm a big fan of Dyna Soar alike and MAKS alike designs. Just keep in mind: heavy parts in front, drag parts in rear.

personal addition: 4 basic fin at the bottom tank (cheap, lightweigth and helps with stability) also this guide my be usefull:

The MPL its both: -Overpowered, because it may quickly and easily produce enough science to complete the tech tree and then keep producing science that can be 'sold' with strategies. -Underpowered, because game resources are so easy to obtain without even bothering to setup research stations. But the real 'issue' here its not MPL, its TimeWarpToWin (TWTW). There is recurring cost, in funds or otherwise, one need to worry when timewarping, no salaries, no equipment wearing, no orbit decaying, the agencies don't stop to offer contracts, kerbals don't retire on old age . Personally I don’t think anything of this is necessary but its something can be done with mods or just roleplaying.

Well, that is the case for the build spacestation contract, however for the expand spacestation things maybe different. I will probably check it out for myself but my reasoning so far: 1.Only the craft with the required ID will complete the contract. Even if the game check the age of the craft, the age the station have when the contract is generated need to be valid. 2. Two vessels docked together become one vessel with the age of the older vessel. A module newer than the station will preserve the age, which is valid. Now to clarify the situation I'm considering may not complete the contract: I have two station in orbit: Mir is 2yo and support 5 kerbals, ISS is 1yo and support 10 kerbals. A contract is generated asking to expand ISS to support 15 kerbals. What happens if I dock Mir and ISS together? My supposition is that the resulting craft will have be considered Mir, so it will not complete the contract. However I think the game keep track of the ISS ID, if nothing else to reassign the correct ID when undocking, so the contract will not end in failure when docking Mir and ISS together.