S.O.P.H.I.A.

This is probably a long shot, but is there any way to turn the cockpit's glass canopy/windshield itself into an RPM HUD? I mean, how cool would that be?

I'm having a bit of an issue in 12.2P1. For some reason, this block of code: until ABORT{ print "testing". set ship:control:pitch to 1. }. ABORT off. is locking the throttle to 0, despite not actually mentioning throttle in the code. Manual controls and "Lock throttle to x" are having no effect. EDIT: Figured it out. It looks like when you set a control, you also have to set SHIP:CONTROL:MAINTHROTTLE if you don't want the throttle to cut.

I made that change (adding kOS capabilities to vanilla command modules) so long ago that I forgot I'd even done it. Largely because I use FAR, and it's a real pain to work in additional parts when aerodynamic drag is such a huge concern. I'm going to undo that change and test to see how it works. UPDATE: Yup, that fixed it. Conclusion: If you're having the bug where only the command module appears when you revert to the runway, and you modded the mod to add computer capabilities to the capsule, undo that mod.

Nope. No remotetech, and integration is off. This is my list of mods: Toolbar, Chatterer, FAR, Floorit, Kerban Joint Reinforcement, Kerbaltek, kOS, Infernal Robotics, Mechjeb, Scansat, and RasterPropMonitor. I could try running the game with only kOS and seeing if it causes the same bug.

I'm getting a gamebreaking bug both in the current release version (12.1) and the prerelease version (12.2P1). Every single time I revert to the launchpad/runway, I end up with a floating cockpit, no other parts from my ship, and no control/physics. The only way out is to restart the game. I love this mod, but this is the most significant bug I've yet seen any mod cause.

I've located what may be a bug, or may be an unexpected feature; I can't tell. I went for a while from early KSP .23 until now without updating FAR, and I found that in the new FAR, turbojet engines are dramatically less powerful. They cut out at around ~1500m/s regardless of the amount of air I have left, meaning that planes that could get to around 1000km apoapsis without switching to rockets can now only get to around 24km. This is probably realistic, and not terribly unexpected. The really surprising bit is that RAPIER engines are now *more* powerful. At high speeds, when a turbojet is barely outputting 1kN, open-cycle stock RAPIERs are over 100kN. The reason I'm surprised is that I'd always considered RAPIERS to be a bit of a compromise between rockets and jets--you get a less-effective jet by mass than the turbojet and a less-effective rocket than the aerospike in exchange for having both for overall less mass and size. But now, the RAPIER is a better *jet engine* than the specialized turbojet, leading to some weird designs. My new-generation fleet uses RAPIERs instead of Turbojets, but never switches to their rocket mode, instead using a nuclear rocket motor. It seems strange to me that two RAPIERs (without ever using their rocket mode) and a nuclear engine is vastly more effective, except at low altitudes/speeds, than two Turbojets and a nuclear engine. OTOH, according to wikipedia, the SABER engine that the RAPIER is based off of has incredible high-speed/high-altitude performance, so maybe this is intentional, and my perspective of the RAPIER being a compromise engine is inaccurate. Anyway, is this a bug or a feature?

Is there any function or variable that will tell you the current throttle setting? The THROTTLE variable only has an output if you LOCK'd THROTTLE to something (ie, if you set it yourself).

I believe I've found a bug with the Sideslip Indicator on the airplane-style HUD. When I'm doing a typical spaceplane ascent (ascending at around 10-30 degrees with my heading as close to east (90 degrees) as I can manage), the prograde icon 'flickers'. When I am heading slightly less than 90 degrees, the sideslip indicator moves all the way to the left of the compass, as if I were moving around 270 degrees instead of around 90 degrees. It works properly when I am heading greater than 90 degrees, however. I am using the latest stable release (though this problem predates this version; I only just identified the cause of the bug) with KSP .23.5 and FAR, MechJeb, Joint Stabilizer, and Chatterer installed, though I seriously doubt any of those mods will affect this. EDIT: I'm actually unsure if the problem is triggered when the *Sideslip Indicator* moves left of 90 degrees, or when my *heading* moves left of the same. I'm having a hard time creating a vehicle that can succesfully be pointing at ~85 and moving at ~95 for more than a fraction of a second to test.

Fair enough. I'd assumed that you could. I'll use a manual camera, instead.

RPM currently doesn't list the claw on the list of parts you can control the vehicle from (where it lists the various command modules and docking ports). It would be beyond helpful if you could select the claw to control from and utilize the docking cam for grabbing asteroids. On that note, a few new variables would be spectacularly useful for comparing Centre of Thrust (CoT) and Centre of Mass (CoM). This would particularly be useful for asteroids, but could serve other purposes as well. Maybe one variable for the offset in meters the two on each axis (for example: ThrustOffsetZ would be +5 if the engines were 5m behind the centre of mass, or -5 if they were 5m in front, X would be sideways, and Y would be vertical) and another for their relative angles on Pitch and Yaw? I don't know if that would be complicated or not. Thanks for making such a great mod! I can't even play without it anymore.

Oh, I had an idea. It would be awesome if, in addition to .txt's, kOS could open a unique file type (ex. .kos). if you typed 'run xScript' in the console and there was an xScript.txt and a xScript.kos, it would prioritize the .kos for simplicity. The main benefit would be that you could set a different default program to edit .kos files, such as notepad++ or one of the dedicated kOS editing programs, and notepad++ could then detect the file being used and use the default user-defined language for it (because really, most of us probably have one that we slapped together).

This is so cool! So, so so cool! Love it. However, I noticed something that makes planes look a bit... off. On jet and turbojet engines, as on all other engines, the intensity of the particles is based on the current throttle setting. However, those engines take time to spool up and down, and it would look much more natural if it was based on the thrust instead. Right now, if you fire up the throttle to max on the runway, the jets are producing very little thrust, but there is a crazy amount of exhaust. Otherwise, this is amazing!

I've been having this exact same problem, where I get flagrant errors whenever I try to get engine stats. Can you tell me how to get .12P1? I can't find it on the github site. Also, I have two questions. I'm pretty new at this, so I don't know if they're super trivial or insanely complicated. First: What is the best way to determine if my airplane is upside-down? (I'm making a vtol, and I want the engines to cut out if I flip over so I don't jet downwards). Second: What is the best way to determine if I'm moving sideways relative to my current facing? So if, for example, my nose is facing North, how do I determine my east/west speed? (similarly, it would be useful, but not as useful to me, to determine my forwards/backwards speed relative to my facing). Thanks!

Okay: What are the specific steps I must follow to turn the default HUD or part of the HUD into a button? I know how to change what buttons do (such as switching it so that buttonX goes to page 1 and buttonY goes to page 2) but I don't know how to make an object, in this case the HUD prop, into a button. Does that help? I can try to be more clear again if it doesn't. EDIT: Nevermind. You're right, the screen was a button. Awesome. Problem solved!

I'm not sure how to do that. I spent the last few days playing around with Unity, but managed to accomplish nothing but frustrate myself. Can I do it simply by editing the .cfgs, or do I need to learn up on my Unity skills? I've deduced that all of the buttons have a flag 'isTrigger' checked off, but the various Collider components are grayed out for me and I can't, for the life of me, un-gray them.

Fantastic! Thank you so much. I love the new look, also.

By default, the smallCtrlSrf does have DeepReplace=true. The only thing sketchy I can see (and I really don't know anything) is that it uses the same texture (Ailerons_Paint) that the much larger StandardCtrlSrf uses. maybe there's some kind of resolution mismatch? Do the _paints have to have the same size/dimension as the original texture?

This mod is awesome! It lets me paint up my spaceplanes like it's Macross. Totally rad. However, I'd like to report a strange bug. Depending on the lighting and angle viewed, the Small Control Surface (and only the Small Control Surface, from what I can see) can lose its colour. Here's two screenshots from the same spaceplane: As you can see, in the first picture, the rear control surfaces are black. In the second, they are white.

Just played after a few weeks of being busy, and oh my goodness, the new features! The orbital displays! The huds! The awesome! However, I was playing around with the new HUD, and I encountered something rather odd. When I reduced the transparency level of the HUD background to increase clarity (which totally works--it's much prettier with backgroundColor = 0,0,0,5 than by default), the Prograde marker becomes almost invisible! Anywhere that it intersects other markings, such as the horizon or staticoverlay, it is clearly visible. It seems to be drawn as some sort of photoshop-style overlay (like multiply or subtract or whatever) instead of simply drawn on the screen at the alpha designated by the command "progradeColor = 214, 250, 0, 255" or whatever. Is there any chance I can get it to draw with a static alpha, instead of its visibility depending on the alpha of the image behind it? Either as a setting or the new default. Thank you! EDIT: I have a question. If I wanted to make the HUD itself a button, so that clicking on it toggles it to a different page, how would I best go about doing that?

I feel like I'm getting greedy with the feature requests, but three extremely useful variables for traditional rockets would be time to next sphere of influence change, the celestial body orbited after the next sphere of influence change, and a boolean whether or not there is a sphere of influence change in your orbit. It would let people flying IVA know if they were going to successfully get to the moon, for example. Alternatively, if there already is a way of determining this information with available variables, could someone point me in that direction?

Testing suggests that the change works perfectly. It functions as expected for the following variables I tested: EFFECTIVETHROTTLE, THROTTLE, HOVERPOINT, TWR, and TWRMAX. This makes it greatly easier to control hovering vehicles. Thank you!

The omega and upside-down omega are the ascending and descending nodes, respectively. I don't know how to perform a rendez-vous without MechJeb. You can get relative target speed by using the Target Menu (one of the buttons along the top, maybe C or D), selecting your target, and then cycling through velocity displays (press the green button next to the velocity readout) until it says Target, rather than Surface or Orbit.

Will do! I probably won't be able to test for a few hours, though. Thanks again for the rapid and active support/development!

I just tested the new HOVERPOINT variable, and it works very well, but I noticed one bug: it doesn't take into account KSP's new thrust limiter tweakables. And if it doesn't, it's possible that other variables don't as well. So for example, if my engines are set to have 50.5% limited thrust (KSP doesn't seem to let me make it 50 exact, weirdly) then I actually need to set my throttle to be almost double the HOVERPOINT to hover. Which actually leaves three possible options--either a variant of HOVERPOINT that takes into account thrust limiters, or changing the original to take into account thrust limiters, or leaving it as it is and taking that into account in vehicle design instead (ie, not limiting thrust). Thrust limiting is useful when making VTOLs because of the fine control needed. That said, what you've already done here is amazingly useful! Finally, I can use my computer skills to make up for my horrendous lack of piloting skills! Thank you so much. EDIT: I've made a pretty sick VTOL-assist screen. The three bars are drawn on top of each other with nudges. The Hoverpoint bar uses spaces for both full and empty bars, but a symbol for the last spot using the new feature. Check this out: EDIT 2: On further inspection, none of the variables I'm using (EFFECTIVETHROTTLE, THROTTLE, HOVERPOINT) take thrust limiting into account. I'm not actually sure if they should, though. It would be extremely convenient for me, and other VTOL designs, but I can think of some purposes where it wouldn't be. Basically, do we want to think of a limited-thrust engine as just a weaker engine, or a powerful engine that's arbitrarily not being used to its full extent? Whichever you decide to go with, I'll use it or work around it.

Amazing! I'll get right on that. On a similar note, another very useful variable would be THRUST%, which would equal THRUST/THRUSTMAX. Just so you know, I'm trying to create a display screen with a series of bars to aid in hovering. One would show your throttle%, directly below that your thrust% (important because jet engines lag behind the throttle, so you need to know how much thrust you're going to produce, not just what you are producing, and below that, a bar showing your hoverpoint. When all of those line up, you should be hovering, or very near to it.