schlosrat

Thanks for the feedback! I’m glad you’re enjoying the mod. I’ve not yet observed the transfer window counting up instead of down. I’ll need to be able to reproduce this at my end to be able to run it to ground. Can you offer any info on the sorts of situations where you’ve observed this? when I think of transfer window this is only associated with transfer to a planet from another planet so I’m a bit confused about how this relates to moons or vessels targeted. Those can have an optimal time for a Hohmann transfer but they don’t have a transfer window time displayed in FP. Can you clarify what you were seeing for that? Any info may help

Yes it does. I've used it that way many times myself.

And here I thought you were holding out with a secret Tardis! Damn... This really disappoints me...

FYI, I was unable to reproduce this with KLH 1.2.1 either.

@charliepryor Which version of Kerbal Life Hacks are you running? I've got 1.2.0, which was released on 1/22 and is the most recent version I see on CKAN. That said, I also see on SpaceDock there's 1.2.1 which was released on 1/24 (only one day in the future - not sure how that's possible). MNC is working fine for me with KLH 1.2.0 (plus a lot of other mods). According to the change log on SpaceDock the addition of "buttons to warp to apoapsis, periapsis and SOI change" was part of KLH 1.2.0, and 1.2.1 just adds simplified Chinese localization and a bug fix for IVA Portraits Toggler. I'll try updating to 1.2.1 in case that breaks something, but I'm not seeing a conflict with KLH 1.2.0. If I'm unable to reproduce this problem then it would help if you could supply the log files from a game where you attempt to open MNC and it doesn't open. There are two log files: KSP2.log is found in the base folder for your game install, and LogOutput.Log in the BepInEx folder inside your game install.

If you're following the procedure I've posted above with the example for Jool then it should be working. Unfortunately, the procedure is a bit more complex than just selecting a body and asking for anode, but FP should give you a node to work with that you should be able to fine-tune with MNC. In some cases, the procedure above can give a node that results in an encounter straight away, but in any case, if you follow the procedure above I think you should be able to get a node that you can use MNC to fine-tune for a better encounter. When you say "I had FP calculate a transfer to Duna" can you elaborate on this part? Obviously, Duna had to be selected as a target or you would not have been able to get to the tab with the Interplanetary Transfer button. When was FP indicating the next transfer window would be? With the current version of FP I recommend time warping to just before the window so that FP will be telling you the next window is ~1 day away or less. If you overshoot a little that should not be a problem, but being just a day away from the window should work. Which burn option did you select? I recommend using "as soon as possible" in conjunction with time warping to just before the transfer window. What message did FP display as a status for you after you clicked "Make Node"? Did you get a Burn Timer display above your time warp bar in the game's GUI? If the start time for the burn is in the past, then K2D2 will not want to execute the node. In such cases, you may be able to use MNC (or other means) to move the time for the node so that it's in the future and then K2D2 will be willing to execute it. I also highly recommend using MNC to fine-tune the node by watching for the encounter in Map View. Once you've got an encounter, MNC is great for tweaking the node so the predicted encounter is to your liking.

I really like the suggestion for 10x/0.1x buttons to more quickly change the increment. I'll see if I can squeeze them in there. I will have to look into (1). I've not observed it doing that, but we may have different settings and I don't want the UI to auot-hide before it should. I'll be happy to implement (2) if I can sort out where to squeeze the buttons in - as noted above, I think this is a great idea. I'll look into (3) as well, I'm not sure how easy it will be, but I understand what you're asking for and agree that would be nice. I'm not sure if or how (4) can be done. It's not like this is a web page and text can be hyperlinks. If this is possible, I frankly have no idea how to do it. Maybe I'm not understanding you, but I think this is exactly what Abs is doing. You give it a delta V you want to use and press Abs, then that's the delta V you're going to get in that axis. Is this not what you're asking for? The UI is already very busy, so I'm not sure where I could squeeze this in. I'll look, but this seems unlikely. Maybe as a toggleable setting to switch between them? I've not noticed this, but I'll look for it and see if I can reproduce it.

If there's a plane change, then that's likely more efficient.

Following up on the above... Let's see how this actually works out, shall we? Here's my Jool-bound transfer and return craft. It's mostly stock other than the KESA-solar panels. Basically, it's a stack of three HFT-T-250 medium-sized hydrogen tanks with a Mk1-3 "Gumball" capsule and a single LV-N "Nerv" engine. There are four more HFT-T-250s strapped on which feed the core - the idea being to drain and jettison them along the way. With a starting TWR of 0.26 it does take some time to perform the departure burn, but eventually, we do get that done and we're safely on our way. Checking the predicted encounter right after the burn it seems we're going to come in slightly closer than the previous pre-burn prediction. Once we've exited Kerbin's SOI this prediction changes only very slightly and we've got this now Again, not ideal performance for FP, but it seems to be workable.

I had some time to play with the notional method I outlined above for a Jool transfer from a high Kerbin orbit. I chose HKO since there's time warping involved and doing that in an LKO can be tedious to the point of being painful, nevertheless, the process does work. Here's an example with some important lessons learned. First, the Interplanetary Transfer maneuver offers two burn time options: "at the next transfer window" and "as soon as possible". In this example, I needed to warp ahead about 30 days to be only 1 day away from the transfer window, but when I attempted to make a node using the "at the next transfer window" burn option it gave me a node 13 days in the future - not what I expected... but even worse the encounter was pretty much unsalvagable! Seeing that I gave the "as soon as possible" option a try and got this, which is actually not horrible as we will see With our 1A and 1B encounter markers so well aligned, it's worth pulling up Maneuver Node Controller to see how much trouble it might be to save this. Here's what you get with just a single click of the "Prograde >>" button in MNC. Well, there's our encounter! And it was only one click away - of course, Jool's SOI is freaking huge so that's a big part of what makes this easy. Orienting the Map View to give a better perspective on what the encounter will be like helps a lot here, and as you can see what we've got here is just barely in the SOI at closest approach. With not a lot of MNC fiddling (primarily to the Normal >> and Time < buttons, we're able to get this encounter So, there you have it. FP (with a little help from MNC) can give a transfer to Jool. The extra clicking is unfortunate and certainly not ideal, but it is a lot easier than making the node manually I think. One very important lesson here is to only use the "as soon as possible" burn option, even if you do warp ahead to the window.

This would be very nice! However if this is proving too hard then you might consider having the GUI display the expected lat log of the landing and offering buttons to shift it N/S/E/W. It would be really awesome if a projected landing point were also shown on the body! Something like this would require the player to get an initial collision trajectory that at least puts them in the vicinity of their target, and then gives them some tools to try to adjust onto their target

As a general workaround for the problem of poor interplanetary transfer nodes, I’ve found this approach to be helpful (I’ve done this successfully with Duna, and presume Jool will be similar). Launch your craft and get to a high circular orbit Use FP (or other tools as you may like) to find the time for the next transfer window Timewarp to a time a day or so before the start of the window - can be closer, but try not to overshoot it obviously. Use FP to make the node - (IMPORTANT: Select the "as soon as possible" burn option). You should get a not-terrible solution that’s close to giving an encounter. Use MNC to tweak the node as needed to get an encounter Use K2D2 to fly the node Warp to outside of the departing planet SOI Check to see if you still have an encounter. If not then you’re most likely very close to having one at one of your closest approaches so make a new empty node not far in the future and use MNC to tweak that, then fly it with K2D2. That should be all you need to do to get a reasonable transfer - and, yes, it’s not nearly working as well as I would like. The good news, if there is any, is that this problem is probably related to the course correction and other problems. Hopefully, when I solve one it will pay off for the others as well.

Well, there's what it’s supposed to do and then there’s what it currently does. What it’s supposed to do is give a node that will get your closest approach to be within the distance parameter - where the distance scale is in meters if your target is a vessel and km if its a celestial body. Sounds pretty good, right? Unfortunately there’s an issue with FP where the further in the future the node is that it’s creating, the more wrong that node tends to be. So, FP appears to be correctly finding a good time for the node and then botching the node. Very frustrating! I don’t recommend using the course correction feature in FP at this time. In most situations you’ll be better off using Maneuver Node Controller to manually tweak a node to get a precision effect like course correction. You could use course correction to make an initial guess for the node then tweak with MNC, or you could just plop an empty node out on your trajectory about where you might expect a good course correction to be and then tweak that. I am working on this and do hope to solve it as this problem is impacting other things like interplanetary transfer too. The time parameter on intercept is literally for your desired intercept time from now. If you make this value really small your results will not be good. You need to give it something reasonable for an intercept trajectory and then it can try to find a trajectory that gets you to your target in that much time. Depending on where you want to go this might be minutes, hours, or days for things that are relatively close. If you’re unsure how long is reasonable then feel free to poke around with some wild guesses and see what you get. This is curious. I don’t think I’ve seen it just refuse to make a node like that. I’ll take a look tomorrow and see if I can reproduce this, but as I said above I don’t recommend using course correction currently as you’re unlikely to get good results.

Updated for KSP2 0.2.0 (For Science!) Fixed issues where plumes were not visible. All SPARK motors should now have visible plumes in KSP2 0.2.0 Fixed an issue where drag was not being applied to parts in this pack. Drag should not be correctly applied to all parts. Added all parts to either the Xenon Propulsion tech tree node or the Heavy Nuclear Propulsion tech tree node. That latter is where you will find the Magnetoplasmadynamic thrusters and their Lithium fuel tanks as these are very high-performance and require stupendous (heavy) amounts of power. Updated dependency for LFO 1.0.0 (needed for plumes in KSP2 0.2.0) and Patch Manager 0.9.1 mod (needed to add parts to the tech tree) Please try it now

Localization would be rather hard to add to this mod, although as MechJeb shows, it is possible. Currently, I don't have the time needed to take on that project, nor do I have the language skills. My number one focus for improving this mod has to do with addressing the issues with moon return and interplanetary transfer features. That said, the project is on GitHub and I sincerely do welcome collaboration! If you or any other bilingual person should want to help add localization you can fork the project to work on this and send pull requests to get your work merged in. If you should choose to contribute in this way I urge you to take advantage of the KSP2 Modding Society discord - that is where you'll find a ready supply of help for something like this.

Updated for KSP2 0.2.0 (For Science!) Fixed issues where node attach was not reliably working in the VAB for the parts in this pack. Parts should now reliably stack with top and bottom attach nodes as appropriate. There are no surface attach nodes at this time, but those may be added at a later date to support having attached radiators. Fixed an issue where drag was not being applied to parts in this pack. Drag should not be correctly applied to all parts. Added all parts to the Nuclear Power tech tree node Added dependency on Patch Manager mod (needed to add parts to the tech tree) Install TNO 0.3.1 and SPARK 0.2.0 Please try it now Please try it now

I'm so glad we were able to get this sorted before Christmas! If you run into any other issues please feel free to post those here and I'll work on them when I get home. In the meantime, I hope FP can help you get where you need to go... For Science!

Big thanks to @munix for tracking down and fixing the issue in Node Manager. Thanks to him we’ve got a new release of Node Manager (0.7.1) which enables both Flight Plan and Maneuver Node Controller to work in KSP 2 0.2.2 For Science! If you have trouble creating maneuver nodes in Flight Plan in For Science! Then please make sure you’ve got Space Warp 1.6.0+ and Node Manager 0.7.1. You should be able to do this with CKAN.

We’ve tracked the issue down to a call to the CreateManeuverNodeAtUT method in Node Manager, which itself calls one of the games’s API methods. At least that’s where the Null Reference Errors are showing up. Some very talented people are helping to sort this out, so fingers crossed that we can get a new version of NM out that will enable FP to work in 0.2.0.

I’m sorry to hear that the For Science release has broken Flight Plan. Unfortunately For Science dropped the day after I left on a three week vacation and the only computer I’ve got access to is a Mac. I will look into this and see what’s going on when I get back home, but that will not be until January 8th, so my advice is to fly without Flight Plan until after I’ve had a chance to sort this out. If you’re having trouble making nodes at all then the problem might be Node Manager. Please let me know if you’re also possibly having issues with Maneuver Node Controller as that also uses Node Manager.

For what you want you should look at Flight Plan. It encompasses much of MJ other than than the autopilot functionality. In particular the things you find in the maneuver planning. FP is compatible with K2-D2 and even gives you a K2-D2 button to execute the nodes it creates. There are a couple of caveats with FP. Currently it doesn’t do advanced planetary transfer correctly so that’s disabled and there’s an issue with returning from a moon where it gives the right maneuver at the wrong time. It’s possible to use Maneuver Node Controller to adjust the time on the node for that, but the APT part is not working yet

Maneuver Node Controller should be all set now! Thanks to an amazing effort on the part of @munix, the text fields are fully functional without locking up the game input! That may sound like a simple thing, but trust me - it was not. The fix he produced will also be paying off for Micro Engineer and Flight Plan too, so we all owe him a big Thank You! You will definitely need UitkForKsp2 v 2.1.1, and MNC 1.1.1, but that should take care of it.

Ok Flight Plan should be all set now! It’s updated to 0.9.1 for real, and - thanks to a Herculean effort on the part of @munix, the text fields are fully functional without locking up the game input! He not only got an updated UitkForKsp2 out improving things for all mods that use it, he also helped track down the specific place in FP that needed an update. It seems to be functioning fine now. You will definitely need UitkForKsp2 v 2.1.1, and the for reals FP 0.9.1, but that should take care of it. Fly Smart!

I've got a test version of K2-D2 working in KSP2 0.1.5 and have given @cfloutier a PR for the fix, it's very minor. Hopefully, we'll have a working K2-D2 soon.

Yep, as Munix noted above this is in fact an issue and it's affecting multiple mods (MNC and Flight Plan at minimum). I'll work with Munix to see if we can get this sorted out shortly. In the meantime, I'd advise you not to try to use the text input fields in MNC 1.1.0 or Flight Plan 0.9.1 (which is reporting itself as 0.9.0 - but that's a separate and much easier-to-fix issue).