schlosrat

Node Manager has been updated to 0.7.3 which should correct the issue of stale node info remaining from a previous session when you load a different save. This does not address FP starting raised in the new session with the previous tab and maneuver type already selected from the previous session. That will necessitate an update to FP, which is forthcoming. https://spacedock.info/mod/3366/Node Manager https://github.com/schlosrat/NodeManager/releases/tag/0.7.3

Yep, that's probably in Node Manager. I'll run that one to ground and get a fix out which should solve this for both FP and MNC.

Thanks for the feedback. I'm glad you're finding these mods useful! The first problem is actually in Node Manager - which is a mod FP and MNC depend on that runs in the background. It's maintaining a list of nodes, and apparently, this is not being cleared and reset when you load a save - hence the stale info from before. I'll get to work on this as it clearly should be handling this more gracefully. Once fixed in NM, the problem should vanish in FP and MNC. For the second problem, I may need a bit more info, and it also may help if I cast a bit more light on what FP is really doing. I'll start with the latter. tl/dr: FP is already backing the node off to make it star before the actual point you want the burn to be centered on. When FP creates a node it does base the *initial* position of the node on orbital mechanics equations that assume the burn is an instantaneous impulse. This is part of the MechJeb heritage and has the virtue that the equations are well-known and not hard to model. However, KSP2 handles burns a bit differently than KSP1, so FP carries on to adjust the time of the node, and consequently the direction of the node so that it will instead start earlier by 1/2 the burn duration. This is a two-putt approach because to get the burn time we must first *create* the node and let the game work out how long the burn needs to be for that craft to get that delta v. So, create the node, get the burn duration, back the node start time off by 1/2 the duration, and then (crucially it turns out) adjust the direction of the node. The crucial node direction adjustment is most apparent in the circularize after ascent problem. The thing here is that burn vectors are in Prograde, Normal, and Radial, and when you back a node off it will be at an earlier part of the trajectory where the prograde and radial vectors were very likely pointed in a different direction, so FP does a little math to make sure that the node, when positioned at an earlier time, has new P/N/R components that will point in the same direction the original non-adjusted node would have. Hopefully, that makes sense - now on to the request for more info! In the example you're using are you basing this on a very steep ascent profile? By steep, I mean one where you've begun your turn quite high and late in the ascent and so arrive at the Ap with not much horizontal velocity. If so, then I have your answer, but if not then I'll need more detail about the example problem so I can try to reproduce it and see what FP may need to do. What type of trajectory are you starting with: suborbital or orbital? for the initial orbit, what are the Ap and Pe? If you are talking about the problem of circularizing after a very steep ascent trajectory, then here's my answer. In such cases, particularly when the Ap is not all that far outside of the atmosphere, you can get into a situation where the node FP gives is not ideal. This is because such a trajectory is developing very little horizontal velocity resulting in needing a much longer circularization burn, and this is coupled with a more tightly turning prograde vector at the Ap of the suborbital trajectory. The solution to this is to fly a better ascent profile where you begin the turn earlier and arrive at the Ap with more horizontal velocity. That's more efficient, too. Alternatively, you can use MNC to make precision adjustments to the node, which you can even do with the game paused! So if you prefer the steeper inefficient trajectory, then as soon as you've got a circularization node from FP, press pause and bring up MNC. Now you'll be able to make very precise adjustments without worrying that your Ap is getting closer by the second, and when you un-pause you'll have a node to get the orbit you want.

No worries, it was good to test this out. TBH, I hadn't ever done a test like this to confirm it would work under timewarp (so long as you don't have such a long burn you'd need to change orientation). This is good to have proof that it does work!

I was unable to replicate this. I build a probe with an X4 NHT, a PB-X750 Xenon tank, an SWR-125 stabilizer, an RC-001S probe core, and an FPS-400 reactor (plus some lights). Pretty basic. I teleported it to a 120km circular orbit and planned an inclination change from 0 to 10 using FP. With the reactor turned on, the throttle at 0, and the engine activated, I had FP tell K2D2 to run the node. As soon as K2D2 has the node running (throttle up) I ramped up timewarp to x4 and was able to observe the delta-v remaining decrease at a more rapid pace than when at 1x timewarp. I tried playing with timewarp at 1x, 2x, and 4x, then left it at 4x until the end of the burn where I found I'd gotten 9.603 degrees inclination. Not perfect, but not bad either. I tried it again running at only 1x timewarp and got a final inclination of 9.632 (pretty close to the same). So I tried it again at 10x timewarp and got 9.597 degrees inclination. So I tried it again at 50x and got 9.599 degrees. So I tried it again at 100x and got 9.610 degrees. So I tried it again at 1000x (max for this altitude) and got 9.617 degrees. I'm not seeing the issue. If you can reproduce this can you please send me a save file to try out at my end?

Munix is correct in that I was referring to the inability to change attitude (or gimbal engines) during timewarp. If I can reproduce the problem we may be able to sort out what's going on. I'm not expecting an issue with the spark engines here since I made them by taking stock engines and changing some values where necessary. They're all fundamentally adapted from the Dawn, and really not that different from any other ordinary chemical engine aside from consuming different resources much like the Dawn. If stock engines produce the right level of thrust while under timewarp, then I don't know of any reason why the Spark engines wouldn't do so as well. That said, the thrust levels are so low that for any sort of optimal burn trajectory over a longer period, you may need to change orientation - and you can't while timewarping.

Updated to 0.10.1 Added Click-through Blocking GitHub: https://github.com/schlosrat/FlightPlan/releases/tag/0.10.1

Thanks! Glad to hear it. MNC will remember the last settings for whether these foldouts are open or closed, and it won't matter if you're launching from the app bar or FP. If they were open when you shut MNC down, then they'll be open the next time you launch MNC and vice versa - so long as displaying them makes sense. https://i.imgur.com/P7QA5jJ.mp4

Update for version 1.2.0 - bringing several of your recently requested features and improvements! Overhauled UI for a new more compact layout (big thanks to @munix!). Burn vector values are now displayed in editable text boxes co-located with the << < > >> buttons. Abs input and button are now obsolete and so removed. Next Orbit and Post Node Lookahead are now foldouts. These are still controlled (enabled/disabled) by user-configurable mod settings. When enabled, they are now in foldouts so that they can be minimized when not needed. Updated << < > >> ^ v buttons for better readability. New graphical elements used for << < > >> and x10 ÷10 used for more intuitive step increase/decrease buttons. Added user configurable precision (rounding) on displayed/editable time and burn vector values. Added click-through blocking. When you first start MNC if there are no nodes, you'll still be greeted by this window If you should use the Add First Node button to make a brand new empty node, then you'll see a new more compact window like this. Here you'll see some excellent work that @munix contributed making the overall layout much more compact and efficient, and greatly improving the look of the buttons. The general layout is similar to what you may already be comfortable with, so not much to adapt to here - just less of your valuable screen real estate gobbled up by a hungry mod! Also, more intuitive buttons to boot! If you unfold the Orbit details foldout you'll see the info you would expect to find there One big change, of course, is that the Prograde, Normal, and Radial displays are now between the large and small step application buttons. But now the vector burn values are editable text fields, so there is no need for a separate Absolute value entry or "Abs" button to apply it - just click into the text field and type away. Naturally, if you happen to goof the entry in a way that it would not make sense as a number, the UI will alert you as shown below. If you have a target object that's in orbit around the same body your vessel is orbiting then of course there will also be ANt and DNt Snap To buttons as shown below If you have a maneuver node that will give you a new orbit with an encounter, then of course you can get that info too. And if the encounter might be a problematic one, you'll still be alerted to that as well If you go into the mod settings, you'll find that there is now a way to set the precision for burn vectors. The default is two decimal places, which gives you cm/s precision on the node - probably plenty for most purposes. If you feel you need more, you can bump that up to as much as 6 or down to 0 if you like. GitHub: https://github.com/schlosrat/ManeuverNodeController/releases/tag/1.2.0 SpaceDock: https://spacedock.info/mod/3270/Maneuver Node Controller Or better yet - just use CKAN Done! (thanks to @leonardfactory!) Done! (thanks to munix!)

I'm not opposed to these changes, but I do have some concerns and thoughts here. You've hit on the reason I've not done your first suggestion yet. Yes, those three lines for Prograde, Normal, and Radial can be combined, but doing so will make the display of the value a problem for larger maneuvers, which are not that uncommon even now and will eventually be even more so. Perhaps if the width of the whole UI frame were expanded in conjunction with making the adjustment buttons smaller... Your other suggestion of ditching the Abs value line (and buttons!) and making the displayed P/N/R burn an editable field may help with this. I like that idea! Doing this would add a little more space to those lines, and might make your suggestion above possible - or at least less problematic. For the Previous Orbit / Next Orbit, and for the Post-Node Even Lookahead - both of these blocks are configurable (to display them or not) in the mod settings. That's not as convenient as a foldout, but it does mean that when they are not present they are really not present at all. @munix has kindly offered to take a stab at these (and he's far more of a UI wizard than I'll ever be), so there's definitely hope! In the meantime, you might try switching off the optional parts of the UI if you don't feel like you need them. https://discord.com/channels/1078696971088433153/1089311169937936424/1201272669304266822 Oh, you and me both, friend! This is a chronic problem for which I'm not sure if we have a solution in sight. This problem is far bigger than this one mod, and in fact, affects nearly all mods that have a UI.

Updated to 0.10.0 Updated to the latest mod template for better development and maintainability. Added fonts to the asset bundle in preparation for localization work - this makes the size of the download much bigger, but does not affect performance in the game otherwise and will enable localized versions of FP in the future. Corrected issue with calculation of the next transfer window time where the time to go was not computed correctly for transfers to orbits lower than the originating orbit. Note: this update requires you also update Node Manager to 0.7.2+ if you want to get the corrected Next Window calculations. In all other respects, it's compatible with NM 0.7.1 GitHub: https://github.com/schlosrat/FlightPlan/releases/tag/0.10.0 SpaceDock: https://spacedock.info/mod/3359/Flight Plan

Also relating to CKAN - I've seen issues even with the latest CKAN version where SpaceWarp will report that a mod I've got is out of date but CKAN doesn't see that update yet. I suspect it's just a time zone issue - and something CKAN can and should be able to sort out - but give it time (a day or less), and then CKAN will see the updated mod. That said, you can most likely install that one mod manually if it's the only one that's changed especially if you've installed previous versions before. One of the things we get from CKAN is dependency checking. Unless the new version of the mod you want adds a new dependency that wasn't there before, you should be safe manually installing it if you don't want to wait for CKAN to catch up. That's what I do.

Ah ha! I may have a solution for you. Create a dummy node in the future between your vessel and the first node hanging in the air. Use MNC to make a small adjustment to that node - like +5 m/s prograde or whatever. The process that MNC uses to make this adjustment should cause all the other nodes to jump back onto their trajectories. Now just back that change out, and then you can safely delete the dummy node. Or, you might use the dummy node as a course correction node to trim out any error from the burn of node 1 (in the past). Essentially, you'll be causing the game to do what it needs to do to update the future nodes for you.

I don't have a problem with this mission. I have a problem that there's no mechanism in the game to dismiss it. There will always be missions that, for whatever reason, you decide not to do. I don't like building and flying planes, for example, so I typically skip the various explore missions in Kerbin where a plane is typically intended. Fine. Cool. No problemo. Now give me a way to say No Thanks to a mission so I never need to see it again. That's what's missing here.

Ahh, I see the challenge you've got - or I think I do. Let's see if I do. Suppose you've got a chain of 3 planned maneuvers stacked up, and you attempt to execute node 1 but it burns a bit short or too long or something. The future nodes are still planned, but the burns they're planning are based on an assumption that you execute node 1 correctly. Since it came up short or long or just a bit wrong in some way, then the planned node 2 won't have the initial conditions you had intended and so it's going to apply the wrong delta-v for the outcome you desire if you carry on and execute it perfectly without first modifying it. In this case, there are two things you might do, and in both cases, I would recommend using Maneuver Node Controller. First, you could do as you've suggested and add another node between the mis-executed node 1 and the future node 2 to try to get back on track. MNC doesn't want to do this natively, but it can help you nevertheless. You can manually drop a node on your trajectory approximately where you would like it, then use MNC to fine-tune that node to get things back on track. In many cases, this might be the easiest and best way to do it - much like a real mission planning a mid-course correction. Second, you may be able to get what you need in a situation like this by editing node 2 to compensate for the error from node 1's execution. Again, MNC can help. What you can't presently do (no mod I'm aware of will do this) is to automatically make the updates you need. That would be some tricky orbital mechanics. You could sort of do it with Flight Plan, but that would involve deleting the future nodes and letting Flight Plan make brand-new ones for you that accomplish what you want. Not really editing the future nodes so much as scrapping and re-making them. Did I understand the problem? If so, then I hope this may help you get where you're going, and if not then please set me straight and we'll give it another go.

Update to MNC 1.1.3 Converted single-press buttons to repeat buttons for actions that apply small and large steps. This has the effect that if you press one of these buttons a single time and release you get the "normal" behavior, but if you press and hold, then after a brief delay (nominally 1 second) the longer you hold the more times the effect is applied (nominally 10 times/sec). The delay and interval are user-configurable so that you can adjust how sluggish or speedy it is to your taste. Fixed issue where, if Auto Shutdown is enabled, you would not be able to raise the UI by pressing the app bar button unless a node is present in the future. Now you should be able to force the UI to appear when you press the app bar button and it will remain up until you've created a node or dismissed it manually. If you create a node, then it will continue to remain up until the node is past and there are no future nodes, or you dismiss it manually. Added a user-configurable delay for the application of the Auto Shutdown feature. This is not quite working, but the configurable is there for future use when I sort out how to make it work better. Nominal delay time is 10 seconds. https://github.com/schlosrat/ManeuverNodeController/releases/tag/1.1.3 https://spacedock.info/mod/3270/Maneuver Node Controller

With further testing, I believe it's possible the message you'll find in your log could be "Automatically closing Maneuver Node Controller due to autoClose == true and nodeCount == 0". What I've found in KSP2 0.2.0 is that if there's only one node, and you get past it by a bit, the game will report that there are no nodes and this can trigger. MNC gets the count of nodes from Node Manager, which in turn gets it from the game like this public int RefreshManeuverNodes() { RefreshActiveVesselAndCurrentManeuver(); ManeuverPlanComponent maneuverPlanComponent = activeVessel?.SimulationObject?.FindComponent<ManeuverPlanComponent>(); if (maneuverPlanComponent != null) { Nodes = maneuverPlanComponent.GetNodes(); } return Nodes.Count; } I've observed MNC autoclosing due to this even when the node gizmo is still on the trajectory, but it's a little way in the past. I've not timed it, but it's not triggering the instant you're past the node, so I'm not sure what the criteria are. Given this, the "fix" I've attempted to put in place is not working. What I did was to make a user-configurable setting to let you set how long you'd like the window to persist, but that's not the branch of code I see bringing the UI down, so my fix may not help in your situation. On the plus side, I believe I have gotten it to where, with Automatic Shutdown enabled, you can bring up the MNC UI even when there are no nodes yet. What it's doing for that is it forces the UI to be open until you've got a node (or you close it manually), and then after that, it behaves "normally". This isn't what I think you were looking for, but I think it is an improvement on the other end. That said, I have gotten a button repeat capability I think you were looking for! I should be releasing that shortly.

This is helpful. Your video clearly shows MNC performing an AutoClose while there is still a node present. It so happens that in every control branch where AutoClose activates there is logging to indicate which branch is triggering and why it's triggering. If you look at a log file from a game session where this has happened what I expect to see is a message like "Node[0].Time + Node[0].BurnDuration + 10 <= UT". Essentially, with AutoClose turned on, MNC will close its window when you're 10 seconds past the end of the burn time. That works great if you're executing nodes with K2D2, but with your manual technique of full throttle until close, then switch to ~5% and creep up on the orbit you want, you're just taking longer than MNC expects you to. One possible fix here would be to parameterize the slack at the end and let you choose how long you want MNC to persist. Or, you could just switch off AutoClose and then it won't close for you.

Update to MNC 1.1.2 * Added increment (↑) / decrement (↓) buttons to the right of the text input fields for Absolute Delta V, Small Step Delta V, Large Step Delta V, Small Time Step, and Large Time Step. These buttons increase and decrease the values in the test input fields by factors of ten to enable more rapid change of the step sizes when adjusting nodes. * Updated progect dependency for Node Manager 0.7.1, SpaceWarp 1.8.1, and UITK 4 KSP 2.4.2 * Corrected minor text alignment issue for the Ap displayed as part of the Next Orbit block https://spacedock.info/mod/3270/Maneuver Node Controller https://github.com/schlosrat/ManeuverNodeController/releases/tag/1.1.2

1: Nodes exist on orbital patches and define the transition from one patch to the next. When you delete a node in a sequence (say the 3rd of 5 for example) you've removed the patches that the future nodes are associated with. In the stock game if you've got 5 nodes and you delete the 3rd one, then you lose nodes 3, 4, and 5. The same happens in NM since it's just a way to enable mods to create and destroy (manage) nodes in the base game. 2: This may be a possible feature, but it will be tricky. In the stock game, you can create a new (empty) node between two nodes. This is possible since the new node has no maneuver component initially, so any nodes following it are already in the right place and they just need to be re-mapped to the new patches that exist because of the new node. Presently, using Maneuver Node Controller to add a node to an existing set of nodes will always result in the new node appearing after what was previously the last node in the set - which is the safe thing to do, but if you're adding an empty node then you should be able to insert it just like the stock game allows. That said, we can look at what happens with Flight Plan if you try to do this where you're also going to define a burn on that node. Consider this (wacky) scenario. Here the starting situation is that there are four nodes doing various minor things on the orbit where the first one happens to be at the Ap for the current orbit (default initial time from MNC). There are two more nodes not long after that, then one that's on the other side of the orbit. https://i.imgur.com/O9SXu3k.mp4 Using FP, we ask it to circularize at the next Pe. This will call NM to create a node at the time for the next Pe on the current orbit. As you can see, this causes a little bit of chaos and results in the last node seeming to be hanging in space. It's not really like that, but that's because the game hasn't updated the last node for the new patch it's on. One way to get it to update all the nodes is to make a small change to one of the earlier ones. When we do this with MNC, then we can see that the nodes are where we asked for them. So, as you can see, adding nodes between other nodes is possible in NM. In the example above FP called NM to do precisely that. NM will happily create nodes wherever you ask it to - or more accurately whenever since nodes are associated with a time. The issue is that when a node is inserted into a chain of nodes we need to re-update things. I've played around with automating this in the past, but there's a weird lag and I've never been successful in automating the update. We can trigger an update manually with MNC, and then back out the unneeded change very easily, but automating the update runs into issues with how the game handles information. The automation tends to arrive before the game is ready for it, but if you do it manually you'll be fine.

@Sade makes a good point. Asking for this in K2D2 may not be a good plan given all the ways craft can be made. Perhaps if auto-deploy landing gear was a user-configurable option that might be OK. Even with the KSP2 bug solved, it might be nice to have an option to deploy landing gear prior to touchdown.

I've observed this as well, and I'm fairly sure it's not a part clipping problem - though that can cause it. I've seen it on a number of different craft. The consistent thing I've seen is that if you attempt to extend landing gear while you're in timewarp not only does it not work, but it can leave your landing gear in an odd state where they won't work outside of timewarp as well. You may notice that the "indicator light" for your landing gear goes to green in the game's UI (upper left part of the screen) even though the gear does not extend. For whatever reason gear can't extend in timewarp, but some part of the game doesn't seem to realize this, so the status indicator goes green as if they're extended. I suspect this is where the real issue is - and it's in the game. I suspect that what's going on is that when we tell K2D2 to Break, it will timewarp to the optimal time to begin the breaking maneuver and so if you haven't yet extended your landing gear you can get into the situation where the game won't let you. One possible way to solve this is to have K2D2 automatically extend landing gear when Break is activated before starting the timewarp. Also, the user can just extend their landing gear before hitting Break.

Thanks for the elaboration. This is helpful, and I've been able to confirm your observations. For Moho targeted from the pad, Next Window was monotonically increasing at a rate of about 0.5s per second of game time. In LKO it's also increasing at about the same rate. When I teleport that vessel to a low orbit around Kerbol (well inside Moho's orbit), then the time for the Next Window is counting down at about 1 s per second of game time. but when I teleport to an orbit that's between Moho and Eve it's counting up again. In the orbit between Moho and Eve, when targeting Eve, the time in Next Window is counting down as it should be. So, the effect we're observing is that if you're in an inferior orbit (lower than the orbit of your target) then the time counts down, and if you're in a superior orbit (higher than the orbit of your target) then the time counts up. I'm looking at the code now to see if I can work out why this is. UPDATE: I believe I've found and fixed the issue. I will need to release updated versions of both Flight Plan and Node Manager as part of the issue was there as well.

FP doesn't give you this option. The math may be fundamentally the same, but the UI simply doesn't give this option so you can't get this from it. The logic governing which tabs are available has to do with what sort of body you're orbiting and what sort of object (if any) you're targeting. The only way to get the Moon tab is to be orbiting a moon - and that tab only has one maneuver on it - Return from Moon. If you're at a planet and select one of its moons, then that tab (Target Relative Maneuvers: Celestial) will show you a Next Window. If you're at a planet and have another planet selected, then you can get to the Orbital Transfer Maneuvers: Planet tab and it too will display Next Window info. The time displayed for Next Window is being dynamically recalculated and updated. I've only ever seen it decrease, but then I've not been watching for this.

Yes, please do share. You can post them here on this thread - or if you lie you can post them here (the KSP2 Modding Society discord channel for MNC).