Stoney3K

The drag model in stock KSP assigns higher drag to 'open nodes', ie. engines that have nothing behind them. It assumes that if something is attached behind the engine, it's occluded and therefore shielded from drag. If you stick a nose cone or other component on the back of a rocket engine it will become less draggy and therefore get you farther into space.

I don't mind a Kerbal ragdolling down a hill for fun and profit, but I *do* mind him ragdolling down said hill (or being hurled across the Great Flats on Minmus) for FIVE BLOODY MINUTES before I can control him again and be able to walk the entire bit back to my craft. Pressing any key to regain control doesn't work, that may be fixable. Some check like "If we're ragdolling for more than 30 seconds, allow player to press 'R' to right the Kerbal and have him magically standing on his feet again" may be appropriate here. Right now it's only boring players.

This was in Sandbox mode (resuming a 1.1.3 save), so I will try to repeat the issue and file a bug report if it persists.

I thought fuel transfer was only disabled if it was set in the difficulty settings? Disabling/enabling fuel tanks (the green arrow buttons next to the resource indicators) seem to be disabled as well. I tried transferring fuel from two tanks which were in the same stack (engines were feeding from both tanks) and nothing happened upon clicking the transfer buttons.

Stock strategies don't allow you to purchase science points if you have a crapton of excess funds. They will only convert a fraction of a contract payoff into science points. You can't go and say: "Hey, I have 2 million funds in the bank and I still need 30 science points to unlock that one tech node that I really need, how about spending some cash to get some science back?"

^^^ That. Tweakscale a pair of Kickbacks to 1,5 of their original size and you have enough thrust to get into orbit while keeping a decent amount of control while still staying true to the STS replica. But even though I can see the charm of discussing rocket part balance once again, this thread was about the Puff engine only.

The O-10 was based on the ol' Shuttle OMS, so it should have been bigger from the start. The rocket engine overhaul was scrubbed from 1.2, but it may still make it into future releases, I guess.

Please, give us a multi-monitor mode that can display a flight view on one screen and the map view on the other. When in the VAB/SPH or anywhere else but the flight screen, this could display the KSPedia or the tracking station.

Well, to be fair, you CAN toggle the resource view and the navball in map mode. So I can see the argument for having an AGL altimeter in outside flight view. I find the IVA cockpit layout too cluttered and instruments scattered in random places to be able to use it for flight. Also, there are a lot of controls lacking in IVA, and outside view is largely obscured, so using it for landings is difficult. Remember that the Mercury, Gemini and Apollo command modules were mostly flown on remote or computer guidance, so astronauts had less reason to peek at their instruments and look outside unless something was wrong and they had to intervene manually.

Even though I really love building and flying planes, this is defiintely true. Anywhere but the KSC means you have no way of guidance to some sort of "runway". PAPI isn't really necessary but some better visibility of the runway at night would be great. As far as navigation instruments go, they're pretty useless unless there is more scenery and more contracts to support flying planes -- perhaps some villages or cities across Kerbin which have their own runways. Right now you can fly a lap around the pattern at the KSC and hop to the island runway, and that's basically it. Precision lighting like a PAPI and instrument landings really only become a thing if there is something else on Kerbin: Weather. In clear skies, you can land visually just fine if you get on course towards the runway early enough. Systems like PAPI and ILS are meant to allow pilots to stay on course even in torrential rain. Also, as a player you can hardly place any navigation beacon on another body, save for flags, which only have limited usage (for example, if you want to construct a runway on Duna from scratch).

The reason I'm asking is because I am building a lifter which can haul 2 strings of base segments side-by-side, and I need some way to attach/detach them to the central "spine" that is supporting the base sections. I can mount a radial decoupler to the central core of my lifter, but I cannot attach the base segments to the decoupler. They will only attach via nodes, and even though it is possible to put some kind of component in between to make them stick to the decoupler, it's just adding unnecessary parts. Alternatively you can use a mini docking port which can attach/detach to the node on the bottom, but being able to attach them to something like a decoupler would be nice. May even spark some interesting alternative uses for those conveniently-shaped semicircular base pieces which also feature a fuel tank (*hint hint*)

The current runway lights are adequate but they can definitely be improved for precision approaches. For example, adding a series of red and green lights at the runway thresholds, and adding a string of strobe lights in the direction where aircraft approach (East). The current runway lights make it difficult to line up and get the correct glide slope when flying at night, especially when you want to spot it from a distance. Having an Approach Lighting System (the string of lights leading up to the green threshold) as well as a PAPI (the four yellow/red lights next to the runway) would be very helpful if you want to fly night time approaches. Maybe we can look into implementing more advanced runway lighting for level 3 and keep the basic runway lights for the level 2 runway?

Exactly as RIC stated, that's why there are no moving parts in stock. The Klaw works as a docking port so it can only move a craft relative to another craft. That's also why trying to Klaw your own craft is a bad idea. And all of the other "moving" parts (landing gear, solar arrays, antenae, and so on) are moving, but they are only moving with respect to themselves. They can't have another part attached to their moving bits, for the exact reason mentioned: It would mean a certain part of the craft is moving relative to the rest of it, and this can't be simulated properly in Unity (which expects each craft to be a rigid body with no hinges) AFAIK, Infernal Robotics uses some kind of hack to make it work, but the most elegant way to implement it would be to have each sub-craft on either side of a moving element act like a "craft" acts now, and make an entire craft consist of a group of these sub-craft. However, that would mean a significant code change.

Well, the reason Station Science is set up is the reason it works very badly with the "Bases and Stations" contract pack: The contract pack requires you to have a science lab component (an MPL) on board to complete a contract for a new station, but the Station Science modules combined with the MPL are currently overpowered and can be used for unlimited science farming. Also, the fact that Station Science requires every experiment to be recovered on Kerbin, means that it quickly becomes impractical to run experiments outside of Kerbin's SOI, especially when you're doing them for contracts. You will need to wait for a transfer window to send the experiment, perform it, and then wait for a proper return window to recover it and hope the contract hasn't expired in the meantime. I am absolutely in favor of more surface-based and station-based science experiments and contracts. My favorite mod sets still remain Station Science, SCANsat and DMagic.

Flight "assists" (as opposed to complete auto-flight) sounds as a very interesting idea, because it will also teach players to fly spacecraft by themselves instead of relying on SAS to fly all maneuvers for them. I once implemented a "Flight Director" that just projected a virtual target on the navball as a tiny mod, never got around to finishing it into a proper flight director, though. But I do support the idea of cueing the player into steering their spacecraft the correct way, as opposed to blindly following a computerized auto-flight. I'm kind of in favor or re-doing the "navball" in Surface mode to carry more information for atmospheric flights. Compare to the Primary Flight Display of a 737, here: The aircraft nose indicator (center) and the prograde marker are pretty much identical to what is shown on the KSP navball. In this case, 'prograde' means flight path angle, which is the angle the aircraft's prograde vector makes with the horizon underneath. So with a horizontal FPA of zero, you're flying level and not gaining or losing altitude. The FPA marker moving off the vertical axis means the aircraft is turning. A roll indicator and a sideslip indicator (which is important for making a coordinated turn) are at the top. The flight director is shown here as two crosshairs which line up in the center when the aircraft is flying the correct path. Horizontal lines mean pitch, and vertical lines mean roll, which is currently impossible to display as a target marker on the KSP navball. Targets are strictly pitch and yaw only, because for a rocket, roll is practically irrelevant.

You can limit the amount of authority on the rudder if it is overpowered. I usually don't use the 'Tail Fin' for a tail fin on small (Mk1 or Mk2 under 20t) planes just because it is such a powerful control surface. The Standard Canard is a good tail for those tiny planes. Also, add a slight amount of dihedral angle (tilt your wings and tail fins upward) which will help with roll stability. It will move the CoL slightly above the CoM which will cause the plane to re-level itself when you're not applying any control inputs. Imagine the plane to be "hanging" from the lift forces like a set of strings, which converge in a single point straight above the CoM if you tilt the wings upwards slightly.

Please tell me how to get something like THAT into Kerbin orbit without having to use the 'Infinite Fuel' cheat. I can usually build things that look pretty just fine, the only thing is, for them to look pretty, they have very limited tank volume so they will rarely make orbit. (At least, if you don't resort to nasty stuff like tank clipping.)

I have a different experience with stock fairings: Payloads regularly flop OUTSIDE the fairing if there are no struts attached. Similarly, stuff clipping through cargo bay doors from the inside. AARGH!

Not just upwards-facing, but also in line with the rocket's center of thrust. If your control point is offset from the craft's center of thrust it will keep trying to gimbal the engines to fly sideways if you want to follow a prograde vector. ('Stability Assist' mode shouldn't be affected, though.) A lopsided payload mass is less important if you have a huge, massive booster stacked underneath it. The payload moving around in the fairing will cause a big mess quickly. You can strut directly from a fairing base now so you don't need to mess around with cubic struts.

Not the first time it's been suggested and a great idea. Especially useful if you have larger craft carrying a few dozen Kerbals and you need to find a specific one.

Maybe splitting a few hairs here but: You're using a Vector, which has massive control authority even compared to the biggest reaction wheel. So what will happen is the Vector will gimbal one way and the reaction wheels will turn to compensate because the vessel starts moving around, which will cause oscillations and the familiar noodle-flop. Both the engine end and the reaction wheel end will try to turn the craft, which only results in bending it. Try building the same craft with both a Reliant and a Swivel to see what the different results are. (OK, we're drifting a bit off topic with this, may be a good idea to continue in a new thread for it.)

The only reason wheel placement does matter somewhat is because no practical craft is ever 100% rigid. So the reaction wheel will impart torque on the structure it's attached to, and this structure will flex. In the most extreme case, imagine a reaction wheel attached to a spacecraft on a piece of string, versus one attached on a concrete pole. Even more true is this the case in KSP, where "craft flex" is more extreme than in real life, and it's the craft flex that will cause the 'control computer' (SAS) to chase after the craft's inertia. Because of the craft flexing, transmitting torque from one end of the craft to the other takes time, and if the sensor component (Jeb's inner ear or probe core) is attached to one end, while the actuator (an engine gimbal or big honkin' reaction wheel) is attached on the other with only a noodle of fuel tanks in between, you're gonna have a bad time. A typical player's reaction is usually "My craft is wobbling and unstable, HELP, I need more control, so let's smack on more reaction wheels!", followed by cramming reaction wheels in all the wrong places, causing an even more extreme amount of torque being applied, followed by heavier oscillations, and eventually RUD. The placement of reaction wheels does not matter for the amount of torque being applied on the craft, but it definitely matters in terms of control lag. Get those wheels as close to the 'Control from Here' bit as possible.

How do they solve that problem on the real shuttle upon re-entry? Is the real-world cargo bay heavier than its model in KSP? I mean, those SSMEs are pretty heavy engines, so I don't expect the CoM of an empty shuttle to be very far forward in real life either.

I was referring to launching due east when its target orbit is equatorial. Which, due to Earth's geography, may almost never be the case, and because the Kennedy Space Center is not on the equator, it needs to turn somewhat for every mission. What makes me wonder is that the shuttle makes a full 90 degree turn and then some, instead of simply pitching over to orient heads-down and bank slightly to turn to the correct heading (returning to wings level orientation once the proper heading is reached). This leads me to believe the shuttle is positioned in the 'wrong direction' (due North-South) at launch because that is the only way the launch facility allows it.

The reason I'm puzzled by the use of the roll program is because the shuttle is supposed to be launching due east (for an equatorial target orbit), so is it necessary because the lauch pad is oriented north-south? I suspect it would never have mattered with rockets when they first built it, but it was more of an issue with shuttles which aren't symmetrical across 2 axes. With respect to the negative G part in the "heads down" orientation: That makes sense, because the thrust is not straight into the crew's back, but on an angle (the component that wants the shuttle to fly sideways and veer off prograde). If they were launching heads-up, that force would push the crew out of their seats, so a heads down orientation is more comfortable.