Morse

I actually already found it. There was a problem with gizmo section hiding/destroying. Already fixed, and the new version is up. The issue with UT non-updating is still a mystery though.

So you need a way to copy the maneuver from one ship to another (I guess you copy not only UT but also dV). I'll think of something for that. I plan for copy-paste tool anyway, to integrate with TWP. I could do the "+orbit" button repeatable. I guess I underestimated how far into the future people want their maneuvers.

It's not supposed to be editable. While I can understand why people would want to enter exact pre-calculated values for dv, I see absolutely no reason to enter the exact UT. Shouldn't be like this Is the button grayed out? If so, it means that there is no possibility to subtract the orbit - the maneuver is less than one period in the future. There is no such thing as "minimized window". If the window doesn't show, that can only mean bug. I'd like to see the logs. The nature of the prerelease is such, that things are constantly changing. Maybe we just have different versions of KSP, or maybe something deeper is happening.

Version 2.2-pre is available now. I think I found a way to add a long-asked feature of editable input fields without constant screw-ups because of the wrong focus. See for yourself if this is convenient for you. The keyboard input locks are a mess! I hope I did everything right for the input not to mess with the stock KSP, but there might be conflicts with other mods. Tell me what you find. +/- 1 orbit was an easy task, as well as AP/PE for gizmo. Other than that, just some small tweak and fixes.

No, there is not. Never had any problems to just put the maneuver node manually to the closest approach point.

This very simple mod will allow you to test various input locks during the game, to see which practical effect they will have. Very helpful if you want to prevent click-throughs in your mod: you'll know what exactly do you need to lock. Nicely complements the new Input Lock Debug Window, which only shows the raw bitmask and the list of active locks. Download https://github.com/radistmorse/KSPInputLockTester/releases/ Sources https://github.com/radistmorse/KSPInputLockTester

Screenshot is in the OP. To enable the "next encounter" section, press the relevant button in the menu. You'll see the "Next enc.:" label, the button with the name of the celestial body (press to focus view) and the label "PE:" which is the closest approach.

Not yet, no. Next week probably.

Dragging the whole gizmo left or right will move the maneuver in time. "Current" periapsis? As, for your current orbit? I don't show such info. I only show PE of the planned orbit (after the maneuver). You can also see the closest approach point for your next encounter in the "next encounter" section.

Well, I actually kinda did Good UI is not an illusion, and bad UI is definitely not an illusion. KSP mod is not a commercial product, yes, but if you're planning to become a professional programmer somewhere down the line, it's for your own good to start learning right away. I'm just trying to help, that's all. If my help is not needed, just say the word, I'll be off this thread faster than a speeding bullet

Perfectly legitimate position. But then you'll have to accept that people won't like it. Let me remind you how it all started: Well, now you know what the problem is Users usually don't know what they need, until they see it. Who knows, maybe the very function that'll make me happy is hidden behind the "rV+" button, I'll never know, because I have no idea what it does. The main purpose of the game - is to be fun (that's what differentiate the game from a helicopter). So you should ask yourself: does your mode increase the amount of fun? Does it make the performance of tasks easier? Maybe it does for the complex tasks, but for the easy tasks it absolutely does not. Again, let me quote you: Technically, you're right, they are there. But in practice, if I don't know how to access them - they are inaccessible. And if to access them is more complicated than to rewrite the TCA2... well... And don't get me wrong, I'm not trying to make you rewrite the GUI or force my opinion on you. It's your mod. I'm just trying to answer your question "why people want TCA2 instead of TCA3 which is superior in every way", because I think this is the answer. Well, at least for me it is BTW, the joke goes like this: two programmers are arguing about the best GUI design. First programmer says: the perfect gui is just an empty window with one button "make me happy". Second programmer argues: no, the perfect gui is an empty window with no buttons at all, and just the text saying "you are already happy". http://bash.im/quote/52960

Well, that's when we get to the UI. You know the first rule of the UI design? If you need to explain it, it's bad. TCA main window has dozens of buttons, but only one of them is immediately clear to me: "enable". All the others I have to guess. "PG" "RG" and all the others? Not a slightest clue. "Engine profiles"? what is that? "Macro"? Are you kidding me? Do you know what a "young programmer disease" is? When a programmer starts adding features not because they are needed, but because he can. And on top of that you have the "advanced" button just mocking at me. Saying to my face "that? that's kid's stuff. How retarded are you not getting all that from the first glance. Just wait until you get to the advanced excrements!" The autopilot modules can be guessed, but only just. What's the difference between "go to" and "jump to"? Between "level" and "cruise"? Between "anchor" and "hover"? Your UI follows the logic of the modules hierarchy, and not the user's task. When I press some button, I don't give two craps which class will do the task, but I really want to know what will happen to the craft. I enable the TCA and the control gets immediately stolen from me. The craft starts doing some weird maneuvers and I have no idea how to switch it off. That should be the basic: the button saying "do you want to fly yourself or do you want me to take over". And the button that defines whether autopilot should go straight to the waypoint, or doing the barrel rolls along the way - that should be in advanced. So my advice is: list all the tasks that the average TCA user is expected to do. It is important to list those task in user's terms. User doesn't "level", "hover" or "cruise". He has a goal in head, like "reach the destination" or "rendezvous with someone" or "intercept". It's you who should know which module is the best in solving various tasks, not him. After you get the list, you can sort it by complexity. After that, pick 2-3 first tasks, and call them "basic": your "basic" GUI should solve only these tasks. More than 5 buttons, and people will start getting confused. Look at how I did it in my... hm... version: http://imgur.com/a/nliCP Also notice how I changed the "TCA role" into something easy to understand. I understand it was the hard work to implement all that stuff. But you know what the hardest part is? To hide all that from the user. It's a pity user will never know how complex are the algorithms he is actually using when he presses the button "make me happy" (do you know this joke?). But users don't like complex.

Well, as a very casual TCA user I can suggest one big problem: TCA2 was a pilot assist, TCA3 is a full autopilot. A whole paradigm shift denoted by just incrementing the major version. I assume that lots of frustration comes from people expecting one thing, and getting something completely different. And yet, while it is different, it looks the same, at least at first glance. Add to this the complexity and GUI, which is... not the best, and you'll get your people just wanting to get TCA2 back.

Well, that's the thing, I also don't really want to maintain it, one mod is quite enough for me Ok, let's do a field test, here's the link, which will probably work, I'm not sure, never used it before https://yadi.sk/d/s6eqVb43ugh2x The plugin there provided AS-IS, no guarantee, and so on (read GPL preambule or microsoft EULA to get the picture). If there'll be someone ready to support this stuff, I'll provide the sources and everything, but other than that - don't expect any bugs to be fixed. I don't even pretend to know how this mod works, I just removed everything that looked redundant, and occasionally returned it back when it turned out that the stuff I removed was important, and the mod stopped working So use at your own risk.

@DStaal, @Fobok, if it interests anyone, I have a slightly reworked version of TCA2. I actually simplified it even further, leaving only the bare thrust balance and VSI control. On the other hand, I added some pretty GUI I never published it, because I already reworked other people's mod. Twice, actually and I really need to stop. But if people really like the idea... @allista, whaddaya say? Should I just post it, or maybe you want something to do with it?

All this is planned for 2.2, if I find a way to lock the input. I want to wait for KSP 1.2 first to see where it is going with the GUI migration.

Let's see the logs then.

To see the window you need to be in the map view and to actually create a maneuver node. "p" won't do anything before that. To select the needed modules you should press the button in the mod panel. The button appears in map view when you are able to create nodes (in career mode the building updates must be done).

Yes, I was thinking precisely the same idea at some point. The problem is, the precision of this output is insufficient. I asked TriggerAu to implement an additional feature to copy the parameters with greater precision (here) but he never answered.

Well, version 2.1 was released 10 days ago, you can find it in the usual place along with the changelog. For 2.2 I'm planning to rework the UT control, probably add +/- orbit buttons, probably add the "snap to" functionality for the gizmo, and probably to make the input fields editable if I find how to lock the input, preventing click-throughs and hotkey-throughs (is this a term?). No ETA on that though, but probably after KSP 1.2, since input locking is probably gonna change a lot.

@Boris-Barboris, I kinda sorta already did it by adjusting the old TCA ver 2.3. I also added some nice GUI to it Man, I should really stop rewriting other people's mods...

Probably. Right now the whole KSP GUI is a mess: half of it has migrated to the new uGUI system, while the other half is still IMGUI. This creates a lot of problems, including click-thrus. To fully fix it, we should first wait until KSP fully migrates to uGUI. Hopefully, they'll do it in 1.2. And who knows, maybe it'll go away by itself

@DasValdez, I just watched your stream. This is the first feedback on the gizmo tool that I got I'm preparing some fixes for the mod now and I already addressed some of your concerns from the stream. First, I removed the dead zone (there was a technical reason for it, but I changed some stuff and now it should work without it). And second, I changed the way the "undo" behaves. Now It can save any number of changes, not just the last one. I capped it at 30, should be enough for everyone. Considering the AP/PE buttons, as you noticed, KSP starts freaking out when you try to use these. Some people even report crashes (in this thread). I have no idea why. Moving the node to AP/PE is no different than moving it in any other place (and I mean literally, it's the very same function), but for some reason KSP has a spaz attack. I don't think you'd like KSP to crash in the middle of the stream If you have any other idea how to improve the tool, please write them here. I'm planning to release the next version in the coming days.

@TriggerAu, I have a feature request. I am developing a Precise Maneuver plugin, and I want to add some kind of integration to yours. The easiest thing would be to do it through the clipboard, since you already have the "copy to clipboard" function. But although it provides "normal" and "prograde", it's precision is only two digits. Can you add a button that will copy the maneuver details (prograde normal and UT should be enough) with greater precision? Even better, if this text will have some unique ID at the beginning (like "Transfer Window Planner Maneuver Detailes\n"), so that I could monitor the clipboard constantly, and if I see that ID I could be sure it's the user pressed this button. Also, the format of this text should be persistent (or at lease backward-compatible).

You can change the inclination first, and then circularize. Circularization won't change your inclination. You can also use the "turn orbit" tool.