schlosrat

Glad to hear that 0.8.12 is working for you! Have you looked at KS2? If a scripted approach suits you, then I think you may be able to put together a one-click-does-it-all approach to what you're looking for in KSP2. That said, I'm fairly certain that what you describe above simply isn't a thing (yet) in KSP2. If it is, then I'm unaware of the mod that will deliver all of what you're looking for in one package. I think we may yet get there as a collaboration with FP and K2-D2, but we're not there yet. For all things Kesa, I'll refer you to @JiMKesa - however, I do know that he recently split his mod into two distinct mods. One is for probe cores, and the other for solar power. Is it possible you've got just one of his mods installed and that one might be the probe parts mod? You can find more about Jim's solar power parts mod here: And his probe parts mod here:

I was unable to duplicate this issue in 0.1.4 with FP 0.8.12. Are there any particular circumstances that might help trigger it? I tried it immediately after opening FP (works), after creating a node (works), and after creating and executing a node (works). I did this with multiple other mods loaded, but only FP was activated and displayed. The craft I was using had both Kesa and SPARK parts and was thus also using Lux's Flames and Ornaments (for the SPRAK engine plume). So, at least with these mods, I did not observe any conflicts. The mods I have installed are the following: Space Warp K2-D2 SkipSplashScreen Node Manager Flight Plan Lazy Orbit (Boosted) Resonant Orbit Calculator Maneuver Node Controller Community Fixes Kesa Lux's Flames and Ornaments Configuration Manager UITK for KSP 2 Stellar Plasma-Assisted Rocket Kinetics (SPARK)

LOL, in the post right above yours, I announced the release of Flight Plan 0.8.12. I hope it comes as no surprise then that 0.8.11.4 is in fact out of date. Thanks for the feedback. I'll look into this and see if I'm able to replicate the issue.

In KSP2 currently, I think that a single-click operation like you're asking for here is only possible in KS2, which flies scripted flights. I've not used it lately, but it may have something like (or close to) what you're describing as a stock script, but it's not as interactive as, say, Flight Plan and K2-D2. That said, FP and K2-D2 are not single-click, but pretty close. K2D2 has a Lift mode that will fly your ascent, but I don't think it does auto staging yet and it won't automatically circularize your orbit. You can get FP to set up the node with perhaps two clicks, plus one more to make K2-D2 execute it for you. Conceivably, K2-D2 could probably get all of this down to one click as FP does have a Library mode where other mods can call it. If K2-D2 were to add auto-staging and auto-circularization (where it would just need to send the appropriate request to FP at the appropriate time), then that could likely get you down to one click.

Thanks for the heads up! It's fixed now.

Updated for v 0.6.2 Updated for compatibility with KSP2 0.1.4 Honestly, why are you still using this mod? You do realize that Flight Plan has fully absorbed all the Resonant Orbit Calculator functionality? Please! I'm begging you! Don't download this, just use Flight Plan instead! It's much better and does so much more!

Updated to v 0.6.1 Updated for KSP2 0.1.4 compatibility. Previous versions of Node Manager will not work correctly with KSP2 0.1.4+. You must update to this version (or later) of Node Manager if you want to use it with KSP2 0.1.4+ Updated dependency on Space Warp to version 1.4.2 (same reason)

Update to v 1.0.3 Updated for KSP2 0.1.4 compatibility. Previous versions of Maneuver Node Controller will not work correctly with KSP2 0.1.4+. You must update to this version (or later) of Maneuver Node Controller if you want to use it with KSP2 0.1.4+ Updated dependency on Space Warp to version 1.4.2 (same reason) Updated dependency on Node Manager to version 0.6.1 (same reason)

Updated to 0.8.12 Updated for KSP2 0.1.4 compatibility. Previous versions of Flight Plan will not work correctly with KSP2 0.1.4+. You must update to this version (or later) of Flight Plan if you want to use it with KSP2 0.1.4+ Updated dependency on Space Warp to version 1.4.2 (same reason) Updated dependency on Node Manager to version 0.6.1 (same reason)

Regarding installation, CKAN is also an option for installing SpaceWarp and its dependency UITK For KSP2. Of course, CKAN can also help with installing SpaceWarp mods, too.

In the game's code, there is the concept of an OAB (Object Assembly Building), which is generic and can be applied to orbital construction, base construction, or as we see it currently in the VAB. We'll eventually see that applied to orbital, bases, and boats, and I very much look forward to seeing how it works out! That will be really exciting and fun. Essentially, they've designed this part of the game's code to work in a number of situations and the part of the game that you're interacting with in the VAB is a deployment of the underlying general capability. So, when we do get orbital, base, and boat construction it will leverage the work they've put in and that we've seen arrive in the VAB. Consider all the patch notes referencing things fixed or improved in the VAB as generally applicable to the development of other instantiations of the OAB and a direct investment in the future delivered capabilities. It would be a mistake to think that they haven't been working on the other types of construction as their work (the parts we've seen) is actually on the underlying OAB and its current instantiation in the VAB. Also in the game's data, we can see some of the parts that they're planning for interstellar. You can't access them while playing yet, but being able to see them we can tell that (a) there are some very big parts coming, and (b) they're further along with that part of the design than may be otherwise apparent.

Wow! And thanks, it's such an honor to be selected for this, especially with so many other truly excellent threads! Congrats to all the winners and nominees, and congratulations to you on your new gaming laptop! I'm glad it (eventually) arrived and hope you get countless hours of fun with it!

Updated to 0.8.11.4 Added check for creating a maneuver node within 30 seconds of an existing node. Previously there was no check and if the player clicked Make Node when they already have a node at the time necessary for the maneuver they're requesting Flight Plan would create the new node on top of the existing node which could result in errors in the game as nodes should never be within 1 second of each other. The limit is set to 30 seconds margin in Flight Plan because realistically you need time to orient your craft between maneuvers. Updated functionality to allow access to the Advanced Interplanetary Transfer button. NOTE: These features are a UI PREVIEW that does not currently allow the creation of Advanced Interplanetary Transfer nodes, but does serve to test and demonstrate the layout and functionality for Porkchop Selection and Limited Time options. Organized the Advanced Interplanetary Transfer Panel to govern what is displayed based on the Burn Option (Porkchop Selection vs. Limited Time) so that only the things needed for the respective options are present and the window size is minimized. Added time input for Max Arrival Time in the Advanced Interplanetary Transfer: Limited Time panel. This takes a time input in y d h:m:s format (e.g., 1 y 425 d 5:59:59.123) and is initialized to the minimum time expected to be possible. When inputting time all possible parameters are not necessary, so if the number of years is 0, you can enter that time as 123 d 5:59:59.123, etc. The string simply needs to be parseable as a valid time in the Kerbal sense (6-hour days, years are 426 days long, etc.) Improved the accuracy of the Porkchop plot in the Advanced Interplanetary Transfer: Porkchop Selection panel. The porkchop plots produced now correctly resemble those produced by Mech Jeb in KSP1 for the same initial time and planet selection. GitHub: https://github.com/schlosrat/FlightPlan/releases/tag/0.8.11.4 SpaceDock: https://spacedock.info/mod/3359/Flight Plan

Fixed (mostly) in v 1.0.2 Updated Automatic Shutdown capability so that it will not automatically close until the last node has been completed. Previously, it would close as soon as the universal time was greater than the start time of the last node, which had the effect of taking down the GUI before the node was completed. Corrected logic so that with Automatic Shutdown turned on, the GUI will stay up when commanded up by the player (via the app bar or hotkey), or when commanded up by another application (e.g. Flight Plan, etc.). With this change, Maneuver Node Controller will stay up until either it's manually closed or a node has been created and that node was subsequently deleted or completed. There is one little wrinkle that I was not able to track down and fix - it may be in the game's logic as I could find no cause for it in MNC. For some reason, if you're in Flight View and you've not yet switched to Map View at least once during your game session, then when you create a node using Flight Plan (or presumably any other mod that can create nodes for you), then MNC does not come up automatically even if you have Automatic Launch turned on. If you flip into MapView, then MNC will pop up automatically, and if you've ever been in Map View previously since you launched the game, then MNC will auto Launch from Flight View. This curious behavior leads me to suspect there's something fishy going on with the game itself that gets sorted out once you've visited MapView at least once. As it is, the workaround is simple. Hit "m" to switch into map view, and then hit it again to get back to flight view if that's where you want to be. https://github.com/schlosrat/ManeuverNodeController/releases/tag/1.0.2

Thanks for the feedback! My hunch is that what's happening when MNC goes away during the burn is that it sees the current node as being in the past and so lowers itself. It should be fairly easy to have it drop only after the current burn is done, perhaps with a bit of margin. I've got an idea for how to work that, so I'll see if I can get something out soon for that. For the second matter, I had thought I'd solved that when I was testing it, but I'll look again. It would help me if you could jot down the steps you've taken when you've seen this happen so I can do my best to recreate them.

Updated to v 1.0.1 Added new configuration parameters for autoLaunch and autoClose (both defaulting to false). When Automatic Launch is enabled, then MNC will automatically launch itself any time a new node is created (either manually, or by any other means) When Automatic Shutdown is enabled, then MNC will automatically hide itself any time there are no nodes remaining in the future. SpaceDock: https://spacedock.info/mod/3270/Maneuver Node Controller#changelog GitHub: https://github.com/schlosrat/ManeuverNodeController/releases/tag/1.0.1 You can access the MNC configuration parameters by going into the MODS menu on the launch screen or pressing Alt-m in-game. From there select Open Configuration Manager. Within the configuration manager, pick Maneuver Node Controller 1.0.1 and set up your preferred configuration values which will be set each time you launch the game.

I'm not aware of anyone working on ion/electric engine mods, but I suspect they may not be too terribly hard to do given all the work @LuxStice has put into what he's done. Are you basically looking for more engine options than the stock game IX-6325 "Dawn"? Are there specific engines you would like to see, or do you just want more variety than the game currently offers?

A lot of the active KSP2 modders began modding after KSP2 came out. You'll find that there are plenty of folks who started out with the very same question and will be willing to help you find your path. It may not be as hard as you imagine to get started. I'd never coded in C# or worked with Unity or anything like that when I started modding.

There isn't any auto-docking mod in KSP2 currently that I know of, but there are some mods that may help you with some parts of this. If you have Flight Plan and K2-D2 together, then those can help you with the rendezvous part. I believe K2-D2 is working on an auto-docking capability, but I'm not sure how close it may be to being released. Flight Plan also helps with selecting a target vessel to rendezvous with and selecting a docking port on your target once you're close. Once you're in the vicinity of your target then there's Docking Alignment Display, which may also help you. It's not going to auto-dock, but it can help tremendously if you want to try your hand at a manual approach. One trick I do (works in both KSP1 and KSP2) is to do what I call "cooperative docking". This is a simple technique that can be used with any two vessels that have docking ports and can be actively controlled by you. Let's say you've got two vessels, V1 and V2, and you want V1 to approach and dock with a port on V2. Hopefully, here V1 has a docking port that faces "forward" as that will make it easier. Make V2 the active vessel Pick the docking port on V2 you want to have V1 dock with and set "Control from Here" Set V2's target to be V1 (or better - target V1's docking port) Turn on SAS (not RCS!) and have V2 point at its target. When V2 stops moving it should have your desired docking port pointed right at V1. Leave V2's SAS on. Make V1 the active vessel Pick the docking port on V1 that you want to use to dock with V2 and set "Control from Here" Set V1's target to be V2's docking port Turn on SAS (not RCS!) and have V1 point at its target. When V1 stops moving it should have its docking port pointed right down the axis for V2's docking port. Once V1 is pointed well at V2 then switch SAS to hold the attitude and not point at the target. Turn on RCS and give V1 a nudge in the forward direction. Aim for a closing speed of < 1 m/s when you're close. Watch V1 glide up and dock with V2

@Shinotama / @Sea_Kerman, The stock game may prevent you from editing maneuver nodes while paused, but - just so you know, this is not the case with mods. If this particular aspect is annoying you then please try Maneuver Node Controller. It's been able to create and modify nodes while the game is paused since it was first released. This means there's no in-game functional reason for not being able to create or edit nodes while paused other than the stock UI is not letting you do so. If the UI would let you click the node and open the widget, then fiddling with the node widget would make immediately evident changes to the resulting trajectory patch just as fiddling with the node in MNC does. The parts of the game that update the trajectory patches if/when a node has changed are still running while paused! I'm not sure if this is a bug, per se. It may be more of a UI design aspect. I suppose this comes down to the question: Is the game working as intended when it prevents you from editing a node while paused? That would be a good question for the devs, and the answer might speak to when or if you'll ever see the stock game catch up with what mods have been doing in-game now for months. In either case, bug or silly UI limitation, I agree it's annoying and there are certainly good use cases for being able to do these things. If this is working as intended, then I'd want to ask the devs why they think this limitation makes the game better. I would happily join you in arguing that it certainly doesn't.

Wow, that's a lot of bugs nailed down! Still a few big ones in there, but dang this is a lot of progress on the bug front! Well done! Looking forward to 8/22! Thanks for the extra context on these. This is helpful and appreciated.

Glad to hear that the UITK scaling is helping you! Your suggestion to allow for auto-hide / auto-appear is an interesting one. That may be feasible, I'll look into it. What do you think you might like to see if there is more than one node out there? Presumably auto-hide only takes place if there are no nodes remaining in the future, but if you've got, let's say, three nodes ahead and one of them completes, then I'm assuming that would mean "stay up please" unless you choose to dismiss it via the app bar button or the close button.

That's a great question! it turns out that what it does is... nothing. By that I mean it doesn't delete the node, and presumably doesn't change any of it's properties - it leaves the old node hanging in space, but not necessarily where you might think it should be. Suppose you;'ve got a node that would take you from Kerbin to Mun and you've fiddled with it so that it's just grazing Mun on one side. As you go from a near miss to a collision, the post-Mun node jumps to an odd location that may be some distance from where it was pre-collision. Moreover, as you keep fiddling with the lithobreaking trajectory the "post-Mun" node keeps moving around! There's a discontinuous jump from where it was right before your trajectory intercepted the Mun to where it is (hanging in space), and then it moves smoothly while you keep adjusting, and then another discontinuous jump once you've adjusted the earlier node so much that you're just grazing the Mun on the other side and no longer on a collision course.

In KSP2 if you create nodes in order from earliest to latest, then adjusting the earliest node moves the later nodes - just like in KSP1. In fact, the game tracks this with a couple of properties on the node. The first is the boolean IsOnManevuerTrajectory. This is set to false for the first node, and true for subsequent nodes which have been placed on patched conic maneuver trajectories. In addition to this, there is also the property ManeuverTrajectoryPatch. This is set to null for the first node (or any node which is not on a maneuver trajectory) and to the correct patched conic patch associated with the time of the node. Patches run from a start time to an end time, so if Patch 0 starts at x and ends at y, and Node 1 (the second node) is at a time between x and y, then any change to Node 0 (which has a burn time that ends at time x) will result in Node 1 moving so the node control gizmo is at the right place based on its node time and the shape of Patch 0. What happens when you create nodes out of order is most definitely not intended, as what's going on is that you've created a node at some time y, and since there were no prior nodes at the time you made that one, its IsOnManevuerTrajectory = false and its ManeuverTrajectoryPatch = null. You then create another node at time x (which is < y), so that node also (correctly) has IsOnManevuerTrajectory = false and ManeuverTrajectoryPatch = null, but the previous node is not updated to have its IsOnManevuerTrajectory = true and its ManeuverTrajectoryPatch = the patch from the new earlier node. This is a bug, as this could never be the intended behavior unless we assume devs are devious and want to confuse players (which is patently false). We can see what the intended behavior should be by creating nodes in order. There is no use case where the player would want the later node to *not* follow the patch of the earlier node as that just means there's a node for that vessel that can never be reached - so they would need to delete that one and recreate it. Thus, this a bug. It would be nice if the game were smart enough to handle nodes created out of order as players tend to be humans, humans do silly things like this, and the game will let you create nodes out of order, so why not handle it gracefully?

I don't know if it's intended or not, though it would seem really odd to me if it were. My hunch is that it's unintended. Also, I've found that it's actually not computationally expensive. I've already fixed this in the Node Manager mod where v0.6.0 of that mod now supports out-of-order node creation. This fix won't help for nodes created manually, but for mods that do call NM, the fix works fine and is a proof of concept for one way to fix it. The fix itself is pretty simple. You can see a video of it working here: https://i.imgur.com/bYK6xzk.mp4