Morse

I can tell that nodes are disappearing in the linux version. I guess MacOS is also suffering from it, although I didn't test. Usually, not only the node disappears, but it also takes a good chunk of HUD with itself. But there is nothing in Precise Maneuver that can make a node disappear. The mod itself can crash, or stop working, or start to behave weirdly (and it does it all the time), but it absolutely can't delete a node unless told to do so.

The new version is out. You can test it now.

Yes, I know this. It's the new update of KSP that broke everything (well, it's a prerelease...). New version is coming. I think yes, the time has come. After the KSP 1.1 release and a bit of testing I'll go for CKAN.

Okay, here it is! It looks very similar to the stock gizmo and behaves the same. You can download the mod here: https://github.com/radistmorse/KSPPreciseManeuver/releases And if you have any suggestions about the plugin, you can write them here:

It will be preferable to people who are used to pulling the handles, who are comfortable with pulling the handles, and just want that the handles were more convenient. No doubt they will ask you: "why on earth do you prefer clicking the buttons, when you can just pull the handles?"

Just of curiosity, what do you mean by "as it is now"? Because the old version can't be perfect since it won't work with 1.1, and the new version is still pre-release, and has some bugs and some unimplemented bits. So leaving it unchanged is not the best idea, whether you want this gizmo to be added or not.

Not likely. There are many ways to make an orbit co-planar. Should it turn the orbit? Or should it try to do it with minimum dv? Or should it use normal only? Should it implement all three options (and possibly some others) and guess the best? Too many options. It's not as "turn orbit" or "circularize" which in every case has a single and determined result.

I spent the last 10 minutes just searching for any mention of this date. So, so quiet. Here's some nice thing I recently found:

Well, that's how you know it's a different mod I'm actually somewhat afraid if people start confusing the two. It wasn't my intention to hijack the idea, just make a different version. Well, there is some space left in the "next encounter" panel I'll see how it'll look.

No, it should work in the latest version. At least it works at my side. Does it show a message "Can't change the orbit, parameters are invalid" when you press the hotkey? That would mean that KSP freaked out, and you need to reload the save. There is no such thing as "unity skin" in the new gui system. You either use the default (which is KSP) or bring your own. And the one that comes with unity editor is not the best looking one. Why? Is there some particular thing you don't like how it looks? I tried to keep the proportions as close to the previous unity defaults as possible. The window is only some 10 px larger.

The text fields are uneditable for a reason. There is no way to separate hotkeys from the input, and since the hotkeys are on keypad, it will only make the things worse. You will accidentally enter the numbers into the textfields instead of hotkeys and vise versa. This actually was the prime reason why I decided to change the PreciseNode mod. You can use the new preset tool to save the values for some often-used maneuvers and load them in two clicks. As for +1 day, it's not that great idea actually. KSP only plans ahead one period for closed orbits, so while it's technically possible to set node's UT to any time into the future, it's not really advisable to move it more than one period, and can cause all sorts of weird behavior. You should use KAC or some other similar mod to warp to the transfer window time.

Well, I'd rather not introduce additional flags. Lots of switches would be confusing. As for the increment, the direction was picked kinda at random. Now that you said it, I also think that going from high increment to low is more logical than vise versa: you start with coarse and go finer and finer. So I think I'll just do that: change the default to decrease and +alt to increase. Also, right alt should also work, so unless you have really small hands, one hand should suffice

No need. I checked it already. Looks like "prefabs" is popular name for a file containing prefabs, and unity don't want to load two files with the same name. I updated the version on github, this one should work.

Hm, maybe it's a conflict between mods. Do you have anything else installed? Can you see something suspicious in the logs?

First pre-release for 1.1 is ready. The new GUI system should be much more robust and efficient, but is the absolute pain in the S to develop. Now the plugin has it's own toolbar button! Yay! Right now only the pager and a manual input modules are ready, but the rest will follow. Probably soon. The biggest changes should be already made. See the first post for details.

Can't say for sure, but probably not. patchedConicSolver doesn't deal with drawing, this count probably tells the total number patches, not how many of them are on the screen. Anyway, I'll investigate it further somewhere down the line. Right now I'm busy learning how this infernal prefab-driven GUI works.

And if it was the number of nodes that was needed to be displayed, you'd be totally correct. But we were talking about conic patches, totally different thing.

Sure, I'll still use linux. Just not for KSP. My distribution has long stopped packaging mono2 which provides .NET3.5, so it's impossible for me to develop mods in linux. Also, linux version loads screens much slower for some reason. Maybe when I finally change my old laptop to something recent and with SSD...

Show what exactly "relative to old" or "relative to new"? Both mods show only the raw dV values, you add them to "old" to get the "new". How can you show them relative to anything? intuitive maneuver changes the way the "normal" change is applied, so that it not added the raw normal dV, but instead turned the orbit in the normal direction without changing it's form. But it doesn't change the way anything is shown. You still see the same raw values.

Pretty much. At least I didn't find it. Sounds like you want a re-implementation of a stock gizmo. I don't think that any mod will ever do it. Yes, it could. I didn't say that any corrections beyond 0.01 do not change the trajectory, they do. The problem is, there is no way to predict what kind of change such corrections will introduce. If you take Precise Node or Precise Maneuver mod, and start adding and subtracting 0.01 m/s for a far-off trip, you'll see that after adding and subtracting it the trajectory will change, although it should've remained the same. That is the cumulative floating point error, which makes it pointless to change the dV with better precision, since the impact from the error is bigger than from the change itself.

Yes, of course. I didn't include the icons in the mockup, but they'll be there. The question is, if the term "conics" is that familiar to the general public. As for +/-, I'll think of a way to make it more clear what they do. And I don't think I can show the number of displayed conics since there is no API for that (maybe they introduced something, I should check). This gizmo is not for precise corrections. For that you should use the default view, which is already implemented in both Precise Maneuver and Precise Node mods. Don't think I'm getting you here. When you're applying normal, it's normal component that gets changed, and nothing else. The ability to turn orbit is already implemented in both Precise Maneuver (as a "turn orbit" control) and Precise Node (as "intuitive maneuver" switch), but there is no such thing in the stock gizmo. Ah, yes, the "execute maneuver" button was the one I wanted to add for a long time. The problem is, it's easier said than done. After looking at MechJeb code for maneuver execution I was surprised at how complicated this task is. There is no way you could take this functionality to this mod without bringing half of MechJeb's code. As for additional precision, it's not needed actually. The accumulated floating point error for long-range trips is just about the same 0.01 as MechJeb gives you. So while you can change the error threshold to 0.001 or even less, it won't change anything. You'll still have to do mid-trip corrections. This is also the reason why I didn't include the step less than 0.01 to Precise Maneuver. It is just pointless.

Hi, author of the Precise Maneuver mod here. I'm about to update my mod for 1.1, and to overhaul it a little in the process. I want to do it modular, and I'm thinking about adding this kind of gizmo as one of the modules. I imagine it to look something like this (a rough mockup, icons are not shown, but they'll be there): All the modules should be optional (i.e. node selector module, orbit mode module and so on) so in the extreme case you'll be able to disable all the modules except the one, and have a window very close in the functionality and look to the proposed in this thread. I'm still not sure about the details, and what kind of visual effects should show the usage of the controls (the hover-on glow is a no brainer obviously, but when you click and drag, should it be a stretch, or an increasing glow, or both, or what). Suggestions are welcome. I intend to start coding during the weekend, hopefully it'll be ready for 1.1 release.

Can you guys at some point give more details on the GUI update you've made, and how mods should update theirs in regards with that. For us modders to start thinking at least structurally about how to make an update.

Hm, this is a legit usecase. I think I'll introduce a way to save several presets permanently and then load them as a drop-down list. But I'll do it after 1.1 is released. It seems the release will have quite a GUI overhaul, so we'll need to see what the new default maneuver controls would be first.

Hm, never heard about unity deprecating IMGUI. So, what are you going to use now? Should add-ons also move to something else?