schlosrat

There was an issue with SpaceDock. I believe it's resolved now. In any event, there's always the option to go direct to my GitHub and get it there: https://github.com/schlosrat/NodeManager/releases/tag/0.8.1

Updated to v 0.10.7 on Spacedock, CKAN should follow shortly. https://spacedock.info/mod/3359/Flight Plan

Updated to v 1.2.2 on SpaceDock. CKAN should follow shortly. https://spacedock.info/mod/3270/Maneuver Node Controller

NOTE: For proper functionality in KSP2 0.2.2 you will need to update Node Manager to version 0.8.1. The current version of Maneuver Node Controller will then work in KSP2 0.2.2. I'll release a new version of MNC which requires this version or later of NM soon so that updating MNC in CKAN will trigger an update to the necessary version of NM.

The issue was in Node Manager, which I've updated to version 0.8.1. If you update NM to 0.8.1 this solves the problem for both FP and Maneuver Node Controller. I'll be releasing updates to both FP and MNC in the future to be specifically compatible with 0.2.2 and to require NM 0.8.1 - but in the meantime simply updating NM will solve the problem.

Release 0.8.1Minor compatibility fixes for KSP 0.2.2 with other (0.8.0) changes rolled in to align with changes in Flight Plan and Maneuver Node Controller.Download on SpaceDock

I've heard that there may be an issue with the latest release (0.2.2) that's adversely impacting FP. I'll be taking a look at that to see if I can sort it out and will post here when that's done.

I think we're already collaborating pretty well. If you like the FP interface, you can have it call K2D2 behind the scenes to execute nodes for you, and if you prefer the K2D2 interface it can call FP for you, so you really only need one or the other on your screen at any time.

Release 0.10.6Updated for compatibility with latest K2D2 version Download on SpaceDock

You probably set the altitude you want to finish at to be lower. Go to the config settings for Lift (gear icon) and set the altitude to finish at to be something higher that's outside the atmo for Kerbin.

I think that @cfloutier has a bunch of plans for future K2D2 improvements, but right now he's pretty busy with an overhaul of the UI. One of the things that he and I have talked about a little is improvement in the landing autopilot. My thought is to have FP offer a deorbit burn node that would put you on a collision course to a waypoint or lat/lon surface coordinates, and then for K2D2 to do something with the waypoint or lat/lon to try to bring the landing down more precisely to those coordinates. I don't know if cfloutier might have any thoughts on how to handle staging on the way down. My approach has personally been along these lines. If I've got a transfer stage with some fuel in it and would like to spare the fuel cost on my descent and landing stage then I may do the deorbit burn with that stage to get my craft headed toward the surface, then stage and turn things over to K2D2 for the remainder. One problem I would see is that the K2D2 landing autopilot is probably making calculations for when to turn the engine on and how long to burn based on the TWR of the current engine. If you start down with one engine, then jettison that once it's done, you would at best need K2D2 to recalculate for the performance of the new engine - and you could very easily get into a situation where you've not got enough time left to land safely with the second engine. So, it's not that easy of a problem, and the much easier thing is to make sure you're on your descent and landing engine well before you're close to the surface so that K2D2 can do its thing based on that engine. Similarly, for ascent (lift), staging can be tricky if what you want is to insert a delay between stages. Here, I think the problem is that there is both a time component (how long a delay you want), as well as the many variables of design. It would be a very tall order to ask K2D2 to assess your particular rocket design and make some choices based on that. As for using the lift curve, I'd need a bit more info to offer any advice. I've found it easy to use, but then I've been using it for a long time. If it's not doing what you're expecting then it may be that you're not fully understanding how to use it - which is something that I think can be helped.

Release 1.2.1Added check to prevent the mod UI from being toggleable while the game's UI is hidden (F2). This should help to prevent situations where the mod's UI is inadvertently raised while the game's UI is hidden which can result in the mod's UI only being visible when the game's UI is hidden and vice versa.Download on SpaceDock

I've confirmed that this state can be entered. One way I've found to enter it is to hide the UI via F2, and then launch MNC via the hotkey (Alt+N). That will quickly get you into a state where toggling the UI's visibility has MNC up when it shouldn't be and not when it should. I'm looking into this, and will also be looking for why switching between Flight View and Map View with the UI hidden has this effect. Hopefully, I can run this down soon and get a new version posted where it doesn't do this.

Update to version 0.4.0 Added capability to switch between Open and Closed part variants in the VAB. This update impacts the FPS-60, FPS-400, and FPS-2000, eliminating three parts from the part picker and instead delivering the capability to choose from Open (has no top truss structure or top attachment node) or Closed (has a top truss structure with a top attachment node) in the VAB. Selecting the Open variant will be lower mass. For backward compatibility, the old parts are all still in the asset bundle (so sadly it isn't any lighter), however, they are hidden in the parts picker. This means that any craft previously built with the now deprecated variants will still load and work as they have, but any new craft built will only have the new parts. https://github.com/schlosrat/TNO/releases/tag/0.4.0 https://spacedock.info/mod/3471/The Nuclear Option

Thanks, this does help me understand the issue better. When you’re looking for a way to plan a Gilly to Eve trajectory the tab you need is indeed the Moon tab, and the maneuver is Moon Return. Of course going the other way it’s not this tab and you’re just planning a simple Hohmann transfer. Right now the Moon Return maneuver is giving poor results for Gilly to Eve, but that is the one intended for this purpose. It sounds to me like you’re finding this arrangement of maneuvers and tabs counterintuitive, and if you are then others may be as well, but this arrangement is by design. When you go from Eve to Gilly, you’re starting in an orbit about Eve and going to another object also orbiting Eve. Consequently the tools you need are basically the same as you need if you want a Hohmann transfer to rendezvous with another ship also orbiting Eve. When you go from Gilly to Eve, OTOH, your starting orbit is not about the same body that your target is orbiting, thus the math is a little different. There is still a hohmann transfer involved, but you need to escape Gilly’s SOI first, and to do so in such a way that your excess velocity puts you on a Hohmann transfer to Eve. Tab availability is situational. If you have two ships both orbiting the same body and one targets the other you’ll get the Target Relative Maneuvers tab for Vessels. This should work at any body including moons. If you target a celestial body that’s orbiting the same body you are then you’ll get theTRM tab for Celestials. If you’re orbiting a planet and target another planet you’ll get the Planet tab which gives you interplanetary transfers. You don’t get this at a moon, which may be frustrating or confusing, but again this is because the interplanetary transfer tools are not designed to get you out of a moons SOi, and then out of a planets SOI after that to put you on a transfer to your destination. Your use case of moon to moon transfer (at Kerbin or Jool) is a good one. I’ll explore if interplanetary transfer code can be used for this since the situation is analogous