schlosrat

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.

Update to 0.8.11.3 Fixed an issue with handling of tabs and selected targets so that changing targets will have the correct effect on the visible tabs and selected maneuver buttons Fixed an issue where the porkchop plot could be called when it shouldn't be (which was spamming the log when that happened) GitHub: https://github.com/schlosrat/FlightPlan/releases/tag/0.8.11.3 SpaceDock: https://spacedock.info/mod/3359/Flight Plan

It is sincerely my pleasure! As a hobbyist mod maker, unfortunately, I don't have the time to QA things as much as I know I should - or perhaps I just don't have the patience and temperament. Getting feedback like this helps me immensely!

True, but the important point seemed to be that there can be an equation, and the issue of the variable naming convention seemed like a distraction from that point. I don't think the equation should be quite as simple as the one hypothesized, but that too is aside from the point. There will be some sort of equation, and it may not be a terribly difficult one if the heat generation/transfer/rejection mechanics are set up sensibly. By sensibly I mean with a reasonable balance between fidelity and gameplay so that the end result is interesting, fun, and sufficiently predictable that one can design with it in mind.

I like this idea! Imagine that with various tech unlocked the distance between modules might be extended (like a max distance property for colony parts perhaps, where more advanced or otherwise capable parts might be able to be located further away). Whether the distance was fixed to one value for all parts or varied "booster pump" stations could be built so that you could daisy chain your way from one part of the colony to another. This could be really useful for heat transfer applications. A solar farm up on a ridge or peak, and a radiator farm down in a canyon for shadow perhaps. I think such a mechanic, regardless of how it's implemented, could lead to some interesting colony designs and site selection challenges! On a related topic, such a mechanic might be useful also for resource transfer as well as heat transfer.

Microsoft for one: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions#naming-conventions

Thanks for calling that to my attention! This one was a simple fix (a minor typo), so there's a new version up now. You can get it 0.8.11.2 on SpaceDock or GitHub. CKAN will most likely pick it up soon, but if you're in a hurry to get your mission back on track then feel free to grab a copy at either of these locations: GitHub: https://github.com/schlosrat/FlightPlan/releases/tag/0.8.11.2 SpaceDock: https://spacedock.info/mod/3359/Flight Plan

Updated to v 0.5.8 Updated node creation logic to align better with how the game creates nodes a player makes manually in the map view. This streamlines the process, better integrates with the game's internal code, doesn't require the use of coroutines, and results in other mods getting the correct patch info for the maneuver resulting from the node.