meyerweb

I suspect what you want is Kerbal Engineer Redux.

I have a bug report (which I’ll file at GitHub, but I’m documenting here for other users who don’t look at Github issues): the keyboard shortcut can create a permanent yaw trim if you use it in a flight scene, including the map. See this from @hvacengi, who helped me work out a problem over on the kOS thread: So if I’m looking at a ship or the map view while flying a ship, and I call up, then dismiss, AnyRes with [alt+A], I’ve twice pushed the trim to the left.

It’s a single light, but the problem turns out not to have anything to do with either SurfaceLights or kOS. I had inadvertently created a permanent yaw trim with a keyboard shortcut to open the AnyRes mod. @hvacengi figured it out for me over in the kOS thread, and provided a fix: Sorry for the errant bug report!

…holy carp. I had no idea. That’s how I ended up with a yaw trim: I use the alt-A shortcut to open AnyRes, not realizing it would affect yaw. I suspect the creator of AnyRes may also not have realized that. alt-X absolutely fixed it. Thanks, @hvacengi! Very much appreciated.

How do I do that? Seriously, I have no idea how one uses KSP’s controls to permanently change or reset the yaw trim. Also, do you have any idea how it might have gotten into this state? I have another (very, very, very different) craft in a different save with the same yaw problem, so any ideas as to how this happened will help me avoid doing it again in the future.

Posted as a gist of the save, which is pretty much four simple probes in a sandbox game and nothing else. I named the probes around Kerbin to indicate what they have or don’t have. If I remove SAS from Yawer, it starts, you know, yawing. The others don’t, and may even not have SAS on right now. I’ll be very interested to hear whether you see the same yawing when you load up the save.

I mean I can see the needle move slightly left when I turn off SAS, and stay there. The ship still responds to inputs, but when I stop controlling it, the slight leftward yaw is still there. It’s always yaw, never (so far as I can see) any other direction. I’ll try to get a video later today. Edit: I didn’t make clear before that this happens even when no kOS program are running, and in fact when the CPU isn’t even on. It seems to be solely a parts interaction.

I think I’ve found a fascinatingly weird interaction with kOS parts and Surface Mounted Lights parts. If I have a craft that has both a kOS part and a SurfaceLights (to use its mod ID) part, it will yaw slightly to the left (as I look at the YAW display) whenever SAS is off, building up rotational speed. I noticed this on a small probe I’d built, and then on a large craft with a very different configuration. I’ve launched variants of both craft with just kOS parts but no SurfaceLights; they did not yaw. Then I sent up variants with SurfaceLights but no kOS parts; again, no yaw. It’s only seen when both kinds of parts are on the same craft. These tests were all done without any other non-Squad mods installed, so it really seems to be an interaction between these two mods. Here’s a gist of the small probe that has the yaw problem: https://gist.github.com/meyerweb/b479f062b29266c2eb4b0f327bceaf5d . Note that while this craft has the light atop the kOS processor part, I observed the same problem in another craft where the KAL9000 part was attached to the craft, and no lights were anywhere near it. When I launched that same craft again without KAL9000, there was no yaw. I’ve reported this over at the SurfaceLights thread as well, in case it’s their part (which seems more likely) and not the kOS part, but I wanted to give a heads-up here just in case.

NOTE: the following is not a bug in SurfaceLights (or kOS, as it happens). I think I’ve found a fascinatingly weird interaction with Surface Mounted Lights parts and kOS parts. If I have a craft that has both a SurfaceLights part and a kOS part, it will yaw slightly to the left (as I look at the YAW display) whenever SAS is off, building up rotational speed. I noticed this on a small probe I’d built, and then on a large craft with a very different configuration. I’ve launched variants of both craft with just SurfaceLights parts but no kOS parts; they did not yaw. Then I sent up variants with kOS parts but no SurfaceLights parts; again, no yaw. It’s only seen when both kinds of parts are on the same craft. These tests were all done without any other non-Squad mods installed, so it really seems to be an interaction between these two mods. Here’s a gist of the small probe that has the yaw problem: https://gist.github.com/meyerweb/b479f062b29266c2eb4b0f327bceaf5d . Note that while this craft has the light atop the kOS processor part, I observed the same problem in another craft where the KAL9000 part was attached to the craft, and no lights were anywhere near it. When I launched that same craft again without KAL9000, there was no yaw. I’ll be reporting this over at the kOS thread as well, in case it’s their part and not the SurfaceLights part.

Here’s a layout I’ve used since original Historian that’s a bit heavy on the flag, but has a lot of information for the different states. I’m looking forward to revisiting it with the new text strings and formatting options! KSEA_HISTORIAN_LAYOUT { RECTANGLE { Anchor = 0.0,0.5 Size = 1.0,0.15 Position = 0.0,0.85 Color = 0.0,0.0,0.0,0.5 } FLAG { Anchor = 0.5,0.5 Position = 0.15,0.85 Scale = 1,1 DefaultTexture = Meyerweb/Flags/USCM } SITUATION_TEXT { Anchor = 0.0,0.5 Position = 0.25,0.85 Size = 0.5,0.125 Color = 1.0,1.0,1.0,1.0 TextAnchor = MiddleLeft FontSize = 14 FontStyle = Normal Default = <b><UT></b><N><T+><N><Custom> Landed = <size=21><b><Vessel></b></size><N>Landed on <Body>’s <LandingZone> at <Latitude>ºN, <Longitude>ºW<N><size=12>ME<T+> </size><size=10>(<UT>)</size><N><Custom> Splashed = <size=21><b><Vessel></b></size><N>Splashed down in <Body>’s waters at <Latitude>ºN, <Longitude>ºW<N><size=12>ME<T+> </size><size=10>(<UT>)</size><N><Custom> Prelaunch = <size=21><b><Vessel></b></size><N>Preparing for launch from <Body> at <Latitude>ºN, <Longitude>ºW<N><size=12>ME<T+> </size><size=10>(<UT>)</size><N><Custom> Flying = <size=21><b><Vessel></b></size><N>Flying Mach <Mach> (<Speed>) <Altitude> over <Body>’s <Biome> at <Latitude>ºN, <Longitude>ºW<N><size=12>ME<T+> </size><size=10>(<UT>)</size><N><Custom> SubOrbital = <size=21><b><Vessel></b></size><N>On a sub-orbital trajectory <Altitude> over <Body>’s <Biome><N><size=12>ME<T+> </size><size=10>(<UT>)</size><N><Custom> Orbiting = <size=21><b><Vessel></b></size><N>Orbiting <Altitude> above <Body><N><size=12>ME<T+> </size><size=10>(<UT>)</size><N><Custom> Escaping = <size=21><b><Vessel></b></size><N>Escaping from <Body> at <Speed><N><size=12>ME<T+> </size><size=10>(<UT>)</size><N><Custom> Docked = <size=21><b><Vessel></b></size><N>Docked <Altitude> above <Body>’s <Biome><N><size=12>ME<T+> </size><size=10>(<UT>)</size><N><Custom> } } (Note: I know the default texture will fail on any machine other than mine, but I figured I’d share in the raw, so to speak.)

Thanks for taking up the mantle, @Aelfhe1m! Downloaded. I’m going to be That Guy™ and put in a request that you add this to Spacedock, CKAN, or some other mod-tracking mechanism, because I definitely don’t want to miss any updates. If there’s a good way to get version updates via Github, I’m happy to do it that way, but could use a pointer to how to set it up.

Perfectly clear, @Snark! (Not that I would expect otherwise from you.) Many, many thanks. I foresee Unicode hackery in my future.

A question for you, @Snark: can you detail a little bit more how the `CountdownText` and `CountdownTimes` values interact? For example: <string name="CountdownText">● ● ● • • • • · · · · ·</string> <string name="CountdownTimes">1, 2, 3, 5, 10, 15</string> I count 12 symbols in the text value, but only 6 numbers for times. How do they go together? Also, suppose I wanted to have the big dots count down from 5 to 1, the middle dots from 24 to 6 by threes, and the small dots from 60 to 25 by fives. How would I set that up?

A thought: the gizmo window would be even more powerful if you added a modifier key scaling capability. So if you hold down the `[` key while dragging on a gizmo handle, it changes the orbital parameter at 1/5th the usual speed. Similarly, holding down the `]` key changes it at 5x usual. (Or 1/10th / 10x, or some other multipliers. Whatever is most sane. Ditto the modifier keys; whatever makes the most sense. I’d have chosen shift/control if they weren’t already throttle controllers by default.)

I just tested, and it doesn’t appear to be working in 1.1.2. Opening the settings shows the number of errors increasing, and no trajectory is displayed, regardless of Trajectories settings. THANKS SQUAD

I’d also love it if this had a ScienceAlert-like option to pop the science dialog without actually doing the clicking. That would let players choose when they want to just hoover up all the science they can without being asked, and when they want to be asked if a given experiment should actually be run (in case they want to save the equipment for later, more science-rich biomes; or, they just like to see they experiments to be run before they’re run).

Followup for anyone who stumbles across this thread: something very much like this has been added to Precise Maneuver. It’s not next to the navball, but it is easily accessible, and acts pretty much as proposed.

I’d tried and uninstalled this mod months ago (the UI didn’t gel with me), but the new gizmo view makes this an insta-install. My Mun/Minmus/etc. encounters are going to be so much easier to set up with this. Thank you!

You can feed it waypoints, or you can tell it to do mostly that what you said—you can definitely set a heading and speed, and have it stick pretty precisely to both. That’s how I usually fly with it, and almost always how I send my spaceplanes to orbit. (Also how I land them, at least until I finish my kOS landing script.) The way I usually avoid mountains is to set a sufficiently high ASL to miss them all, but you can also set a radar altitude to hold. That means your plane will wander up and down along with terrain height changes, but set it high enough and you’ll avoid always terrain altogether.

There are a few out there. I prefer Kramax Autopilot, which works fine for me in 1.0.5, but PilotAssistant (on which Kramax is based) is also good, and a lot of people like MechJeb.

Thanks very much, Gaiiden! I’m already excited to use these (and variants thereon) as I work on my atmospheric autopilot script. And seeing how to use a lexicon to create one’s own data structures was an eye-opening lesson for me.

I use Kramax Autopilot (when I’m not trying to write my own kOS autopilot, anyway) and find it to be pretty good, somewhat fiddly UI aside. Works fine in 1.0.5, don’t know about 1.1.

Oh, I am so installing this when I upgrade to 1.1. Thanks!

Nice! Figuring out target-rendezvous launches is my next major project. Somewhat unrelated question: how’d you move the navball to the left?

GitHub it is!