Cairol

1. KER (should urgently be stock) 2. RCS Building Aid (should be stock) 3. Precise Node or Precise Maneuver (should be stock) 4. Action Groups Extended (should be stock) 5. Docking Port Alignment Indicator (should be stock) 6. RemoteTech (because it adds realism and challenge to the game) 7. Kerbal Alarm Clock (should be stock) 8. Transfer Window Calculator (should be stock) 9. Interstellar Fuel Switch (with custom config for all fuel tanks - very handy) 10. kOS - nifty automation for making ones life easier Would have mentioned MechJeb here, but since KSP 1.1, it's kind of broken for me. Ascent guidance does weird stuff. It used to do perfect gravity turns. Now it's wonky as hell and unreliable for some odd reason. Maybe it has problems with the FAR aero model? It worked earlier however...

I played KSP for a good while now. but I also are on of those that hadn't got to Duna yet... I use RemoteTech. So I had the fear that my satellites would de-arrange themselves on their orbits when I do fast forward for years and years to get transfer windows for other planets. Now I cheated them into perfect orbital periods to avoid this, because I really don't want to reposition them each time I go somewhere far away. Another reason is, that my rocket designs all failed to make it to Duna and back. I need to make them larger with more d/v, and if I do so, it get's more difficult to get them to orbit in one piece. Then I had problems with my Nervas to overheat o the long burn. Then I had problems with the thin atmosphere of Duna to get a proper aerocapture wihtout overstressing the craft. So I failed and failed...a spiral of problems. I'm working on my satellite deployer to get there "soon", but I really struggle here. It's not like I don't want to visit those other planets... It's just that I'm obviously missing some strategies to do it properly. In those youtube videos it looks so easy. Those guys fly every brick and every SSTO to Duna. But I couldn't yet.

Hm. Would love to see this updated. I saw that cool video here and immediately had a couple of ideas for using this.

Does anyone know about a 1.1.x compatible "J's Specialized Suit Pack" or an alternative? It seems like "jfull", the author is inactive for some while. I loved those differently coloured suits for the different Kerbal classes.

I put a red and green nav light on every craft. Mostly on the lander stage. And I pretty much always add a HECS core or similar, even for kerballed crafts - just in case. And for kerballed crafts, I tend to add at least one KAS winch to secure kerbals on EVA to the ship plus KAS/KIS containers with spare parts. I feel better when i know that my little green dudes won't float away and are able to repair solar panels and stuff, if necessary. When using FAR mod, I always build my SRBs with an octagonal strut on top, then a nose cone on top of the octagonal strut. Then a sepratron within the octo strut to prevent drag by the sepratron. And yes, I know that the added weight for the octo strut is probably nullifying the advantage from the occluded sepratron. I do it anyway, because it "feels right". XD

As I'm using RemoteTech, I mostly have communication satellites with different sizes / ranges. They have - Usually 1x Communotron 16 or 32 for SOI / orbital coverage. - 2-x sat dishes. One pointed to "active vessel", one pointed to KSC, additional ones pointed towards other bodies, depending on their purpose. Aside from the antennas, my basic setup for most communication satellites is like this: 1x PB-X150 Xenon container (or more for larger sats) - If I go stock: 1x IX-6315 "DAWN" Electric propulsion system If I go NearFuturePropulsion: 1x IX-8219 "AFTER" Ion Thruster There are also older SAT designs in space with a "Spark" LFO engine. They work, but I would prefer Ions for almost every com sat today. - HECS Core (has raction wheels built in) - Solars (enough to supply all active antennas and other electrical systems plus some buffer margin for charging the batteries fast enough before going eclipsed. Type OX-4W or OX-4L for smaller sats or "Gigantor XL" panels for larger sats.) - Batteries (enough to outlast the darkness time. Usually some Z-200, Z-1k, or with NearFutureElectrical: B-3k, B-6k) - Some larger sats have RCS. But I would omit this in newer designs. Precise placement / orbital period tweaking is actually possible without that by using the thrust limiter. - Girders to have attachment space for sat dishes My larges com sats have 6 dishes and 1 omni to reach every planet. Two of them are in polar orbit around Kerbin as "main communications hub". The smaller com sats are in aequatorial orbits around Kerbin and the moons to give SOI coverage. Either 3 of 4 of them. 17 in total for the Kerbin SOI. I'm preparing a flight with my sat deployer for covering Duna. But I have to "practice" a bit more to get it done. My first kerballed scout vessel was doomed, because I used too much fuel on the trip to duna with inefficient / bad maneuvers. It's like it's rocket science or something...

Woohoo! Love it! I missed the symmetrical parachute spread and the control authority sliders for control surfaces. And I would also appreciate symmetry highlighting a lot. It helps greatly when doing complicated asparagus setups or other finnicky stuff. Thx, for updating!

I use standardized lifters. Why? because as a (real life) engineer, I aim for solving problems only once. So when I found a lifter setup that can serve a good range of payloads without having to change much (best case: Only change the fuel loadout), I can concentrate on building and buckling up my payload. Of course it's fun to build those crafts in KSP. And of course I also try other designs like using a space plane or SSTO to deliver my payload. But a lifter rocket is only a work horse for me that I need to accomplish my missions. So I'm better off re-using the design than to fiddle with the details of my lifer every time I try to bring a satellite into space. I of course have several lifter designs for the different payload weight ranges, but I only keep those that showed to be practical.Insert other media

I like that new feature. As I'm using Remote Tech, I often have to fly sensitive satellites or probes into space. Bringing three large long range satellites at once into space in one piece with my "sat deployer" craft was always a tricky thing.

- no air hogging - 120% re-entry heating - no obvious parts clipping for functional parts - rockets that wobble beyond sane amplitudes are strutted up or re-designed, even if that wet noodle can manage to orbit - Rockets need to have the "Abort" button configured in a way, so the crew capsule/cockpit can act as an LES, being able to separate from the rest of the rocket withotu harm in every stage of the ascent and must be able to land safely - no modded parts that are better than stock parts without appropriate drawbacks for balancing - not relying on SAS for planes / space planes to keep it stable and flyable (must be designed properly, except for fun builds like micro flyers / micro hover seats) - not relying on SAS for holding the atmospheric re-entry vehicle retrograde (CoM must be placed properly) - Settings and mods that reduce grinding are ok, as long as it doesn't make the game boring. (I don't like career much. I like to engineer.) - if the cockpit is intact after landing, it's a success, no matter the kind of deceleration that was used to come to a full stop - if the outcome is uncertain, don't sent Jeb, Bob, Bill or Valentina. Send a probe or a "redshirt". - no Kerbal gets left behind (Jeb counts on me with that. Poor guy had to wait months on the Mun once, because I misjudged the d/v needed for a return from his mission AND the rescue mission...)

"zero drag" actually describes well what I expierienced before updating FAR. Now it works. But it's really noticable that the atmoshpere is thinner. My starter rocket (nose chute, capsule, flea SRB) made the SRB explode upon landing, because I had still a speed of 8.6-ish. But now I have those other chutes unlocked in career, so it's managable now. Problem solved.

Nevermind. I installed the newest FAR version now and set a highter MIN altitude for the chute opening. Didn't know you can do that in the right-click-menu of the chute. The normal GUI is limited to 5000m. Now the chute had the desired braking effect, while not having any noticable effect before. Not sure if it was a bugged FAR version (first version for 1.1) or if something else misbehaved. I'm aware of the thinner amosphere of Kerbin from the changelog, but I have no feeling for it yet. So thanks for the advice.

I updated KSP to V1.1 and installed FAR, because I always used it in the past. So now I started a new carrer and I have a big problem there: I can't even get my first basic rocket safely back to the ground. It's just a capsule with the starter SRB underneath, three small wings and two goo containers for science. I reduced the SRBs power to get a 1.2 TWR on liftoff and have a nose chute attached at the only available attachment point. I can get up to about 8k meters with this setup. My chute opens at 5000 m, but is not able to slow my vessel down in the slightest. When it reaches 350 m/s in free fall, the chute burns up and I crash. I did not play without FAR yet in 1.1, so I don't know whats with vanilla behavior. But did someone else have this problems with FAR in 1.1? Any tips on how to get that rocket back to the ground in one piece?

The last version I tried was "Goldstein". So I guess I'll give the current version a go. I'm really desperate to get FAR back into the game, as it makes things more predictable for me. It feels more real than vanilla and makes more fun, although being a little less forgiving for flawed designs than vanilla.

I also get blurry / frazzled text with 110% and 120% UI scale with my 23" 1080p panel. But with 100% scale, the UI is simply too small, while the nav ball is too big and noticably low-res / blurry too. The app selector buttons on the right are too big. And I also noticed, the preview images in the parts selector (the animated preview) is super-low-res and non-AA. Don't know if the latter was already present in V1.0.5, but it looks pretty cheap and is somehow distracting.

Same procedure as every update: Is the "heating exaggeration bug" that caused parts to overheat and explode spontaneously no longer happening with KSP 1.1 and FAR? That nasty KSP bug which was made apparent by using FAR was the reason for me to abstain from using FAR since a couple of versions ago. And I'd love to be able to use it again...without having my stations blow up.

I guess after you proved your successful completion in the respective challenge thread, the author of the challenge acknowledges that. And then you are allowed to copy the badge from the challenge thread. It's usually provided in the first post if there is a badge. So you can insert it in your signature if you want.

MechJeb with FAR definitely needs other settings than without FAR. For me it works when I limit the AoA in MechJebs Ascent Guidance to 3° or even less in extreme cases. Also, enable corrective steering and limit speed to termial velocity. Let MechJeb not turn the rocket below 4 km. (edit ascent path). Make sure your rocket is inherently stable by looking at the center of mass and center of lift. CoL should be as far away as possible from the CoM and CoM should be in front of it. Especially when the first stages tanks are empty, there should still be some margin between the CoL and CoM to reduce the tendency to flip. But I guess you already know that. Also use struts to make your rocket stiffer. MechJeb has a hard time getting your rocket to space if it bends like a sausage during ascent. Limit your engines power if necessary to get a TWR of 1.5 to 2.5 for the ascent stage(s). Personally, I try to achieve a starting TWR of 2.2 or so for the lower ascent stages (SRB boosters and primary LFO ascent stage). And I usually do the initial angle correction of just 5 degree or so myself at 3-4 km and activate MechJeb not until I reach 10 km. This will cause a not 100% optimal gravity turn, but for me it helps to prevent MechJeb to turn the rocket too early and thus causing stability issues because of the still low speed at 3-4 km. (As the ascent path set in the ascent path editor never seemed to be respected by MechJeb for some reason. At least that's what I expierience.) You have to tweak those settings I gave here for your own ascent technique. But for me it works OK like so. But nonetheless, MechJeb makes my rocket oscillate much more than a manual ascent with active SAS does. MechJebs stability controller is better than the stock SAS but also more aggressive with default settings. (and I would not recommend to mess with them...) For me, limiting the AoA helps with keeping this under control.

I guess it might be tricky to preset those sepratrons to deliver the exactly needed thrust so you don't crash and also don't get accelerated higher than you were before the ignition.

The good old Saitek Cyborg 3D and Cyborg evo both work well for me.

AGC 1.33a with KSP V1.0.5 gives the following exception and prevents exiting the VAB or SPH: NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXEditor.Update () [0x00000] in <filename unknown>:0

Hm. Guess we have to omit insta-staging now and double our stages to be able to wait for a little distance to the staged stack. I don't like to ride to space on explosions. :/

I also noticed somehting like this several times in the oceans of Kerbin.

If I were you, I would setup 3 aequatorial system-range com sats for coverage and 3 polar orbit inter-system com sats for connecting to KSC for every planet. And at some point you will want to setup communication command centers at some of the planets to keep the signal delay down to a resonable value. So connection uptime to KSC is no longer that important. (given you don't want to go ultra-hard-mode) Setting up 3 sats is barely more effort than setting up 2 of them. So I always go for the increased com link uptime and deploy 2x3 sats per planet. It will also help for ground missions with rovers. With only 2 polar sats, a rover at one of the poles can be dead for hours.

The link of Alshains first post is my way to go. It delivers everything you need to plan and insert your satellites precisely where you want them, plus you can calculate your needed battery capacity for 100% uptime.