Claw

I love the way separators look. I like the thin profile and the way they separate. Decouplers (because of size) also provide a nice place to hide batteries, RCS fuel, and other small stuff. Then it looks kind of neat when they fall away. I suppose because of debris and utility, I tend to use decouplers.

This is correct. But the advantage of turning SAS off is that you won't continue to draw electricity while turning. Just like RCS, you can get the turn started, then stop providing input. If SAS is ON, the ship will try to stop moving as soon as you stop giving input, which is fine if you aren't concerned with electricity.

Eh. Here, perhaps this will help. The junior and regular sized docking ports are reasonably obvious since each side is pretty distinct. The Sr docking port is a bit harder, because both sides are relatively flat. I've included the shielded docking port too, but that should be pretty obvious since you can only connect it one way. Each docking port has a lighter ring on the docking side. Those two sides must meet at a reasonably flat angle for the ports to dock. You can be pretty far off, but if your ship is large then the ports will have a hard time swinging the ship around to lock. You can also probably find a ton of docking example videos on youtube. By the way, welcome to the forums!

Sr docking ports are nutorious for getting put on backwards or in too far, where you have it oriented correctly but connect to the node on the other side of the port. Are you asking about all ports? Or one in particular?

If you are going to go through the trouble of delivering it to Kerbin, then there is no need to drop it and break off the ladder. Just recover it. If you have more than 1 capsule, there is also a mod (crew manifest, I think) that allows kerbals to transfer between modules of the same ship without going EVA.

If you're talking command pods, be aware there is also a bug when you detach two pods at the same time. This also causes problems, although what exactly happens after the initial bug is still a bit of a mystery.

Ahh, yes. This is a very good point, especially if you just loaded a texture compressor (and it's hanging on a texture, like you said). I believe one of the texture mods takes something like up to 20 minutes the first time you run it. If you need mod compatibility help: http://forum.kerbalspaceprogram.com/threads/74457-ARM-Pack-0-23-5-Mod-Compatibility-Thread

Like KvickFlygarn87 said, you can place them pretty much anywhere and they help turn your ship. However, you'll usually want to place them on a fairly sturdy part of your craft so they don't rip pieces off. The reaction wheel and advanced SAS module now basically have the same functionality. They used to act differently, but now the only difference is their weight and appearance.

Depending on how many mods you have installed, you might be running out of memory. That will cause it to quit loading or to crash out entirely.

Hmm. I haven't heard of this exact problem but it sounds like many of the docking/frozen orbit bugs the claw is experiencing. When it switches to retrograde target, does the target velocity stay up on your navball? Does it increase up to some high number?

The amount of science points is irrelevant to the % lost during transmission. Double check your science archive. If you did science in "high orbit around the Sun," then check for a matching experiment in your science archive. You can click on the sun's picture to narrow down the list of science displayed.

In general, I agree with Yasmy's first post. It seems the penalty for going above or below terminal velocity a bit isn't that bad. I would guess that many designs tend to suffer more losses from bendy joints and excess mass. To me, the first post really says that if you are limited on time/effort, you are better off optimizing other areas of your ship than to worry excessively about how far from perfection your ascent speed and TWR is. It doesn't seem to me that Yasmy is arguing that speed/TWR doesn't matter, just pointing out that it isn't as big of a factor as one might initially believe.

Well, start off by deciding what you want for a mission profile. Then have a look at a delta-V map. The delta-V map will tell you how much dV you need for each phase of your trip. From this, many people will design their rocket stages to have enough dV for particular parts of the journey. For example, if you want to take a trip to Mun and back. From the dV map... Liftoff to LKO: 4500 m/s Burn from LKO to Mun: 680 + 180 = 860 m/s Capture in Munar orbit: 80 m/s Down to Low Mun orbit: 230 m/s Land on Mun: 580 m/s So if you add all that up, you need 4500 + 860 + 80 + 230 + 580 = 6250 m/s So your ship needs around 6250 m/s of total dV to land on the Mun. (Doesn't include the return journey.) Now, some people will break that dV requirement into different stages. Here is one example of how to break it down. Lifter portion (to get to LKO) will have ~4500 m/s, these parts get left behind in LKO or deorbited back into Kerbin. Munar Injection portion will have 680 + 180 + 80 + 230 = 1170 m/s. This stage gets you from LKO into Munar low orbit. Lander portion needs 580 m/s. This allows you to land on the Mun. Generally speaking, you want to add a bit extra to all those numbers to allow for mistakes. An extra 10% is an okay rule of thumb. Add more if you need it, take some away if you have lots of practice. Once you have an idea of how you want to break apart your flight profile, you can use MJ to help sort out how much dV is in each section. It might take a little extra adding up on your part since MJ doesn't group pieces together.

Docking Port Won't Undock This fix is for those times when you try to split your ship by right-clicking on a docking port and "undock" but nothing happens. This is the same problem roscoe_jones posted a fix about. It seems this fix doesn't work as well for 0.23.5. This fix will actually modify your ship so that it acts as if you built the entire thing in the VAB. My belief is that it then allows KSP to use different game logic to split the ship. Super quick and dirty instructions. This is about the quickest hack you can do that allows you to get your ships apart. It's a little messy, but seems to work. 1) Keep copies of all your files. 2) Go to your ship and DISABLE crossfeed on all the broken ports. Make sure all the working docking ports have crossfeed ON. Quicksave. 3) Edit the quicksave and find the ports with the disable crossfeed. You are looking for the section below: EnableXFeed { [COLOR="#FF0000"]active = True[/COLOR] 4) Scroll UP and find out what dockUId this docking port is connected to. (Its docked partner.) MODULE { name = ModuleDockingNode isEnabled = True state = Ready dockUId = [COLOR="#FF0000"]3458512135[/COLOR] dockNodeIdx = 0 EVENTS 5) Search for the dockUId that you found in step 4. (It is the UID for the other docking port.) PART { name = dockingPort2 uid = [COLOR="#FF0000"]3458512135[/COLOR] mid = 1011018771 [COLOR="#008000"]parent = 12[/COLOR] ... srfN = None, -1 [COLOR="#FF8C00"]attN = None, -1[/COLOR] attN = bottom, 206 6) Connect the docking port's node to the parent by changing the "attN" line. PART { name = dockingPort2 uid = [COLOR="#FF0000"]3458512135[/COLOR] mid = 1011018771 [COLOR="#008000"]parent = 12[/COLOR] ... srfN = None, -1 [COLOR="#FF8C00"]attN = top, 12[/COLOR] attN = bottom, 206 7) Save the file and quickload. 8) To undock, find the docking port that gives the option "DECOUPLE". Do NOT select "Undock". In-depth Instructions. These instructions are a bit more in depth and will ensure the save file is "clean" when you're done. Use this if the above doesn't work. 1) Make a copy of your persistent.sfs and keep it safe. 2) Go to your broken docking port pair and disable crossfeed on one of the ports. 3) Edit the quicksave.sfs 4) Find the broken port in the save file by searching for the "EnableXFeed" that is active. 5) Gather the information for the broken docking ports. - For the first port that is disabled crossfeed, we will call it "Port A." Get Port A's uid, part number, and dockUId numbers. - Search for the matching docking port using the dockUId that you just wrote down. We will call that "Port B." Get Port B's part number and uid. 6) Go back Port A's uid. You'll need to modify the docking port to mach the section below. PART { name = dockingPort2 uid = [COLOR="#FF0000"]2225582713[/COLOR] [COLOR="#0000FF"]// This is Port A's uid number. Don't do anything to this.[/COLOR] mid = 173226788 parent = 10 ... srfN = None, -1 attN = [COLOR="#FF8C00"]None, -1[/COLOR] [COLOR="#0000FF"]// Change this to "attN = top, (Insert Port B's part number)". So this should look something like "attN = top, 47"[/COLOR] attN = bottom, 10 ... MODULE { name = ModuleDockingNode isEnabled = True state = [COLOR="#FF8C00"]Docked (same vessel)[/COLOR] [COLOR="#0000FF"]// Change this to "state = PreAttached"[/COLOR] dockUId = [COLOR="#008000"]2734470680[/COLOR] [COLOR="#0000FF"]// This is Port B's uid. Change this to "dockUId = 0"[/COLOR] ... Undock { active = [COLOR="#FF8C00"]False[/COLOR] [COLOR="#0000FF"]// Make sure this says "False"[/COLOR] ... } UndockSameVessel { active = [COLOR="#FF8C00"]False[/COLOR] [COLOR="#0000FF"]// Make sure this says "False"[/COLOR] ... } Decouple { active = [COLOR="#FF8C00"]True[/COLOR] [COLOR="#0000FF"]// Make sure this says "True"[/COLOR] ... } ... } Just follow the notes in the code. You will also need to go to Port B and do the same steps. Except put Port A's part number in the attachment node ::: "attN = top, (Port A's part number)" Do these steps for all the ports. Always make sure you are putting attaching Port B's part number onto Port A's attachment node, and Port A's part number onto Port B's attachment node. 7) Save the file and quickload. 1) Make a copy of your persistence.sfs file and keep it safe. 2) Identify the broken port by disabling crossfeed. - Go in-game to your vessel with the broken ports. - Right click on the two ports. One of them will give you the option "Disable Crossfeed". Select that to turn off crossfeed and make sure all other docking ports have crossfeed ON. - Quicksave! 3) Open quicksave.sfs in a plain text editor like notepad.exe. Do not use WORD or some other processing software. 4) Find the broken port in the save file. - Find your ship by using CTRL-F to search for the ship's name. - Now CTRL-F to search for "DisableXFeed". You're actually going to be looking at the "EnableXFeed" block, but searching for "DisableXFeed" make it easier to find in notepad because you won't have to scroll down. The section looks like this: EnableXFeed { [COLOR="#FF0000"]active = True[/COLOR] guiActive = True guiIcon = Enable Crossfeed guiName = Enable Crossfeed category = Enable Crossfeed guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } DisableXFeed { active = False guiActive = True guiIcon = Disable Crossfeed guiName = Disable Crossfeed category = Disable Crossfeed guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } 5) Gather the docking port information. You need the uid and part number for both ports. 5a) Getting the uid and dockUId. For this part, grab a piece of paper. You have to fix the ports in pairs, so you need two sets of information. Your paper should looks like this: uid: part #: dockUId: top #: uid: part #: dockUId: top #: Scroll up in the docking port that you found in step 4. The block should look like this (I've removed the irrelevant parts for clarity.): PART { name = dockingPort2 uid = [COLOR="#FF0000"]2225582713[/COLOR] mid = 173226788 parent = 10 ... srfN = None, -1 attN = None, -1 attN = bottom, 10 ... MODULE { name = ModuleDockingNode isEnabled = True state = Docked (same vessel) dockUId = [COLOR="#FF8C00"]2734470680[/COLOR] ... Undock { active = False ... } UndockSameVessel { active = True ... } Decouple { active = False ... } ... } Grab the "uid" and "dockUId" from this docking port. Your table should now look like this. uid: [COLOR="#FF0000"]2225582713[/COLOR] part #: dockUId: [COLOR="#FF8C00"]2734470680[/COLOR] top #: uid: part #: dockUId: top #: 5b) Find the paired docking port. Search for the paired docking port by searching for the "dockUId". In this case, search for 2734470680 Once you get to the paired docking port, you're SHOULD find the same information as the previous port, just swapped around. PART { name = dockingPort2 uid = [COLOR="#FF8C00"]2734470680[/COLOR] mid = 173226788 parent = [COLOR="#800080"]11[/COLOR] ... srfN = None, -1 attN = None, -1 attN = bottom, 48 ... MODULE { name = ModuleDockingNode isEnabled = True state = Docked (same vessel) dockUId = [COLOR="#FF0000"]2225582713[/COLOR] ... Undock { active = False ... } UndockSameVessel { active = True ... } Decouple { active = False ... } ... } The "parent" for this matching port is the first port you found. Write this number down as the "part #" for the first port, and the "top #" for the second port. Your information table should now look like this: uid: [COLOR="#FF0000"]2225582713[/COLOR] part #: [COLOR="#800080"]11[/COLOR] dockUId: [COLOR="#FF8C00"]2734470680[/COLOR] top #: uid: [COLOR="#FF8C00"]2734470680[/COLOR] part #: dockUId: [COLOR="#FF0000"]2225582713[/COLOR] top #: [COLOR="#800080"]11[/COLOR] 5c) Find the part # for the second port. Okay, so this is the one part of "figuring it out" that you need to do. There isn't a fool proof way of finding the part number for the second port (the one you're looking at right now). You'll have to scroll up to the part before, and the part after the port you're looking at. You'll have to have some knowledge about how you put the craft together, what symmetry you used, etc... Once you figure that out, put it in your table. uid: [COLOR="#FF0000"]2225582713[/COLOR] part #: [COLOR="#800080"]11[/COLOR] dockUId: [COLOR="#FF8C00"]2734470680[/COLOR] top #: 47 uid: [COLOR="#FF8C00"]2734470680[/COLOR] part #: 47 dockUId: [COLOR="#FF0000"]2225582713[/COLOR] top #: [COLOR="#800080"]11[/COLOR] 6) Fix the ports. Here's how you use the information from the table above. I'll walk you through the process for fixing the first port. You don't have to fix all the ports at once, but as a minimum you need to fix them in pairs. First Port table data: [COLOR="#FF0000"]uid: 2225582713[/COLOR] part #: 11 dockUId: 2734470680 [COLOR="#008000"]top #: 47[/COLOR] The two parts you need to fix your file are the uid and the top #. It might be easier to simply write down the "uid" and "top #" for the port you're working on so you don't get confused. 6a) CTRL-F your way to the first port's uid (in this case 2225582713) You'll end up in the docking port's part section. PART { name = dockingPort2 uid = [COLOR="#FF0000"]2225582713[/COLOR] mid = 173226788 parent = 10 ... srfN = None, -1 attN = [COLOR="#008000"]None, -1[/COLOR] attN = bottom, 10 ... MODULE { name = ModuleDockingNode isEnabled = True state = [COLOR="#008000"]Docked (same vessel)[/COLOR] dockUId = [COLOR="#FF8C00"]2734470680[/COLOR] ... Undock { active = [COLOR="#008000"]False[/COLOR] ... } UndockSameVessel { active = [COLOR="#008000"]True[/COLOR] ... } Decouple { active = [COLOR="#008000"]False[/COLOR] ... } ... } The green and orange parts will need to change. 6b) Edit the part structure. So here's how you actually fix this part, and this is for only one port. Remember, you have to do a pair. uid - leave this completely alone attN - you need to modify this so that it points at the matching docking port. That's the "top #" from the table. For uid 2225582713, the top # is 47. So it should look like "attN = top, 47" Make sure you edit the line that says "attN = None, -1" and not the one that says "attN = bottom, 10" state - you need to change this to "PreAttached" dockUId - this needs to be zeroed out. So quite litterally "dockUId = 0" Undock - you need to make sure this says "active = False" if it says "True" then change it. UndockSameVessel - you need to make sure this says "active = False" if it says "True" then change it. Decouple - you need to make sure this says "active = True" So this is what the structure will look like when you're done. PART { name = dockingPort2 uid = [COLOR="#FF0000"]2225582713[/COLOR] mid = 173226788 parent = 10 ... srfN = None, -1 attN = [COLOR="#008000"]top, 47[/COLOR] attN = bottom, 10 ... MODULE { name = ModuleDockingNode isEnabled = True state = [COLOR="#008000"]PreAttached[/COLOR] dockUId = [COLOR="#008000"]0[/COLOR] ... Undock { active = [COLOR="#008000"]False[/COLOR] ... } UndockSameVessel { active = [COLOR="#008000"]False[/COLOR] ... } Decouple { active = [COLOR="#008000"]True[/COLOR] ... } ... } 6c) Repeat the above procedure (steps 4a & 4b) for all the docking ports. 7) Make a copy of your newly modified quicksave.sfs in case you mess up your quickload, and accidentally quicksave over it. 8) Quickload your game and undock. The option will actually say "decouple node" but you get the same effect. 9) Profit.

Help! My docking ports refuse to dock or undock! KSP has suffered from docking and undocking problems for a while now. This thread by roscoe_jones outlines a fix but seems to not fix all of the problems with docking issues in 0.23.5. I think I have figured out a new method which seems to work on the more stubborn undocking problems in 0.23.5. Also, for completeness, I've included instructions on how to fix the common "unable to dock" problem. This thread has been added to the 0.24 Cross-Platform Problems thread: http://forum.kerbalspaceprogram.com/threads/92235 Keep a copy of your save files somewhere safe... UPDATE HISTORY: 8 May 14 - Found shorter method to fix "undock bug"

Start by building your subassembly using something like a structural part or a decoupler as the root part, then build. That should allow you to save it as a subassembly.

Yeah, sorry. I guess I should have been more clear about that part. You are dealing with a bug. The craft name should still be showing up at the top. If my suggestion doesn't work for you, I'll see if I can dig up the old thread and see if there was an actual fix.

Hmm. This post came up before but I can't remember the specific fix. Try changing the resolution, and switching between window/full screen mode. You can also make a shortcut to KSP.exe and edit the link properties to say "KSP.exe -popupwindow" I don't know if that'll work, but it's the first thing that pops into my head to try.

There is a bug in the VAB/SPH for the tweakable portion of the ladders. You can only extend/retract the ladders the when you place them. If the option is gone, you can get it back by deleting the ladder and placing a new one.

If he's ragdolled and not just stuck, try this thread. http://forum.kerbalspaceprogram.com/threads/75586-Master-Thread-Unresponsive-Kerbals-in-EVA

Hmm, I tried to follow your thought process but was getting a bit confused. It seems you have some crisscrossing fuel lines between your main tank and the liquid boosters, so I'm not surprised you're having some fuel flow misfeed. It might be easier if I point you toward this thread by Kasuha. It gives the fuel flow rules in the most basic setups. Hopefully you can get an idea of the rules and how they apply to the complex setup you're aiming for.

This matched up slightly with my suspicion that it might be due to the increased joint strength. I'm wondering if the force to ragdoll them is now less than the force to eject them from a seat. Thereby causing what you described, where there's a condition where they get hit hard enough to be "knocked out" but not hard enough to be dislodged.

-Confirm you're running 0.23.5.464? Maybe there's a problem with 0.23.5.459 that most of us aren't seeing in 464.- (Edit: I just checked .459 and it's fine.) Well... Like others have said, a picture would help a ton. Here's why...

This may be the reason your game is ignoring your changes. In what you posted, you put: state = state = Seated (Command) It shouldn't be "state = state = Seated (Command)" It should just be "state = Seated (Command)". I'm not sure if that's a typo in your post, but it looks like you copied and pasted a bit too much. Also, for a kerbal stuck in a command seat you don't change the name. MODULE { name = Jebediah Kerman isEnabled = True This is the module section. So here you need to leave the "name = kerbalEVA". You only want to change the name part if your kerbal is actually EVA, but not when he's stuck to an external command seat. Please remember to also scroll down to the CREW section at the end of the save file and check his "State = 1" and "idx = 0". You can also edit him out of the rover, but it'll take me a minute to find all the relevant parts.

Awesome, I'm glad you got your guys fixed up! Sounds like you ran into an extension of this problem, or perhaps a second bug with the throttle and flight states. Thanks for the extra info. If you still have a corrupted save file I'd like to have a look so I can include that information here.