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!

Thanks - I just edited the existing font to remove the black outlines - it can be a bit thin now but is much better when smaller, so will do for now. Again, thanks! I tried my own module configuration for this a while ago, and just managed to crash things.

My transparent-glass IVA HUD in the Mark-I cockpit is pretty hard to read, and flickers a bit - any idea how I can fix this? Any idea of a reference to the config you need to put into place to make this happen?

So, i'm attempting to understand plane construction - without stepping up to spaceplanes, for now. It'd be nice to just get around on Kerbin with the simplest possible configuration, and build up from there. I've made two similar planes with different wing configurations - ,one with the swept wings and one with the wing parts (so, rectangular). It was my understanding that the bigger wing should give a larger lift; however, it seems to require a larger take-off speed, and the data from FAR seems to match this - both in the graphs and the stability derivatives giving a lower Cl (I understand to effectively be the lift) for the rectangular - 0.278 vs 0.369, despite being a larger area. Why is this the case? In addition, I seem to be getting lots of swaying side-to-side when attempting turn (with joystick - I can't seem to find the documentation any more that explains the FAR assistance options and keyboard just seems to give massive control overkill) and am not sure which numbers I should be reading to describe this - I tried a lateral simulation just setting the Beta value but it just ended up diverging. Probably lots of other control issues but this is the main one I have noticed. Also; landing - I haven't been able to actually get the planes to slow below ~150m/s. I assume I either need More elevons to push the angle of attack into something higher to cause drag when landing (it can't seem to turn faster than a few degrees) Spoilers (which I cannot do at the moment because of the tech level of the SPH, I am trying to use minimal starting parts/configurations) Any advice on my pitiful attempts at getting Jebediah to fly?

Regarding Canards; Why do they stall before the main wing? I can see why if they are at a steeper angle of incidence, but the text and image doesn't show this? Also, how do I tell (especially, with FAR, but even without) what the swept wing "Better at high speeds" actually means - supersonic? Less? how can I quantify whether I'll need to sweep the wings or not?

Does anyone know of any good guides to creating decent/working airplanes? I've seen http://forum.kerbalspaceprogram.com/threads/52080-Basic-Aircraft-Design-Explained-Simply-With-Pictures but it says a lot about what should work and seems low on actual practical design advice. Ideally, something that involved using the FAR GUI and learning how to design, and then tweak based on the simulation results. Even more ideally, something like a series that starts with the most basic design with a minimal of parts and building up from there. Anything like this around?

Any current way to get the triggers to happen when landed? It'd be nice to, e.g. jettison shields and activate remotetech antennae on touchdown. Also, is there some reason I can't activate the gear group?

Is there some way of getting the speed/acceleration settings to apply in the VAB? Or is this just a bug..

Is NetKAN working at the moment? It doesn't seem to have picked up the kOS update kOS: Scriptable Autopilot System in the past couple of days - wondering if it is to do with the metadata restructure?

Has anyone had any luck with a hovering script for jet engines? I've got as far as realising that they spin up/down exponentially, and measuring the e^(-t/K) constants as K=8.38ish when increasing, and K=4.80ish when decreasing (at KSC level, at least - no idea if this is dependent on height but want to hover low anyway). I'm just not sure how to take this response time into account in a hovering script?

I don't like, with current behavior, "no touching the controls" - too easy to accidentally break. I'm not sure if the computing unit acts like a probe core on it's own at the moment, but it could be made that it works as a core for ship/identification purposes, but with the caveat that when you have only the computing core (and no other probe core) none of the controls respond directly - like remotetech when there is no connection - with the only interface to control the craft being the terminal (direct commands, uploading scripts etc). Then, the contract could specify the lack of any other control cores whilst fulfilling the conditions (e.g. if it was a landing contract, it would allow you to fly the probe to the destination as a payload manually, but not whilst you do the actual landing). That way the condition would be much more unambiguous.