Morse

Hm, never even knew there was such a feature previously. Is it really needed? KSP is very unstable when dealing with the nodes that are more than one period ahead. The total dV may return in future. Right now the window is packed, but I plan to add some kind of integration with "transfer window planner" anyways, so some overhaul is likely.

Well, actually, they are there. Under the "patches control" section, hard to miss. Moreover, you can set hotkeys for these if you like. As for the total delta-V, you can actually see it near the navball. That's why I removed it: it's already there.

Yes, this is prefab. It is very different from IMGUI, but not much more complicated, although you'll need a Unity Editor to modify prefabs. I separated this new GUI from the old one, so both of them are usable, even simultaneously, if needed. I only changed the behavior of the applauncher button. Anyway, in three weeks this GUI will definitely be ready, so ping me when you'll be in the mood to mess with the code.

@Boris-Barboris, remember how I offered to help you with GUI a month ago? Well guess what, I did something! As you can see, this version of GUI is very minimal, only the essentials, but everything is compact and easy to find. I plan to work on this a little more, polishing some cornercases and such. If you are interested in this GUI, I can prepare the patches.

You may want to try to add more trajectories in the patches control. The default number is kinda low.

@Clubbavich, yes, it's KSP problem. Or rather, limitation. First, if your craft is in a 100km orbit around Kerbin, that means that one period is about an hour. KSP only calculates the orbit for one period in advance. Placing a node more then that in the future will definitely screw things up one way or another. Second, the precision issues. I don't know where KSP uses single precision, and where double, but what's for sure, is that it's not enough in the interplanetary scale. The difference even in 0.01 in deltaV can be enormous in interplanetary scale, and the error of calculations seems to be comparable to this. This is one of the reasons why PM doesn't allow for the finer adjustments, it's just pointless. So for your initial maneuver just getting into the SoI of the target planet is ok. Everything else should be done mid-course.

I make them conflict on CKAN to prevent the bug reports, but technically the mods do not conflict. They use the same hotkeys by default, so there will be some weird behavior if you enable them simultaneously, but that's it. The difference between the mods is in the GUI, but since the mod IS the GUI, that means that pretty much everything is different . I guess you can just look at the GUI and see what the mod provides. The only "hidden" feature is the maneuver select: when you click on the maneuver, PM automatically selects it. Also, lots of hotkeys. You can look at the first post, the "initial release" section of the update history. The key differences are listed there. As for direct input, the mod has the maneuver saver. You can save your "kerbin-duna" maneuver to the disk and then load it in one click. I do not have much control over input fields. While it is possible to block the input from the keypad, it probably would be complicated, and I just think it's not worth it. I'm not against the video. It'd be interesting to see the plugins side-by-side from outside. I know I prefer my version because I made it for my taste, but a third-party view might be refreshing.

Yes, I just updated the tag per request of the NETkan maintainers. I guess it'll take some couple of hours before the CKAN database gets updated.

GUI behaves differently. You can look at the "initial release" part of the update history in the OP, most of the key differences is described there.

The adding and removing of the button itself is pretty trivial. To add: if (ApplicationLauncher.Instance != null) appButton = ApplicationLauncher.Instance.AddModApplication(OnTrue, OnFalse, OnHover, OnHoverOut, Enable, Disable, ApplicationLauncher.AppScenes.<TheScene>, appButtonTexture); To remove: if (ApplicationLauncher.Instance != null && appButton != null) ApplicationLauncher.Instance.RemoveModApplication(appButton); But the trick is WHEN to add and to remove. And there you have two solutions based on whether your plugin is persistent or not. If it's [KSPAddon(KSPAddon.Startup.<Whatever>, false)] That means the plugin is NOT persistent, and is instantiated every time the relevant scene is loaded, and destroyed every time the scene is exited. In this case the good idea would be to create the button in Awake and remove it in Destroy: public void Awake () { GameEvents.onGUIApplicationLauncherReady.Add(AddButton); GameEvents.onGUIApplicationLauncherUnreadifying.Add(RemoveButton); } public void OnDestroy() { GameEvents.onGUIApplicationLauncherReady.Remove(AddButton); GameEvents.onGUIApplicationLauncherUnreadifying.Remove(RemoveButton); } But if there is "true" in the persistent state, then it means that the plugin won't be created and destroyed every time the scene changes, and you should probably listen to the SceneChanged GameEvent.

Yep, a gizmo sensitivity slider is in the works right now. I finally understood how to make a KSP-like sliders and I plan to add two: the global UI size slider (you can change the size of the main window in wide range 50-150%) and this. The UI size is already implemented, the other will be soon. I'll wait for some time for this weird stage-locking behavior to maybe manifest to some users, and if all clear, will release the final 2.0 version with these features.

Does anybody else has this weird problem of most of the UI missing? I can still press the buttons blindly, but I can't get them visible.

The author of MAF has already answered to that:

Are you using the latest version of the mod? Looks like not. There was one very specific error caused by KSP API change that I fixed a couple of weeks ago, and your version suffers from it. I see lots of NullPointerExceptions from KER and none from PM. But before I investigate further please update the mods to the latest version. If there is some issue in between KER and PM I need to be sure of the both mods versions.

Nice screenshot. Now, how about some logs? I don't debug based on screenshots, I do it based on logs. You mean the gizmo module on PM or a stock gizmo on maneuver? The former is done in PM menu in the right side of the screen. The latter is done by clicking the maneuver, nothing is changed there. It's not like "capturing", it's just "listening". When the window is on-screen it's listening for hotkeys. You can't really "focus" or "unfocus" it. You can just hide it. If you do not like the default hotkeys you can change or disable them, but there is no way to enable-disable hotkeys separately from the main window. I'm thinking about the introduction of a global scale slide, but it might screw the text which might be not that easy scalable. So we'll see how that'll look. As for rotation, there are two problems. One is that it's not that easy to implement. You need to calculate the relative direction of the camera and the relative position of the maneuver, and how the gizmo would've looked if it was on screen (which it can be not). The second is the usability problem: one of the reasons people wanted the new gizmo, is because at some angles the axes are covered by each other, and you can't easily pick the one. So by making the gizmo rotating I'll introduce some other problems, and together with the fact that this is damn complicated to implement, I'll just pass

1. Why the smoke from the rocket is going up? 2. What is the point of keeping a radio on the ground nearby?

Well, I do have both mods installed, and I have no such behavior. So can you please attach your log?

Can you show me this log? Also, what modules have you enabled?

Hm, ok now I'm interested. Can you provide some logs or something? I can see not a single way how Precise Maneuver could interfere with staging, but who knows.

Well, it don't have to. Yes, there are lots of numbers and inputs, and I have no idea what they do. But luckily, I can control the craft without knowing all the details. But speaking of GUIs, would you be interested in some alternative light-weight GUI with just the essentials that would be easily accessible? Three buttons for profile, one input for speed control and one for altitude, all in one small window. I could do that... Eventually. Yes, it certainly does more than just balance. It takes my control signal and happily ignores it, like it has a better idea of what I want to do. I guess there is a button safely hidden beneath all that GUI mess that switches TCA from autopilot to assist, but I failed to find it.

Yes, that's the problem, AA can't help me with vertical take-off, and TCA can't help me with winged flight. And also TCA's GUI is atrocious, but that's another story. I wonder how hard it'll be to tear off the basic engine balancing from TCA...

And speaking of TCA, do you have any plans to integrate something like hover control into your mod? TCA is so bloated with unnecessary functionality, and yet for a simple VTOL plane with AA + TCA, well, surprisingly not-easy to control.

Yes, I've seen this behavior too. Strange indeed, but there is nothing I can do about it. After all, I just update the maneuver with the new numbers, I have no idea what KSP does with them afterwards.

The only thing that was gone was "focus on vessel" button. Everything else is implemented.

To implement a whole warping engine to just warp to the maneuver? Especially when there is a perfectly normal way of doing it in the stock? Kind of an overkill. As for the +/- buttons which everybody wants... Well, I don't like it. It's counterintuitive. The only way you can learn how to use it is by watching the video. I try to design a GUI in such a way that just by looking at it you could easily guess what it does and how to use it.