schlosrat

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

There are all sorts of things it does! It’s basically a port of parts of MechJeb2, mainly the maneuver planer parts. The interplanetary transfer part is straight up MJ. I’m still working on the Advanced Interplanetary transfer though. The basic version doesn’t cope well with different orbital planes, so the results are sub optimal and you’ll need a course correction - but I’ve used it to get to Dres that way, so it does work.

Updated to v 0.6.0 Incorporated fix for Out of Order Node Creation. With this fix, if you use Node Manager to create a node that is before any other nodes (and there are other nodes), then the new node will be the first node and the subsequent nodes will correctly be on the maneuver trajectory of the new node. No more leaving nodes behind just because you created them out of order!

I've seen this bug myself. It's quite annoying. Did you try an f5/f9 to see if that resolves it? As I recall that usually does.

Here's a video demonstrating that this can be solved today with mods. This is my first shot at fixing it, so it's not optimized or ideal, but it does in fact work. If mods can fix it then devs can fix it - and likely much better! https://i.imgur.com/bYK6xzk.mp4

@Spicat, this is a very annoying bug and I agree it really needs to be prioritized. That said, I'm not sure what you mean when you say "an inclination maneuver should only do an inclination and not enlarge the orbit" in the context of a maneuver where only normal or anti-normal burns have been planned. If by this what you mean is that you'd like to be able to set up inclination burns that have the effect that they only change the inclination, then I agree and would refer you to either MJ2 in KSP1 or Flight Plan in KSP2. They both use the same orbital mechanics code for working out the burn vector you'll need to change just your inclination leaving the rest the same. If you take a look at the maneuver nodes they set up for you you'll find that there are in general prograde and may also be radial components mixed in there. The thing that is going on is that if you only burn in the normal (or anti-normal) direction - even if the maneuver target point never moved so that your maneuver works like you've shown when you switch SAS to hold - you're going to generally raise your Ap, and for the large burns you're using in these examples, raise it quite a lot. You're adding energy to the orbit when you burn, and that energy does more than just change your inclination, it's speeding you up. Picture a 2D plane passing through your craft at the point of the maneuver node where the X axis is pointed Prograde and the Y axis is pointed in the Normal direction. You start with a velocity vector that is 100% in the prograde direction, and then you point your craft 90 degrees from that to +Nornmal and fire your engines. Assuming that things work as they should (which, given this bug, they don't), then you have a new velocity which can be seen on the 2D plane as the root sum square of the original Prograde vector and the applied +Normal vector. This new larger vector is your new prograde vector in the new orbital plane, but your distance from the CM of the planet hasn't really changed. So, you've not just changed your inclination, you've sped up quite a bit while you're in the same altitude - you've added energy to the orbit! That added kinetic energy will be turned into potential energy as you coast to your new much higher apogee. This is just orbital mechanics. For example, if you start in a roughly 500km circular equatorial orbit (i =0) and would like to change that to a 500km circular orbit inclined at 60 degrees, you're going to need to apply 1541 m/s in the Normal direction, but also -866 m/s in the prograde and 162 m/s in Radial. Either MJ2 (KSP1) or FP (KSP2) will work this out so you don't have to mess around with the math and can just have the node you need. It would then be up to you and your mad piloting skilz to execute it! (or you could hand that off to a droid)

Thanks @Anth12. I think the problem is simpler than that and could be solved today. For example, I've got a dev version of Node Manager that I'm using with Maneuver Node Controller and Flight Plan to implement a fix. These are mods, obviously, but they just call what's already there in the game. So far, I've got it where I can create the earlier node after the later one, and the later one will follow the earlier one perfectly... after you give the earlier one any adjustment. It's not completely perfect yet, as when you create the earlier node the later one briefly seems to still be on the original orbit. I think I can solve that, and plan to before I release the next version of Node Manager. So, I think if it can be solved today with a mod, then it could be fixed in the game without needing new features. Regarding the RX 6800XT, yes I do get flickering. It's annoying, but it's also not present all the time. I wish I knew what brings it on, but I don't. When it's there, it's always there and doesn't go away any time soon even with exiting and relaunching the game.

Is this an opinion, or do you have data? I have no data, but anecdotally I know lots of people who play the game and to the best of my knowledge not one of them launches via Steam. This is an admittedly skewed data set since those I know who play are also mainly modders - not that most players are modders, but that's the group I mainly circulate in. But on the other hand, it certainly doesn't require any modding skill to be able to get around Steam, and I was doing *that* before I'd started modding.

FWIW, I don't think the steam numbers tell the whole picture. Who wants to load the game through the Steam interface? I almost never fire up Steam or load KSP2 that way, and I'm in the game most days. I think regex has it right. People will come back to try out new features, content, and bug fixes as they perceive those to be of interest. I expect when we get 0.2 (Science) we will see a bump in the numbers as ppl come back to check that out. Bug fix reports like this are helping to clarify what's going on with the bugs that have caused some to put the game aside for now, so that plays it's part as well.

Thanks for the up! It's great to see this approach to bug reporting take off. As one of those affected by #5, I can assure you it impacts the AMD RX 6800 XT - which (ironically) I bought because it was the recommended AMD card when EA first came out. That said, from what I've seen this bug is mainly just annoying. I think #1 - 4 are all much more important - and especially 1 & 2, but I'd imagine different skill sets are involved in fixing those so work on 5 presumably doesn't delay or impact work on 1 - 4. I've noticed a maneuver node creation bug (which I've reported) that I hope makes it onto this list. Did you know that the order of node creation can result in a situation where editing the earlier node does not cause the later node to follow along with the patch from the earlier node? It's easy to reproduce. Just create a node some way ahead of your craft on your orbit, then create another node between that one and your craft. If you edit the closest node (the second one created), the later node stays on the old orbit and doesn't follow along on the patch resulting from the earlier node. If you create them in the opposite order all works fine, but creating them out of order makes this issue occur. This video shows what I'm talking about if you'd prefer a visual. https://imgur.com/a/1BgZ8r3

Reported Version: v0.1.3.2 (latest) | Mods: none | Can replicate without mods? Yes OS: Win 11 Pro | CPU: i9-9900K | GPU: AMD Radeon RX 6800 XT | RAM: 32GB When creating a maneuver node, if the new node is created on the active vessel's orbit at a point earlier than what was previously the first node, then the old first node (which is now the second node) is not treated as being "on the trajectory" (IsOnManeuverTrajectory == false, ManeuverTrajectoryPatch == null), and consequently when changes are applied to the new first node these changes do not cause the location for the second node to be correspondingly updated. If the nodes are created in the opposite order (the earliest node is created first), then the second node is correctly set to be "on the trajectory" (IsOnManeuverTrajectory == true, ManeuverTrajectoryPatch == patch resulting from first node), and any changes to the first node do correctly result in changes to the location of the second node. See the short video below for a simple example of both scenarios described above. ManeuverNodeOrderIssue.mp4 Observed Behavior: When a new node is placed before any other existing nodes, the locations of the subsequent nodes are not correctly updated when the new first node is edited. Expected Behavior: When a new node is placed on an orbit prior to any existing nodes, those prior nodes are updated to be on the correct trajectory such that any changes applied to the new first node correctly impact the locations of the subsequent nodes.

Here's a quick demo of Maneuver Node Controller v1.0.0 and its Post-Node Event Lookahead feature. This demo shows how a node created using MNC can be easily edited, and how the post-node events will be automatically displayed. It also shows how a node created in another application (Flight Plan) can be similarly edited and will also show its post-node events. Note that in this demo, the display of the Previous Orbit / Next Orbit info block is disabled. This is done through the MNC configuration settings panel which is shown below. You can enable or disable either of the optional info blocks (Post-Node Event Lookahead and Previous / Next Orbit Display) using this interface, that's accessed via the SpaceWarp modlist interface (Alt-M -> Open Configuration Manager -> Pick the Maneuver Node Controller mod) These optional info blocks default to Enabled as shown above, but you can disable them if you don't need them and want MNC to take up less space on your screen.

Updated to v 1.0.0! With this update, I believe we're essentially at full capability for this mod and future updates are probably bug fixes or minor improvements in UI layout, etc. This release adds some capability to reduce the amount of screen realestate needed for the mod, with the default being to give you all the info. Added Post-Node Event Lookahead information block. This info block displays up to 4 events anticipated after the selected node. If fewer than 4 events are anticipated, then only that may are displayed, and if no events are anticipated the info block is omitted entirely. The user can also enable/disable the display of this info block via the mod's configuration panel (Alt-M -> Open Configuration Manager). Reportable events include the following Collision (reported in red) SOI Entry (body and time) SOI Exit (body and time) Orbit Intersection Fly By (Pe and Inclination) Partial Out of Fuel Completely Out of Fuel Corrected issue with the Previous Orbit / Next Orbit information block where sometimes the wrong Next Orbit info was displayed Added user-configurable setting to enable/disable the display of the Previous / Next Orbit Info block (Alt-M -> Open Configuration Manager) GitHub: https://github.com/schlosrat/ManeuverNodeController/releases/edit/1.0.0 SpaceDock: https://spacedock.info/mod/3270/Maneuver Node Controller

Would it help you if I made the Previous Orbit / Next Orbit block optional? In the next version there will also be a Post Node Event Lookahead block below the Previous Orbit / Next Orbit block, This new block only displays up to the next 4 events (SOI entry / exit, fly by distance, collision, out of fuel) and automatically goes away entirely if there are no events, but it could also be made configurable optional. Changes like these would make the UI more compact at the cost of displaying less info. Other possible changes would be generally a harder to put under dynamic user control such as using a smaller font and making rows of info less tall. Such things can certainly be done, but finding a way to do them so that the user dynamically configures them may be a bit tricky.

Good question! I’ll look into that - it may be possible now that it’s a UITK gui. Also, I could make some parts of the display optional like the previous/next orbit and encounter info. Would making those parts optional help you?

You would not be the only one who finds the parts manager window... sub-par shall we say? For this, there is already a mod, but sadly it's out of date and needs an update. https://spacedock.info/mod/3292/Better Parts Manager @ShadowDev, and news on when you might be updating BPM?

Personally, I like the new UI way better, but if you just want to customize the placement of things you can do that with this mod. Yes... Eventually, the UI will be modded... any day now... Feel free to hold your breath, OK done? Now breath in!

I agree that the official modding capability is no more in question than anything else on the roadmap. In fact, it may be much less in question. There is so much of the official modding capability there already that we've found we can actually use the "official" modding capability with only a few lines of code inserted as prefix and postfix to the existing content. When this is done, it's possible to have your mod in GameData/Mods and they will load. Given that all that's needed are a few simple lines of code then I'd say it's more like a roadmap choice on their part to hold off for now, and not at all like solving more complex problems such as Therma (the point of this thread). The "official" modding support is not merely likely, it's inevitable. That said, I disagree with the opinion that the reason they're holding off is "because it turns internal APIs and data structures into public ones". There are tons of data structures that are public today. We're already able to do all sorts of things with those structures, including adding parts and bringing in complex capabilities like MechJeb. They must have some reason for their choice on this point, but given the very large swath of useful and necessary things that are already defined as public, I can't see this as a strong argument. Perhaps they'll widen the arc of public things when they roll out the official support, but also perhaps not. They may not think they need to, as so much is already public. If you would like to see for yourself, then I invite you to go exploring in the KSP2 Modding Society's API documentation site: https://schlosrat.github.io/

Updated to v 0.5.9 Updated CreateManeuverNodeAtUT to detect and prevent nodes from being created on top of other nodes. The method now enforces a minimum time gap of 1 second between nodes. This prevents a cascading error in the game's code which can occur if nodes are placed on top of each other. A warning message is displayed in the log when this occurs.