Wobbly Av8r

Well, looking at it, no autostruts are enabled for the vessel at all, and the result isn't so much Kraken-like as it seems to *possibly* be a bug introduced when the good folks at Squad made it so passengers couldn't EVA - I think that was one of the modifications that occurred between 1.10 and 1.11. I'm wondering if this issue isn't some side-effect of that decision, even though the Kerbal occupying the EAS-1 is a scientist (There are pilots and an engineer in some of the other EAS-1 seats in the payload bay... But what has me mystified is the noise that it makes, completely unassociated with any actions taking place and the undesired staging. Very odd. In any case, thank you, @Serenity for taking the time to respond and offer your ideas.

Well, I re-engineered the vessel - I even unstaged the fairing but found out that the transition to [the problem] occurs immediately after I pick up a stranded scientist and EVA the Kerbal to an empty EAS-1 seat that is located in the payload bay - the moment I clicked on "Board EAS-1 seat", the staging status on the left goes into the "You have two stage 4's that are both empty" as described above, and opening up that seat again does not change it back. Funny thing was that didn't happen the first time I picked up the stranded Kerbal... maybe things changed when I updated to 1.11.2? I was previously running 10.2 prior to the upgrade...

Thank you, @Serenity, I will give that a try.

I have an odd problem that I'm hoping someone here has encountered and can help me to correct, or at least to understand what is going on: I am docking two ships around Minmus, one that has transported Kerbonauts from Kerbin to Minmus orbit, and a lander craft that I dock with, refuel and transport the required Kerbals to the Minmus surface and back. This has worked "famously" for a few missions until now. As I docked with the lander vessel (I docked by flying the lander because it has the RCS system, not the transport) immediately, upon docking, the TD-25 Decoupler performed an uncommanded separation followed by a sound which is best described as a Geiger Counter clicking combined the operation of a steam engine. IOW, I have no idea what sound file is called, but it's not a decoupler sound file! In any case, I've Alt-L 'd to prevent staging (which is not illustrated below, but it was tried), I've deselected each of the docking port Jr's options to not stage, I've tried to dock while flying the non-RCS transport ship and no matter what I try, upon docking the decoupler does its thing and my fuel and engines go bye-bye, along with that weird sound. I verified the file integrity. Of interest, on my transport ship staging information displays NOTHING; no decoupler (or parachutes, which are also attached) or engines and while my total dV is displayed, none of the two stages (both which are labeled "4") have any dV associated with them. I have no problem firing the engines but, again, they are not displayed anywhere in the stack on the left either. What is going on? Is this just a corrupt file? I've checked the .sfs and the vessel has all the components in that file as exists on the ship but none of the status displays seems to think so AND docking creates a weird decoupling/sound. Suggestions?

Well, the picture link doesn't work, but the most common problem is that you need to change the pitch of your propeller blade as well as the torque of the motor. The blade pitch is usually done by selecting "Deploy" for the blade and changing the deploy angle.

While I am sure that if one has the proper mathematical acumen this can be determined 'on paper', on the planet of Kerbin such calculations are left to trial and error - I'm pretty sure it's in their Konstitution! The steps to developing a meaningful chart/table that determines lifting capability needs a consistent launch profile, launching a specific mass (I use full 2.5m ore tanks) and verifying that you can 1) Achieve orbit, 2) Determine how much fuel is left over. The left-over fuel can either be off-loaded or payload increased, as necessary. As an example, I have a booster system that is based upon the Twin-Boar with a Jumbo-64 tank on top. That arrangement will place a relatively steamlined payload of 18t-19t into LKO. As I strap certain combinations of SRB's to it, it increases the amount of payload...

I personally derive my KSP pleasure from attempting to accomplish my space program as if I had to deal with budgetary concerns as well as semi-reality in launch vehicles, meaningful to only one person, but that person happens to be me, so... In so doing, I find others making ENORMOUS ships that fall outside the boundaries I try to set on my own program, both in cost and reality potential. Instead of building ginormous vehicles, I strive to build more compact, powerful, reusable vehicles and attempt to make use of an orbiting fuel station around Kerbin as well as Minmus that can refuel heavier payloads for deep space travel. Very large vessels are built to complete their assembly in orbit with docking ports. This kind of planning (to me) causes me to 'extract' maximum performance from the parts I select, both from a weight perspective as well as a cost factor. My most expensive projects cost well under 200,000 Kerbucks, most less than 100,000 and I recover part of the booster almost everytime so my cost decreases even further. Just a few thoughts if such a thing appeals to you...

I think the answer you're looking for is LEFT-ALT to terminate the fairing without a mating surface (simultaneously with left mouse click).

Try the "[" or "]" (bracket) keys? That's what works on Windows...

Not to be a n a l or anything, but making a new post rather than "necro" a post from 5+ years ago might be the way to go in the future, but as to your issue... If your vessel is composed of more than one command pod, either you or the software has to decide which pod controls the vessel. This includes when you dock with another pod, whether with a docking port or the klaw. Each command pod defaults to priority "10" and if the user has not changed any of the command pods to a higher priority, it "arbitrarily" chooses which pod will take control. This is likely why, after docking with the "debris" which happened to also be a command pod, the debris became the control point. Of course your engine thrust is not aligned with the orientation of the command pod in the klaw and the result is what you experienced. Right-click on the original command pod (the rescue ship) and set the control priority to something higher than 10 and you should at least have control of the vessel as you did before attaching to the stranded vessel. As far placing items in a cargo bay to recover them, I have no experience, so I can't be of any help with that part of your problem... sorry! Good luck!

@pblevy08 First, some background to make sure we're dealing with the same thing: There are two symmetry modes, RADIAL and MIRROR and you can toggle between the two modes with the 'R' key as @vv3k70r stated above. MIRROR symmetry is limited to either placing one part or two parts like a mirror image of each other, thus if you are in this mode, you will NEVER be able place more than two parts [or sets of parts] at a time RADIAL symmetry allows (beyond the standard single part placement) 2-, 3-, 4-, 6-, and 8-way placement, which you can cycle through by using the 'X' key (or reverse direction with SHIFT-X ) Okay, so that's the background; the quick answer to your problem is that WHEN you've attempted to place 4x fins and they "snap" back to 2x fins, WHILE your mouse is on the desired parent part, type 'X' twice. For most construction this will simply get your symmetry back up to what you desire. The reason is can default is because you probably already put some other parts on the rocket body that already have 2x symmetry, and as you move your mouse to place your fins you passed over a 2x symmetry part. If you carefully avoid mousing over any of the 2x symmetry parts like@magnemoe describes ("kind of come in from below and then place the fins") you avoid this but sometimes it's just easier to have your mouse close to where you want to place your part and type X or SHIFT-X to get to the correct symmetry. One last note: If you have already placed a part with, say, 2x symmetry, if you attempt to place something on THAT part with different symmetry, it won't let you - the results will usually not be what you want anyway. So if you want to, say, place four fins on each of two SRB's on either side of a rocket body with symmetry, you will need to start by ONLY building ONE side of what will ultimately be doubled. In this case you put on one decoupler, then one SRB, then use 4x symmetry to attach fins to the SRB... and THEN (and only then!) go back and select the decoupler (the highest parent part) which 'pulls the part away from the rocket body, change symmetry to 2x and then 'reattach' the decoupler to the rocket body... >voila< you have 4x symmetry fins on a 2x symmetry SRB configuration. Hope that makes sense! Good luck!

Are you trying to build it [from scratch/on your own in the VAB] or are you trying to download something and use it?

First off I commiserate with you about surface recoveries. Second, yes, absolutely using BG parts for recovery is very possible - your solution parallels my own and others I've seen and I can attest to their effectiveness (and level of frustration, so there's that too...) I can't quite venture to say why your Klaw would say it was engaged but not picking up the object, but I would offer that there is a thin line between object collection and object collision, which is a large part of the problem here - I navigate this issue by making sure that before engaging the Klaw that it is as DIRECTLY above the object to be recovered as possible; if you are not right above, the object collision is triggered rather than the connection. Whereas you use wheels to establish such as position, I took the "economical" strategy and "asked" one of the Kerbals on board to go out and push the object until it was right underneath the Klaw'd recovery vehicle. (Those snacks aren't gonna pay for themselves! We worked out a deal...) I would add, if you haven't discovered it already, that when you recover a part which has reaction wheels built in that you disable them before attempting to maneuver, and that your recovery vessel command pod has a higher priority than default or occasionally after you connect, you will have a new orientation / control point and that will definitely make the trip more, uh,... "memorable". [Edit: Oh! And the way to the get the URL embedded is to remove the html formatting - just the url location itself will allow it to be posted as an image in your post rather than a link...]

Actually, I think your problem is similar to my problem (I'm running 1.10 but I've had the same kind of problem since I can remember.) It has to do with the symmetry and how it's built in the VAB/SPH and the solution I've found is to build only one side of the symmetrical structure (in single symmetry) all the way through, i.e. normally you would place two servos, then two engines, and so on, but I would build ONE side of your symmetry, THEN turn on double symmetry and select the root part of the symmetrical structure and place it back down so that the OTHER side is created all at once. Then it behaves like you would expect. Interestingly, in my experience, if you edit an outer portion of the symmetrical structure after original placement as described, you end up with the same problem again, so if you have to change ANYTHING on the symmetrical structure, you have to edit the portion and then place it ALL again in desired symmetry. Don't know why, but it works.

You could very well be right - I've never accepted a contract that didn't have all the parts available, but that certainly doesn't mean that's the way it is.... (That's why I start most of my "help" replies with words like "Usually...") If you or anyone else has the definitive answer, I'd certainly be willing to read and learn!

Usually, if a part is required in the contract, it is "loaned" to you - it is suddenly in your inventory, but will disappear after completing the contract. This said, taking contracts you will not complete for a long time (if at all) is a great way to "unlock" parts that you would otherwise not have access to! This is more common with certain engines and/or landing gear, etc. Sometimes it's worth it to take a contract just for the parts you will have available to you! [Edit Add: One way to check if a part will fill the requirement is to include the questionable part in a vessel (the simpler the better) and place it on the launch pad and then open the contract tab (upper right) and see if the "Has a cupola" requirement is checked off. If it is, the part will work, otherwise it's no bueno.]

[Edit: Apologies, reviewing the OP, replace 'keys' with proper console joystick and/or buttons! D'oh! I'm gonna guess that whichever joystick controls the elevator, the OPPOSITE joystick left-right controls the ailerons, aka roll/bank...] Almost undoubtedly this. The A and D keys control rudder and indirectly control flight direction, but as you have become aware, not in a fully controllable way! Most folks get very used to the A and D keys to turn left and right with wheeled vehicles, but it is not intuitive to understand when turning an airplane, you 'bank' the airplane (roll using Q and E) in the direction you wish to turn and let the 'tilted' lift vector move you in that direction. As you roll/bank the aircraft, because some of your lift is 'redirected' and actually causes the craft to turn, the total lift opposing weight/gravity is reduced and the craft will start to descend. This cause and effect is more pronounced as you attempt to turn quicker with greater amounts of bank angle, thus the amount of elevator one must use to counter this phenomenon increases with bank angle. TL;DR? Use Q and E to roll your plane in the direction you want to turn, use S to prevent descending when doing so as well as increasing the rate of turn.

I could be wrong, but I don't think it was a bug... A maneuver node is essentially a "plan" to achieve a certain trajectory. As such, once the node is established, what the Navball maneuver prograde marker indicates is how to continue to achieve that path - both in direction and required dV, not necessarily what was contemplated when placing the node (i.e. x amount of thrust in prograde direction, and so on). Thus, with a low-TWR vessel, in order to accomplish what was planned with the maneuver node, let's say a burn that takes 10 minutes at low thrust (optimally accomplished by starting 5 minutes before the node and completed 5 minutes after the node), as the vessel proceeds past the 5-minutes-before mark, the requirement for thrust will exceed the thrust available and the node reflects that by increasing and a continuously changing requirement as you continue to close in on the node, as displayed. Additionally (edit add) if your TWR does not allow a single orbit burn (it requires too much time) it will act rather bizarrely regardless of how you attempt it - the solution is plan a, say, 10 minute burn over multiple orbits until the cumulative effect results in your desired trajectory / path. [Edit 2: A full circular orbit at 100,000m takes about 32 min 38 sec.; a 35 min burn would literally require burning over an entire orbit and then some. Maneuver nodes are simplifications of a maneuver's burn requirement - AS PLANNED they are "instantaneous" burns, meaning we know that to be precise, you would need to "instantaneously" burn all the dV at the point of the node. Realistically (even in KSP!) we have to distribute the burn over time due to TWR constraints (the half-before the node, half-after referenced above), with the burn time constraints becoming virtually impossible as the burn time requirement exceeds half of an orbit. Hope that all makes sense... ]

Indeed! Early in the game I hired some crewmembers, but discovered that as you rescue them from LKO, the Mun and Minmus you add crewmembers to your roster... for FREE! AND you probably get a few Kerbucks in the process! Doing "endless" rescue missions can give you a fairly sizeable roster in no time... while they don't show up as money, they are, in fact, money in the bank!

Because the complexity of the options for the noob can be overwhelming, I think a lot of folks get into the idea that pursuing whatever it takes to complete contracts and science, they don't take a little extra time to "smell the roses" (From the philosophy/saying "As you go down the path of life, it is important to take time to smell the roses") In this case, experimentation as you suggest is really important to developing a real sense of the reality of intergalactic travel! Kudos on the recommendation! However... Yes, recovery of equipment takes extra playing time, but if properly considered, also minimizes launch costs to an embarrassingly small investment, i.e. in essence the cost of the fuel; the trick is to make a single stage vehicle that requires minimal recovery components (but also knowing that if you can control the reentry, you will recover 90%+ of the costs) and only use them to establish LKO. As an example, I can routinely put 19t into LKO for a total cost of < 7,000 Kerbucks with no loss of time because the recoverable portion can orbit Kerbin indefinitely while I focus on the continuing mission and I can recover the booster during a "break in the action" as it were. Just food for thought.

@Limonadd - In my experience, the reason you had the disparity in location of Center of Mass has to do with symmetry and how you use it during construction. Typically, when one adds a single piece to a single node, we don't pay attention to the symmetry setting - we may believe we're adding a single part at a single node, but OCCASIONALLY (haven't determined exactly why or when) IF the symmetry is set to more than one (a single dot), more than one part can be added at a single node. While there may be a subroutine that goes through your construction before launch and eliminates the duplicate part(s) (since they should show an exactly identical location), WHILE you're building, your meta-data information (Center of Mass, Lift, Thrust) could be "fooled" by this occurrence. Hope that makes sense. As an aside, while I completely support one's desire to build with "moar boosters" (there is a certain magnificence to launching that!), as you progress in the game I would humbly recommend that you give thought to the idea bigger is not only usually not better, but as you get too big, you exaggerate ALL of your problems... but just a suggestion. Carry on and Good Luck!

@Le Lynx were you able to get the information you needed? The KAL-1000 is rather similar to the whole of KSP itself: has a lot of different capabilities but many of them not so obvious - because of this, you may need to ask more specific questions about what you're having problems with, but I believe you have a large audience here willing to lend their knowledge.

Anecdotal evidence (experimental with KSP) would indicate that yes, more blades generates both more thrust (requiring more power) and more lift. If you simply right-click on a single blade you get the same readouts at the same deploy angle / angle of attack and RPM. but of course, it's only measuring that one blade. Multiply it by the number of blades and you get the overall result, which is single blade x number of blades. I'm guessing turbulence is not an emulated factor for the rotating installations based on my observations. When I did my test above, regardless of whether I checked on a 2-, 4-, or 8-bladed installation, they reflected the same lift per blade at identical RPM's. Now the question of whether - or to what degree - translational lift is mimicked for either ducted or unducted installations is a head scratcher...

I'm glad I could help, but must give credit to those who passed the knowledge to me long ago! This is one of those non-intuitive lessons that all aviators must learn - don't get on the backside of the power curve! It is humorously described thus: If you push on the flight controls, the houses get bigger, if you pull back on the controls, the houses get smaller. If you KEEP pulling back on the controls the houses get bigger even quicker! You shouldn't feel bad about having to take time to digest this information - there are still people flying actual jets around that end up stalling them because the concept, while not difficult to understand at a fundamental level, is rather more difficult to put into practice. But rest assured it is a truth of flying any vessel which has a thrust to weight ratio of less than "1". Something of interest that might be of benefit to your purpose is the idea of "translational lift", which is how a helicopter is able to fly at altitudes it cannot hover at; in brief, rather than each blade acting as a wing providing a lifting force through rotation, the entire plane of the rotating blade acts as a circular wing as long as the vessel has enough forward velocity to take advantage of it...

@OHarasums it up nicely (like so many of OHara's posts) but I'd just throw in a couple of extra thoughts as you anticipate other atmospheres... A prop is simply a rotating wing and when measuring the force of wings, they provide lift, but in the case of props it is thrust but otherwise similar. The actual equation for sake of my examples is Lift = Surface Area x CL x (1/2 x Air Density x Velocity2) CL is the Coefficient of Lift, and is determined by both the effectiveness of the cross-section of the surface (something you don't specifically control outside of blade selection) and the angle it makes with the air it is passing through (the 'deploy angle' in KSP). What is important to get from this formula is that because lift is calculated by multiplying a number of factors together, and lift will generally be equivalent to the weight of the vessel (constant except for gradual reduction due to fuel burn), if ONE of the components is reduced for whatever reason, one or more of the OTHER components must increase to compensate. One example you've already discovered is that as you ascend and the air becomes less dense, one or more of the other components ( Surface Area, CL, or Velocity) must increase to maintain the amount of lift needed to support your vessel. Typically you won't change the surface area of the blades, so CL (essentially 'deploy angle') must increase and/or Velocity (rotational speed) must increase. But of course there is a caveat... if the angle the wing/blade makes with the oncoming air is too high, the CL suddenly decreases and ceases almost entirely over a short span, which in turn decreases the amount of lifting force it can produce, which is commonly known as a stall. You can see this happen when you hold your hand out a car window at highway speeds - hold your hand flat (no angle of attack) and your hand is not suspended, but tilt it upward and your hand wants to rise! Keep tilting upward you reach a point where your hand is pushed backward, not upward as the turbulent flow and impacting air give relatively little lift and mostly drag. Finally a note on air density and stalls - just like water is more dense than air, so the design of 'wings' designed to operate in those two very different densities must differ in their properties because of how density affects the stalling angle of attack; think airplane propeller vs boat prop... less dense air favors longer, thinner airfoils at lower relative angles while more dense water favors stubbier, wider blades at a higher angle. Another example is that because air density decreases with altitude, and you can only increase the angle of attack so much to increase lift, it is velocity (rotational speed) that must make up for the decreasing density, not angle of attack. (Also keep in mind that because lift increases by the SQUARE of velocity, it makes more sense to increase speed rather than angle of attack for high altitudes...) What you choose in KSP is simply a balance of these factors... Good luck!