Cairol

I had three Kerbals sitting on Mun and waiting for rescue for years. Today I managed to get them home. But it was not as easy as I thought. I built a rocket that was unmanned and RemoteTech-Controlled, because I wanted to use my new cool Munar satellite network. So after multiple tries to land near the crew pod, I managed to get near the pod. Halson, Raxie and Thomhat used their Jetpacks to fly the remaining 900 m to the rescue lander. The first problem arose on the first try to land on Kerbin. I had conveniently placed my antennas in a way so the were garantied to burn up during aerobreaking in Kerbin atmosphere. And why did I place the atmosphere-capable DP-10 antenna on my ascent stage instead on my lander stage?? And without antennas, I could not burn my engine to break, could not deploy the parachutes and SAS would also be non-functioning. I learned this during my first 5(?) attempts.. That, and that a direct landing coming in with orbital velocities is not the best idea.. So what to do? I pre-programmed my parachutes to open at some pressure and height which I believed should be good and armed them while still beeing in Mun SOI. That way prepared I flew over to Kerbin and did one initial aerobreaking maneuver. During that meneuver I lost my omnidirectional antenna, but my DTS-M1 was still intact. So after coming out on the other side of Kerbin, I regained control over the vessel and could do last preparations. Like turning retrograde and decouple the bulky lander tanks / engine. After entering the atmoshpere once more, there was nothing I could do from this point on as I lost connection to KSC again. It was quite a ride. I entered the atmoshpere at about 3200 m/s in a flat angle. All radially attached parts except fot the parachutes dissolved in hot air during my descent. All I could do was hoping, that my programmed pressure levels for the parachutes were suiting my descent profile and that my return stage would not flip head-first during re-entry. And it worked! So all three Kerbals were finally safely on the ground. Man, what a relieve...! Next time I definitely should stick the DP-10 on my lander stage instead of my ascent stage... BTW: How can one embed an imgur album here?

I normally keep SAS active when leaving the craft. Especially when it's a space station or a satellite that was optimally turned towards the sun. I know KSP stops movement when a craft is not active, but it's just my paranoia... The control values I mentioned in my first post are from the Stock Bug Fix Modules Mod. Didn't realize that until now. Now that I know what they do, I'll play with them a bit more.

Like I said, I use the build-in reaction wheels and it's wiggling with those in the above mentioned example. (HECS core + 1t satellite)

MechJeb has a "Stability Control" option in the Rover Autopilot module. I use it in my Munar circumnavigation and I feel like it's doing better for a ground based rover than SAS does. But I don't know if only the controller is more balanced than the on in the stock ASAS, or if it actually is designed to help with driving. Can someone confirm this?

This is not something serious, but I'd like to figure out if there is a solution: When building very light crafts or satellites, when turning on SAS in stability mode those crafts / sats begin to wiggle a bit around their current orientation as if the controller of the SAS overcompensates continuously, which is slightly annoying. Heavier crafts are held steady by the SAS. I mostly get this problem with light satellites (about 1t mass) with for example an HECS core with the integrated pretty weak 0.5 kNm reaction wheels. Changing those three control values for the integrated reaction wheels did not help at all. Are those actually mappable to the common Kp, Ki and Kd parameters? Is there a way to prevent this wiggling?

I outfittet Minmus with a satellite network. Directly before decoupling the third of five satellites, I accidently hit the "SHIFT" button and decoupled the satellite, resulting in me wondering why the sat was not being propelled by the separator and drifting away as usual. When I figured out what was happening, I stopped the engine of the ship and wanted to switch back to the satellite. The satellite has already been accelerated so much by the ship pushing it, that it was on a course leaving Minmus SOI in some arbitrary angle. And KSP somehow did not let me switch back to the sat. No button was appearing. Going back to the Space Center did not fix it. So the sat was lost. I placed the remaining two satellites in polar orbit, flew Neilcott home to Kerbin and did another flight to bring the last satellite. All went well. But I somehow managed to switch orbital direction at Minmus on my insertion burn without noticing it. After deploying the satelite, I recognized my error. I was so upset that I failed again, that I dismissed the satellite instead of trying to correct its direction and orbit. So next time I need to send a third mission to get that third aequatorial satellite set up...

Orbiting Mun in a small command pod for ages now. Not enough fuel to get back to Kerbin. So I have to rescue him. Another 3 kerbals are sitting on the Muns surface in a large command pod lander for the same reason. Jeb actually was meant to rescue them. But I miscalculated the needed d/v for the rescue mission too... So I have to send a rescue mission for the rescue mission. But "KESA" does currently have other priorities. XD

I currently run an nVidia GTX 580 which was highest-end at times. It's still more than sufficient for KSP, but it's 4 years old now and meanwhile far from high-end. Next year I probably have to build a new PC to keep up with those new top-notch gaming titles. With one exception (ATI Radeon 9700 Pro) I always had nVidia GPUs in my PCs. My subjective opinion is, that nVidias drivers are generally better and more games work perfectly with NVidia GPUs than with ATI/AMD GPUs. Technology-wise both brands are on par. Which is good for us consumers, as they are always wrestling for the better performance and efficiency. Another thing why I use nVidia: I never liked AMD. I was always an Intel guy (also with one Exception: AMD Athlon XP). So when AMD bought ATI, I automaticly began to dislike AMD GPUs too. No real reason for that. It's just a fact.

I thought Swat fixed this "increasing inaccuracy for outer regions" by dividing the space into several patches with their own center for calculations to reduce floating point errors? So I basicly have to live with this and hope the satellites will not de-synch in the forseeable future...

- Parachutes with integrated drogue stage and adjustable deploy/cut altitudes for both chute stages. Also inline parachutes (good one, @MalfunctionM1Ke). - More 1 and 2 seat control pods (inline and normal ones) - More sizes for crew cabins - Oxydizer-only aviation fuel tanks (Mk1, Mk2 and Mk3) or beeing able to distribute both fuel types freely for the total volume of a tank. - Stack Bi- Tri and Quad couplers for 1,25, 2,5 and 3,125 m radial rocket parts in both directions. - Stock nav lights with low power demand, just like the NavLight mod - More height profiles for inline RCS tanks with respective capacities. - more specific rover parts, especially for smaller rovers - more sizes for structural parts (girders, panels, attachment points,...)

A short question: Yesterday I set up a satellite network around Mun. And while fine tuning the orbital period of the sats I noticed that the period was fluctuating by several seconds while the satellite was orbiting the Mun. From my understanding, the orbital period should be perfectly stable down to some milliseconds if the satellite does not accelerate or rotate by active control inputs. (RCS off, Engine off, SAS stability mode enabled) My orbital network around Kerbin has super-stable orbital periods for all satellites. I was able to fine tune them down to a couple of milliseconds. The jitter of the shown values is miniscule. But around Mun, it's not that stable. My fear is, that those satellites will de-synch while on fast time acceleration during longer interplanetary transfers, because the deviation is in the seconds area. Why is that?

Staging error. "5..4..3..2..1..and we have liftoff of the Munar Explorer X2 .... erm ... launch escape system!" *cough* *cough* "No that we successfully tested the LES, the actual launch will commence in only 2 hours..."

From my expierience, SAS on rovers is semi-helpful at best. It does behave pretty much the same as if it was used in a plane. In stability mode, when moving over the top of a steep hill at some speed, it will try to maintain the direction of the rover and thus preventing the front part to sink down to the ground. If the reaction wheels/RCS is stong enough, your rover will sink down on the other side horizontally. Bad for your front tires, as they will have no contact for a longer period of time than without SAS. But good for your rear tires, as they will not be lifted as much as they would without SAS. When turning on sloped terrain, it will also not adapt to the needs of a ground vehicle. It can even make thing worse. It will always try to stop any externally inducted change of orientation, except for active player inputs. The only real application on the ground is, that it will stabilize your current horizontal direction on fairly even ground to some extend when driving over gentle humps that do not make your rover to take off. SAS on the ground is not what you would need for a ground vehicle. It's (sadly) not an ESC or a TC-like system. A TC system will always try to maintain grip of your tires during turns or acceleration/breaking by reducing power of the engine or selective breaking of tires. An ESC will try to maintain grip of your tires and additionally will try to counteract forces through every available control system that would otherwise lead to a loss of the current driver-inducted "directional request". I never expierienced SAS acting in such a way in stability mode. So from what I can say, SAS has no appropriate control mode for rovers on the ground. But I would really like to see such a feature in the future.

My Mun- and Minmus rovers have enough SAS power to roll themselves sideways back on their wheels. I'ne not build high-g rovers yet. But I probably would use the large landing gear as a flip-device.

Try this. To get a better understanding of basic orbital maneuvers, I also suggest you search Youtube for a KSP beginners tutorial. For example:

Even for a beginner I would highly recommend to install the following mods: - Kerbal Engineer Redux (important readouts of your craft while building it. Gives you an idea if your rocket will lift off, if it will be able to reach orbit, how far you can go with your rocket, and much more.) - RCS Build Aid (Shows center of mass and also "center of dry mass" of your craft without having to empty the fuel tanks manually to see it. Good to detect flip-happy rockets at design time. Works with KSP 1.0.4) I would start in Science mode or Creative mode. The first one is more rewarding if you achieve something and you don't get overwhelmed with all parts of the game at once because you need to earn science first, to unlock higher tiers. Creative mode removes the tediousness of earning science, but removes also the achievements. All parts are unlocked from the start. Also, a must-read for new rocket engineers to avoid early frustration: KSP Aerodynamics and Aircraft design in pictures

I've no pictures. But I managed to regularely leave the runway with my SSTO to the left at > 100 m/s during the start. And if I managed to get it airborne in one piece, it was not perfectly stable during sub-sonic flight and suicidally twitchy at super-/hypesonic speeds, messing up my ascent a dozen times. So I checked every single part of the craft for symmetry errors, checked my wings, replaced a lot of parts to be 100% sure, checked that my fuel is evenly distributed, made the craft more rigid to prevent mis-alignment upon landing on the runway after physics enable when the scene finishes loading, checked my control surface settings and some things more. No luck. It always veered to the left slightly, often resulting in a RUD on or alongside the runway. Finally I thought, I should check the control indicators at the next start. I didn't use the joystick at that time, but it was connected to the PC and configured in KSP. Turned out my joystick had a slight slight mis-alignment for the center of the "yaw" axis. So the game always registered a minimal "yaw" control input, messing up my controls. After increasing the dead zone, the craft was perfectly stable.

My current design works ok until now. I take it more cautiously now and only accelerate to > 10 m/s on really flat terrain. My calculations say, that I will need about 25-35 real hours to get around Mun. So I have still a lot of time to worry. The thing with this challange is: The gray surface of the Mun is boring as hell. But I need to concentrate 100% to not go flying and destroying my rover. So I usually drive no more than 1 real hour per day. I don't want to quicksave every 100 meters. So I got used to a slower, safer pace. I'll set the thread to "Answered" as I now have some good tips from you to improve my rover further, should I fail again.

Good to hear. Because I love my bi-coupler shock-cone twin-intakes. They look cool and it seems like their drag is not so bad. What I didn't expect was, that placing a cone at the back of for example a R.A.P.I.E.R will reduce drag. Problem with this is: I don't like to clip parts in an unrealistic manner. :/ Really great information here Yakuzi. *thumbsup*

Some really good tips here. I'll see how I can reduce drag and become more efficient. The second SSTO shown by Slashy shows clearly that my design is far from optimized... Never could have imagnied that one Rapier could bring three times the payload to LKO than my design. Óó According to the wiki, all small solar panels have the same drag. Does KSP evaluate the exposure or form of external parts and differenciates for example between wing-mounted solars and side mounted ones? I didn't attach that much importance to those small parts (drag-wise) annyway. Guess I should have. I'll definitely try that "incidence angle" thingie for my wings.

I just found something really amazing. I don't know if this is the correct forum section. A Mod may move this if not. This guy is docking a segmented airplane made of 4 parts together in Kerbin atmoshpere in mid-flight. Never seen such a thing before and wanted to share this with you guys.

I run remote tech and I have no connection on the backside of the Mun. That's why I fly kerbaled and that's why I bring those satellites to the Mun in the first place. The drone core is...well, just for emergencies and for fun in this case. I can test my orbital network with it after deploying all sats. (two more in polar orbit will follow) I want to deliver them by the space plane to be able to place them precisely in 120 degree angle to another in orbit. For me, thats best done with a deploy vehicle in Mun orbit that has a third of the orbital period of the satellites. So I can drop one satellite each time my ship is reaching the AP marker and only do the fine tuning with the sats after deploy. I've done that a couple of times now on other bodies to get my orbital network up and running. The Terriers were intended for slightly more efficient space burns. I don't need them for the ascent. But I guess it does not matter much on that short trip. So I'll discard them. I tried it with only two Rapiers. But my TWR was too low to get to space before running out of fuel. I'll see how I can cut down the mass of my craft.

Normally I go with rockets, because I'm not very expierienced with space planes. But for fun I decided to build a space plane to transport 3 communication satellites to the Muns orbit. Technically it's an SSTO, but that was not a "must" for me in this case. The payload is only 3t total. My space plane has a mass of 43,600 kg, which leads to a payload fraction of 0.07. And the ship does not even have enough LFO in the current form to get to the Mun and back. It barely brings me to LKO without circularization. Means: I even have to stick more tanks on it, making it heavier than it already is, probably leading to sticking on even more engines, and so forth... Before you ask: My ascent profile is this: Climb at 40° to 9-11 km, level out and speed up to 1000 m/s, climb at about 25° till 22 km, switch to closed cycle and accelerate to 1600 m/s, climb till reaching target AP. Don't know if this is efficient at all... And now I wonder what payload fraction is considered "good" for a space plane. And if someone could tell me a rule of thumb how much d/v and how much LF and Ox I need in total and in relation to each other to get such a space plane into orbit, it would help me a lot with my building phase. A good video tutorial on that would also be helpful. I like flying space planes to orbit, because it's much more "work" to do than just using a rocket. But I obviously need more expierience on how to create efficient designs.

Tried to fly a basic space plane to bring three micro-sized short range satellites up to the Mun. Seems like my ascent profile was a bit too aggressive. My Mk2 cockpit with Phlipp and Mellanie was destroyed by rapid overheating. There is a probe core installed, so I wanted to at least bring the rest of the craft home. Sadly I forgot to bring an antenna with me and so had no connection to the KSC ....

Too bad I sold my good old TI-82 13 years ago. XD If I only had known... Does this also run on the TI-92 or Voyage?