Xgkkp

It mostly seems to work, though once or twice I've had a craft get "stuck" and self-destruct when starting/stopping warp. It's really nice to not have all of the spin magically disappear on warp (and admit I have fully taken advantage of this in the past).

I'm a little confused by the PITCHPROGRADE, PITCHRETROGRADE and family variables. I'd expect they would give me the information required to draw a navball, but they don't seem to. Example: Asking for PITCH/YAW PROGRADE/RETROGRADE I get: Position for Prograde: (pitch: 0.860445 , yaw: 62.2183 ) Position for Retrograde: (pitch: -0.860445 , yaw: -62.2183 ) Which is the absolute position to draw them, but gives me no information about which one we are actually facing. Is this by design? Am I just misusing these variables?

Slightly stupid question, how do I use the, uh, ADI? I've tried having it on a second screen while landing, but it seemed to do nothing....

Do you mean telemachus in that mod's screen, or that mod's screen appear in telemachus? The latter might be doable, but I don't know how far down the video feed route that Rich ended up.

I can see this being partially implemented e.g. when sending commands via telemachus, but the other way around would probably involve too much storage requirement to be able to run in the game proper. I can easily see though, some external proxy server that pulls the data out (and a variable for signal delay) and buffers it until the time has elapsed (in-game, it could read the game time also). I wonder what multiple vehicle telemetry would look like? At least in stock kerbal, other vehicles are unloaded so only orbital positioning information would be deriveable. This might be enough....

Craft file (lengthened slightly) here: https://www.dropbox.com/s/sbtghyco46453ca/HobbyFly%20I.craft. Uses B9 Procedural Parts, Procedural Parts, KAX If having the ailerons up is a problem, how do planes in that configuration manage? e.g. Cessnas seem to have about the same offset (or is it all mass distribution?) I don't know about not aligned, but the wheels were slightly off of directly vertical - but were aligned with the runway. It's tilted wheels it doesn't like? Correct: The inner surfaces on the wing are flaps. Strage shape: No reason, just that's how they were when I finished, I think I had the wing more angled at some point. I should try changing them, but I can't imagine the effect is that big? The tail is an AV-R8 winglet. I suppose I could make it a tail piece, but it doesn't seem that far off in area. It's a full moving surface, at least. It's set on Deflection 15, 100% pitch yaw roll, so, I think the default settings. It is a procedural wing - I haven't noticed anything really odd, and it both looks much better and seems a lot stronger than the flimsy cobbling together of smaller parts and struts . As for the reaction wheel, I could, but It kinda feels like cheating for aircraft - like a magic "Stabilize this!" button. I don't know if I'm the only one turning off cabin torque.... As a minor aside, I just my most Kerbal landing ever whilst trying out designs of this aircraft: (hit the beach in front of the KSC landing pad, this is how I came to a rolling halt).

Few minor questions on the stability simulations. I assume that the third lateral box is supposed to say "Init r"?? What is the blue line, phi, on this chart? (And theta on the longitudinal sim) I can't find mention of it on the Terms and Symbols nor stability notes pages. FAR used to have a popup over the chart values (certainly on the main lift/drag page) that was useful as a reminder of what the variables were. Was there a reason this went away? It was useful. This page colours Yp red if positive, however the main page doesn't. Less a question, more an observation - I imagine a minor bug?

In my continuing quests to actually build functional aircraft, I've designed this as a lightweight (comparatively) hobby craft: It has two main problems: Very hard to control at takeoff - weaves all over the place and 70% of the time a wing crashes into the runway When trying landing approach, it becomes very difficult to keep it running reasonable straight - lots of waving back and forth How can I reduce these problems? Anything else obviously wrong with the craft?

So, this is what I've been working on, with my RPM access extension; an iOS-based (so, runs on iPad) remote HUD, based (obviously, if you know it) on the RasterPropMonitor airplane HUD. It's suprisingly responsive, and I just perch my iPad right in front of the monitor. It's only the plane HUD at the moment, and the start of an implementation of NavUtilities HSI, because I don't really use the other RPM pages enough, and don't know what other people tend to use. Perhaps the orbital display might be useful; I can envision using several phones/ipads layed out around the monitor with various data screens, but it's probably best to think of things that wouldn't work so well on a web browser. Source is at https://github.com/ndevenish/KerbalHUD.

So, I wanted to get access to more variables that do not exist/a pain to calculate from the existing ones (mainly stuff like the FAR-related variables, and my inability to understand the Telemachus rotation), so I whipped together a quick bridge to RasterPropMonitor - https://github.com/ndevenish/Telemachus/commit/a4b0dc0f9629dbcc9c635182465540ff1a11ce8e Features: - Doesn't add a dependency, still works without RPM - Query access to RPM with "rpm.available" - Query RPM variables with "rpm.VARIABLE" Caveats: - It probably breaks in ways that I have not tested with the slightest breeze - It will break when they update RPM next, as they have changed where they calculate variables in the current github master - I haven't studied Telemachus enough to understand the caching system, so it's probably really inefficient in querying for the existence of RPM

This is the error that seems to spam the log files after a disconnect:

For what it is worth, I find connecting via websocket pretty hit-and-miss - sometimes it will just connect, and refuse to respond, sometimes it will all go through perfectly, and sometimes it will just sit there and hang before connecting. I haven't yet tracked the cause down, but restarting the program connecting several times usually works. I have had some errors popping up in the log to do with connections, possibly when disconnected just by shutting the client down, but am still experimenting.

I've just noticed that InfernalRobotics hasn't been updating - causing KSPAPIExtensions errors. The reason? It looks like the version number changed from "v0.21.2" -> "0.21.3" e.g. dropped the v. I'm not sure where this problem originates but maybe something to autodetect?

One other thing that really keeps bothering me; The reference to a Lawn Dart - I assume that this means "Hard to turn" but not entirely sure - the cultural reference is lost on me (either we never had them in the UK, or I just never encountered them as a fashion).

Thanks - it took me a while to work out exactly what you meant - with the swept wings the control surfaces are literally being placed further backwards from the CoM - with the rectangular wing, they are almost in line with the axis which they are trying to turn on. Adding a set of delta deluxe winglets right at the tail works much better (and the wheels back so that it can tip, also). I haven't worked out exactly why this affected Landing yet, but it's certainly easier now (I managed to land - stopping beyond the end of the runway, but with Jeb in one piece at least) This makes sense, and helps with turning, indeed. The problem is, I'm starting from scratch and wasn't really sure what conventional looked like, really!