RexKramer

Watching.

I've had good results using the Claw to secure vehicles in cargo bays. I put a claw on the rover, drive up the ramp, and clamp on to the front of the cargo bay. This has worked well even for fairly heavy rovers, like miner/refiner units. One downside is that I haven't figured out how to build ships with an active Claw attachment, so I have to launch the rover separately, then drive it onto the aircraft. Works fine, but would be a problem loading onto a verticall launched rocket. That would probably also work if the Claw was mounted to the aircraft instead of the rover, haven't tried that yet.

That is a really interesting question, unfortunately I don't have a copy of 1.0.5 to test that out on. Here's a couple of suggestions though- 1. Make a BACKUP copy of your 1.0.5 save file, in case something goes wrong. 2. As omelaw stated, probably simplest to bring your entire roster back to Kerbin. Not sure if this is completely necessary, as you are editing the save file anyway, but will make things easier to diagnose if you run into problems. 3. The Astronaut Complex is limited in how many Kerbals you can have, until you upgrade it. So dumping a large roster of Kerbals into a new career could potentially have issues. The Kerbal 'limit' in the AC can be exceeded in certain situations, and you may be able to edit your roster into a new career with no issues. Having your original game backed up would be wise however, just in case. 4. In a previous version, there was an issue when a Kerbal was fired or otherwise removed from the roster, but had completed a milestone before being fired or killed. I think that issue was cleared up, but another reason to have a backup of your original save file in case issues arise. Excellent question! Please report back with information regarding how your transfer turned out, it will certainly be helpful to other players.

I've used Goo canisters or radial RCS tanks in the past. The basic aircraft wheels work great too, makes it easy to reposition if needed. Honestly, now I normally land on the engines. I find if I can't get my descent rate less than 2.0 m/s then having landing gear isn't going to help much anyway- because of the bouncing and attitude changes.

When you're conducting burns to transfer from one body to another, you want to have maximum thrust. You lose efficiency with long, slow burns because less burn time is spent at the ideal burn location. As your 5 engines have nearly identical ISP, I would certainly run all 5 for transfer burns. Also, during landing a similar principle applies. A 'suicide' burn is usually more efficient than a long, slow burn down to the surface (although also more risky..). Since you said control is difficult with all 5 engines going, perhaps you could use all 5 engines during most of the descent, turning off 3 engines for the final touchdown phase. When I send a huge mining/refining operation out to Jool, it's normally very under-powered, with 2-4 LV-Ns. The nukes are very efficient during long burns. However, the burn to escape Kerbin is very inefficient with the low TWR. So, for the Kerbin escape burn I bring a Mainsail. The Mainsail allows a more efficient escape from Kerbin, and makes it easy to get a boost from the Oberth effect. After I've left Kerbin and am coasting to Jool, I jettison the Mainsail, as it's no longer needed.

It looks like there was a fairing over the cupola, I'm wondering if that is causing your issue. If you still have the vessel saved in the VAB, try the following: Launch the same vessel, and look to see if the cupola requirement is checked while sitting on the launchpad. If the cupola requirement wasn't checked, return to the VAB and remove the fairing. Send it back to the launchpad and again see if the cupola requirement is checked. Please report back. If the fairing is causing the issue, it shouldn't be. Posting a link to your craft file may be helpful.

You are not clogging up the board. You had an excellent question, which was clearly stated. Additionally, the title of your question clearly reflected the content. That makes it easier for other players with the same question to find an answer using the forum search function. Welcome to the forums, and welcome to KSP!

I had been using a ferry which could transport 8 Kerbals, and had 7800dv. I ditched the two Hitchhiker pods for a single MK3 cargo compartment which holds 16 Kerbals. Dv dropped to 7500, which is still more than enough to get to Jool and back, especially with a fuel operation at Bop. The ship is only 38 parts, I'm trying hard to keep my part counts as low as possible. Electric is a single large battery and two RTGs (only need one, the second is for 'just in case'). There's a single RCS tank. Two large docking ports and a single medium docking port. I added a single 200kW radiator to help keep the 4 LV-Ns cool. Eventually heat still becomes a problem, but it takes a very long time. I also added a single antenna, again a 'just in case' item. The first couple of photos are docking with a SSTO to transfer Kerbals to/from the surface of Kerbin. With all the RCS ports I used, it's very easy to dock. I didn't even put any RCS on the spaceplane, the heavy ferry takes care of all the docking work no problem. Works great, thanks again Warzouz for the idea. As long as I'm sending a ship to Jool, might as well take as many Kerbals as possible. My flight plan has generally been: Start from Minmus orbit with full fuel, then drop to a Kerbin PE of ~300km for the burn to Jool. With the initial low thrust to weight ratio, a Kerbin PE of less than 250km isn't really efficient because it takes too long to complete the burn. About 300km PE gives me enough time to complete the burn to Jool. After dropping from Minmus, it takes next to nothing to escape Kerbin, so almost your entire burn is raising your Kerbol AP out towards Jool. My first trip hit flybys of Laythe, Tylo, and Vall, followed by a stop at Bop for refueling, and finally a landing at Pol before departing for home. However, Bop is a pain because it's off kilter from the rest of the moons. So my second trip had flybys of Laythe, Tylo and Vall, then I went out to Pol (landing) before going to Bop for a refuel. Worked much better, and I was able to use Tylo to get my orbit straightened back out before departing for Kerbin. I have two of these things going now, and am about to launch a third one because I don't like waiting for a ship to get back from Jool. The spaceplane isn't very efficient, but it is easy to get to orbit, and only costs about 6K funds in fuel to get 16 Kerbals to and from orbit.

Well, to dig a little deeper- What mods are you using? Which platform? (Windows, Mac, Linux) Latest version, 1.0.5? A screenshot may be helpful. Also, if you are using sub-assemblies or merging ship files, this sometimes causes nodes to disappear. Anything you can do to narrow down the problem may be helpful. I tried a basic vessel in the VAB, with a command pod, the fuel tank, and finally an engine on the bottom. Does this simple arrangement work properly?

Try holding down the ALT button (modifier key) while trying to place the engine. Holding down ALT forces the part to attach to the node, instead of trying to surface attach.

That makes sense, and I see how it could be accomplished since the Twin Boar is such a long engine. Used to be a problem with engines mounted above the COM would not gimbal the correct way (ex. Sky crane type landers..), that was fixed a while ago thankfully. To eliminate the problem described here, the game would need to use the engine's thrust point(s) to determine if it is above or below the vessel's COM, not the engine's COM as it appears is occurring now. Thanks for the reproduction tip blowfish.

Warzouz, that's a great idea, which I plan on borrowing! I usually have a mining/refueling operation set up at Bop or Pol, so that will make my adventure easier to do.

If you have anything attached to the capsule near the hatch, this can sometimes cause Kerbals to be flung rapidly away from the capsule when exiting. Sometimes even small items mounted to the attachment point on top of the capsule can cause this effect. The issue has been mostly mitigated in 1.0.5, but still occasionally occurs. Seems to be more likely to occur if objects are mounted near the hatch.

Take a look at #5977 (and corresponding linked bug), which is actually new in 1.0.5. I wasn't able to duplicate the results the OP had here, but the lack of roll authority in the twin boar (single centerline installation) is present in 1028. The engine gimbals properly, even with opposite gimbaling with roll input, but no roll moment occurs (make sure you disable reaction wheels to test...) #5977 has a better explanation of the cause of the roll issue. Also, howdy NathanKell!

There is a known bug with the Twin Boar, which results in the engine having no roll authority despite the nozzles gimbaling in the correct direction. However, the result you describe is different than the reported bug. If possible, could you please post a screenshot of the vessel you are seeing this with?

As stated, it is very tricky getting docking ports to line up horizontally once you are on the surface. No matter how carefully you place your rover wheels or landing legs, differences in gravity or changes in the vehicle's weight cause the ports to not quite line up. Very frustrating. Here's one workaround I have had great success with: Use the fixed (non-retractable) aircraft landing gear. They don't flex or sag with minor changes in weight or gravity. The only trick is ALL your modules have to have the landing gear attached in the same location. The fixed aircraft landing gear do not provide propulsion or steering (unless you use the steerable nose gear, haven't tried that yet), so you will need to provide those functions. A reaction wheel (SAS) is adequate to provide steering on Mun and Minmus, and a small rocket engine (or two) works for propulsion. Even RCS can be used for short distances. Joining modules together on the surface isn't really necessary for the first contract, just land the whole thing in one piece. The ability to add modules really comes in handy if you want to accept the "Expand Surface Outpost" contracts. Using the fixed landing gear, I can test on the KSC runway. If it works on the runway, it will work on any flat surface, because the geometry won't change.

This. I suggest using the largest fuel tank you can, not multiple smaller ones. As Snark said, your fuel depot may end up becoming a parking spot for several ships. It's handy to just leave them tethered in one location rather than randomly drifting in space. So, with several vessels docked to your depot the part count can get high quickly, which leads to fps issues, or lag. Keeping the part count as low as possible on your fuel depot helps, do this by using the largest tank available, instead of tacking on multiple smaller tanks. Other than docking ports (can't ever have too many of those..), try not to put a bunch of extra parts on it unless they are absolutely necessary. If one Orange tank isn't enough, I go to the bigger size tanks instead of adding more orange tanks.

Thanks nuclearping. Nope, not a mod issue, I saw the same thing in stock. Interesting. As Geschosskopf mentioned, there's several biome quirks in the game, I hadn't seen this one. The fact that this one has "Poles" in the biome caught my attention. There used to be a bug where you would get credit for visiting Pol if you visited any biome with the letters "pol" in it, including the 'poles' of planets and moons, and even the KSC 'FlagPOLe'. That one was fixed quite a while ago. I also saw the Polar Lowlands by driving a little south of the Poles location you specified. Just a short drive north of those locations the biomes return to normal, so this is a good spot to grab science from 3 biomes with a short drive! Until it gets fixed anyway. Thanks for posting the coordinates.

Could you provide the Lat/Lon coordinates at this location? I play stock, and I'm curious if this is mod related or not. You can find the Lat/Lon coordinates in Map View, clicking on the info button. At least one of your mods probably can provide that info as well.

I ended up completing the Master Mariner badge by completing a water circumnavigation of both Kerbin and Laythe, stock, prior to the buoyancy update. Obviously, having distance values was critical because my vessels had limited range on water. I took a different path to getting distance values. If you know the Latitude and Longitude values of two points on a sphere, you can determine great circle distance between the two points. The formula is pretty simple, especially if you use a spreadsheet to do the actual math. You first need the Lat/Lon values of the two points you want to know the distance between. You can get this in the info pane in Map View if you already have a vessel there. Or, just use KerbalMaps, the website allows you to scroll around, and gives coordinates at the cursor position. The formula requires the coordinates be converted to Radians. A spreadsheet can make this conversion for you. The result of the formula is the number of radians between the two points you specified. The great circle distance is simply that number from the formula, multiplied by the radius of the sphere. (500km for Kerbin). Here's the formula: ArcCos(SinLat1*SinLat2 + CosLat1*CosLat2*Cos(absolute difference Lon1-Lon2)) Again, the Lat/Lons need to be in radians, a conversion the spreadsheet can do. Multiply that number by the radius of the body you are on, and you have the great circle distance between your points.

I'm in the camp that says 'stock is stock'. While this challenge is more about the journey than the destination, there is definitely an additional challenge in completing a stock entry. In particular, I found completing water legs in stock the hardest thing I've yet done in KSP- that was before buoyancy was tweaked of course. Even just basic informational mods can be a big help. I recall one screenshot which provided lat/lon coordinates on screen, and thought how much of a huge help that would have been. My suggestion would be to leave it basically as is- Stock vs. Mods. Perhaps maintain a very short list of Stock-Approved mods. And I would absolutely include your stock bug fixes in that list if you go that route. Otherwise, doing away with the stock/mods tags actually seems kinda appropriate for this challenge- again this one is more about the journey than the destination. However, in the end I would vote for whichever method allows you to painlessly manage this challenge. This is a truly unique and special challenge which adds a lot to the KSP experience. Thanks for stepping up Claw.

Unfortunately, the issue has been around for a while (at least 0.90, probably earlier). The process of the autopilot (SAS or ASAS) orienting vessels generally works fairly well in KSP. It turns out the process of determining which inputs are necessary to achieve the desired orientation is somewhat complicated. Google Proportional Intergral Derivitave (PID), that's the mathematical basis for autopilot controllers. In the real world, controllers are optimized for specific applications, for example different aircraft have differing efficiency in responding to various control inputs. I'm not sure how exactly KSP handles this, my guess is a one size fits all controller is used. Some errors which players have noticed with the stock KSP autopilot include: - The craft jitteriness and inability to track accurately with light ships that you have noticed. I've mentioned a few workarounds earlier in this thread. Additionally, you may notice a higher resource drain (electric or RCS) when this is occurring. - Overshooting the desired attitude. This happens with heavier ships as well, in fact it is probably more annoying with heavier ships than lighter ships. Ideally, an autopilot would overshoot little if any. - Ships with more rotational torque in one axis than another produce annoying results. Two easy ways of encountering this are have more RCS on one axis than another (pitch vs yaw), and more SAS in one axis than the other, which is easy to see with the Mk2 cockpit (which has a lot of pitch torque, but less yaw torque). This one can cause some really bizarre hunting around for the right attitude. Until the jitteriness issue is resolved, the best solution is to use the least amount of SAS (or RCS) you can on light probes. Unfortunately, for extremely light probes (and yours looks extremely light indeed), even the smallest SAS unit, found in the basic HECS and OCTO cores will still cause ships to spas out. The only solution I have found in stock is to just use the basic Attitude Hold, not the vector hold modes. You can still use the vector modes to initially spin your ship to the correct vector, but then switch back to the basic mode to avoid the mentioned problems. The issue is known to the developers. Creating a one size fits all controller for KSP is difficult, the range of possible mass, rotational inertia, and rotational force combinations is pretty large. Those of us who played KSP before the handy vector hold modes were introduced are still pretty thankful we have them at all. Good luck!

There is a known issue, which results in jitteriness and craft pointing not exactly at the selected vector. It seems to affect small light vessels the most, especially ships which may have more SAS or RCS power than they really need. To the OP, I don't think you are making any errors in the construction of your probes- the issue is not limited to specific parts, or clipping, or even the Klaw. Here's a couple of possible workarounds I've used- - Reduce the amount of rotational force relative to the mass of the vessel. For SAS, use the probe cores which provide the least SAS torque, as this is not tweak able in stock (yet). I don't use RCS for rotation, but if it is possible to reduce the max thrust of RCS ports (like you can with engines), that may help. - Conversely, increase the mass of your probe. This isn't a great suggestion, you worked hard conserving mass after all. - Don't use the vector hold modes, instead just use the basic SAS attitude hold. The basic SAS mode doesn't seem to be affected by the issue. Finally, I don't use mods at all. I'm curious if other users can comment if mods exist which reduce or eliminate the problem. I'm thinking even MechJeb might do the trick. For your exact probe, here's what I would try: Get rid of the SAS unit you added. Replace the small probe core with one of the slightly thicker ones, which have minimal SAS force, and use SAS for alignment, not the RCS.

After you pull off a rescue without a TS upgrade, try going to Mun or Minmus. Hitting either one is actually easier than a rescue contract with a Level 1 TS, but equally rewarding. It was only after doing a couple of trips to Minmus with a Level 1 TS that I finally figured out how to launch directly into an inclination which matched Minmus, or at least pretty close (within a degree). You can do it, and you'll be glad you did.

Yup, mining Minmus is much easier than Mun. However, there's a couple of good reasons to set up mining/refining operations at Mun- 1. Ships at Mun need fuel. Lugging the fuel from Minmus isn't an ideal solution, if you are doing a lot of operations at Mun having fuel there is handy. Lugging fuel from Minmus to Mun turns out to be not terribly efficient. 2. A mining operation that works at Mun will work well at Ike also. So you can see how your Ike operation will function before hauling all the gear all the way to Ike.