Bedwyr

Heh. That works. I did figure in-game that I could create a transfer direct to the mun, get a periapse approach, and then offset to an appropriate number of degrees by eyeballing. Not perfect, but then real side-L points would be a bit outside the body's path at 60 degrees (I think it's 60 degrees for a two body L4/L5 right?).

I'd like to place some relay satellites in-line with points L4* and L5* in front of and behind the Mun. Assuming the usual 60 degree difference, how should I calculate the angle required from my parking orbit around Kerbin (usually 150km) to burn for an apoapse and reach either point at the correct angle? Thanks! *Emulated. Yes, I know; don't remind me. Single body physics.

Excellent. Thank you!

Is there a way for a couch gamer to scale the UI size? I tried editing the guidisplaysize.xml file to no avail. May I request it as a feature if it doesn't work? I am having the devil of a time reading the numbers from 8 feet back.

Oh, btw. The reason I couldn't access the debug menu was because I had the new GeForce Experience installed and "share" was active. Alt+x controls are default key bindings and override the KSP controls. Disable share and its fine.

I am such an idiot. It took a third trip and a closer glance at the screenshot I took. I was still in time acceleration. I'll go hide now. Still can't get debug to show up though.

Ok, I replicated it, but I need clarification on whether this is a bug or an expected feature. *Should* a spacecraft still be controllable when out of CommNet range when there is a live Kerbal or Kerbal pilot controlling it? If not, then nevermind. It's working as expected (even though I didn't expect it). If so, then I have launched both Jeb and Valentina to Munar distance with degraded comm operation and was unable to control their spacecraft. I *was* able to create maneuver nodes, but I could not control attitude of the spacecraft or throttle engines up. SAS is ghosted as happens with probes. I was expecting the ship to be controllable because there's no documentation and all the existing material refers only to probes. Can someone confirm this is expected or not?

NK? Sorry. Jargon and all that. If it may be a bug, I'll have to reproduce it myself again in case it's simply a transient. I'll see if the editor can do it. Also, for clarity, what is supposed to be the behavior? Edit: er, Alt+F12 should work for debug, right? It's not popping up for me.

Build 1532. Rudimentary Mun rocket, no external antenna, Valentina piloting. When Kerbin goes below the Mun's horizon, the spacecraft becomes unresponsive. I was under the impression that kerbal pilots should be able to fly the spacecraft independently of a communications link to KSP. Is this correct?

Last night I flew Valentina behind the Mun and lost attitude control of my spacecraft. I thought kerbal pilots were supposed to always be able to fly the ship.

It looks like the Steam Controller does not correctly change modes. By testing, the controller remains in menu mode when inside the VAB and airplane hangar. Haven't yet tested whether flight mode engages at launch.

Video doesn't display correctly on the tumblr site.

Gotcha. Just to clarify my strategy was sort of like the Cirrus SR-22. Parachute down to an EVA site, pack the parachutes, take off like a normal airplane. Pre 1.1 that was a good way of not having to worry about difficult landings in tight spots.

Those are some good ideas. I have trouble with the "settling" part though. Planes in Kerbal are difficult to corral already and I do have trouble slowing the rotation rate of the nose to a point that it doesn't "Pinto" (80s ref!) on touchdown, space-shuttle style.* KSP just doesn't seem to have that level of precision. *I got to meet the guy who created the descent control laws for the shuttle. He said controlling nose pitch on rollout was the hardest of the control schemes. Wild, huh?

Slashy, do you have a recommended tweak to dial back some of the nose-gear's resiliancy? I think it would probably work ok at a higher weight, but letting the gear fall on rollout after landing causes it to go into an uncontained bounce till it explodes. It's very amusing and it's only one part, but maaaybe I should split the difference? Edit: and cheat the gear to indestructibility. Gah. I just discovered that my old strategy of doing Kerbin EVAs by ballistic parachute recovery won't work anymore. The gear need, probably, <5 m/s fall rate and I can only provide about 7 with five chutes.

Good point; I'll have to try that. I also have a XB1 controller. Unsure how the mapping is on that. Also have a Steam controller, but the default Squad mapping is purely WASD assignment. I'd have to spend some time to see if there's a flexible analog solution for that controller.

Ha. Yeah, that was it. I'm obsessing with landing now. Quite a bit less forgiving of error isn't it? I'll admit I'm not very good at handling energy the pattern for these things. They really like long dragged in approaches. I think I successfully break nothing on the landing about 1 out of every 3 times so far. Working on it.

Hmm. For some reason the module manager isn't loading the cfg for me today. I've got the correct version of MM in the GameData folder and tried the cfg file in the game's root folder, the GameData folder, and a separate new folder inside GameData. 0 modules loaded every time I try to fire up the game.

F key swaps between local and global.

Yeah that's not too far off from my process. My airplane is pretty unoptimized (keep in mind I'm coming back from before 1.0.5... that's a long time away from the game), but I'll mess around still with angles of incidence and position a lot. My interest is mostly in getting the uninformed off the ground with as little hassle as possible. So I'm trying to think somewhat stupid-proof.

Right. And I'm not complaining; just adjusting expectations. The gear are usable, but have to be treated like rolling eggshells. I'm strongly inclined to think that the two big design considerations for these things are: - Either get the airplanes mass tighter in (read "in-line engines") to reduce moment of inertia or find a way to spread the gear out for better stability. - Find a joystick or gamepad controller that lets you input much smaller control inputs... like 1/4 yaw deflection or less. Keyboard control, even tapping the keys, is less than optimal. Pilots in real life hardly ever input full deflection on anything unless they're flying gnarly aerobatics like this fine lady: Doesn't that look like fun? Edit: after re-watching that pay attention to the end of the video when she lands and compare what her legs are doing on the landing roll compared to her routine (note: tailwheel planes are squirrely on landing).

More like veering with strong wingtip-dragging roll moments on even small keyboard yaw inputs. I've experimented with a variety of takeoffs including no yaw input, slight early corrections below 20m/s, continuous yaw corrections through the roll, and so on. It just seems super sensitive. Let me try global snapping and get back to you.

For others to help it would be useful to describe design, control inputs, and actions taken precisely. Otherwise it's just a random comment people will just say "oh... that's nice" to.

I tried Slashy's cfg file and it appears to have made some improvement in controllability. Please see his thread for my comments regarding the changes. I will repeat what I said there about design choices. Because the Juno engine is now first out of the gate in the research tree, it's natural that people will mount it to the side of the 1.5m fuselage. The downside is that it changes the weight distribution around the longitudinal axis and the L01 gear was never very strong. This means it's still going to result in a difficult-to-control airplane on takeoff and that mounting the gear from a wider position will help stabilize things. I've tried messing with the damping and spring strength settings, but don't notice a real heap of change. However tuning control systems has always been a test of my patience even in real life. I'm too prone to get tired of messing around with PID gains hours after hour.

Ok, so I tried the changes and it does look like the undamped oscillations have disappeared. However I want to try playing without the cfg as I haven't attempted 1.1.2 vanilla yet. The remaining issues appear to be pretty standard Kerbal problems such as the gear being too weak for the plane. For instance making small runway heading adjustments on takeoff results in significant wing dips and a crash if you're not careful. That can be managed and designed around as a typical sort of Kerbal weirdness (and lift induced rolls on takeoff are things student pilots *are* capable of in real life) due in part to all-or-none keyboard control. In the interim you have a thumbs up from me. If I don't have any problems with 1.1.2 vanilla then Squad gets a thumbs up. But given the changelog, I think you might actually have gotten it to behave better. One design note: since the tech tree was tweaked, the first jet engine available is the Juno. This induces side-mounted engine designs like I did. You don't encounter an in-line engine first. This means that the weight distribution has a higher moment of inertia in roll and that the gear may have a harder time than before dealing with yaw inputs and yaw-roll coupled moments. Just a theory but I think it might be a reasonable one. I tried keeping my plane the exact same and replaced it with an in-line cockpit and circular intake + single engine at the back and I think I did notice a control improvement. That sound plausible to you guys?