schlosrat

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.

Updated to 0.9.8 Added the patch transition start and end info to the encounter info group. This makes it possible to quickly see the effect of node adjustments that might result in things like SOI escape, collision with a body, etc. without needing to be in map view. Updated dependency for Node Manager to require 0.5.8 which includes an improved node creation process enabling mods like MNC to have the correct encounter and transition info as soon as a node is created or modified without needing a hacky process of making a second unnecessary node. Updated the look of the UI to align with the game, K2-D2, and Flight Plan for colors and thicknesses of borders, etc. GitHub: https://github.com/schlosrat/ManeuverNodeController/releases/tag/0.9.8 SpaceDock: https://spacedock.info/mod/3270/Maneuver Node Controller Here's a sample to show the new look relative to K2-D2, FP, and the game's UI elements

FYI, Flight Plan and Node Manager both have significant amounts of actual MJ2 code (updated to work in KSP2). Node Manager is a library mod that delivers some of these features and capabilities for other mods (like Flight Plan and Maneuver Node Controller) to call. So, in this sense, there's real live actual MJ2 code available in KSP2 now. There is also a capability in FP for deploying payloads into resonant orbits, too. The primary modes (tabs) of Flight Plan are as follows Ownship Maneuvers - Always available. Things you might want to do that don't involve other vessels or transferring from one body to another. Target Relative Maneuvers: Vessel - Available when you're targeting a vessel or a part of a vessel, and that vessel is orbiting the same body you are. This is where you'll find the Rendezvous capability. You can use this tab to also select a vessel's ports to aid in docking. Target Relative Maneuvers: Celestial - Available when you've got a celestial body targeted and that body is orbiting the same body you're orbiting. Enables transfers to a moon, or to a planet if you're orbiting Kerbol. Orbital Transfer Maneuvers: Moon - Available when you're orbiting a moon and may want to get to the planet the moon is orbiting. Orbital Transfer Maneuvers: Planet - Available when you're targeting a planet that's not the one you're orbiting and may want to do a planetary transfer. Resonant Orbit Maneuvers: Always available, allows you to set up a resonant deployment orbit.

Another useful mod would Maneuver Node Controller. This also integrates with FP, and can be used to fine-tune the nodes that FP creates prior to having K2-D2 execute them. This can be useful when plotting a flight to a moon, and is almost certainly going to be necessary when using FP to set up an interplanetary transfer. The latest version of MNC (0.9.7) has the added new capability to display encounter info, though there's currently a minor hitch.

Here's a quick video to demo the new MNC 0.9.7 Encounter display capability. Note, that in this version of MNC, and using Node Manager 0.5.7, it's currently necessary to add a second empty (0 Delta V) node for the encounter information to be correctly displayed. I think this shouldn't be the case, and am working on finding a way to get this working without that hack. In the mean time, it's at least possible to get the correct info.

I’ve updated Maneuver Node Controller to 0.9.7. Added display of trajectory encounter info for previous and next orbits to aid in fine-tuning encounters Updated display of Ap and Pe for previous and next orbits so that these fields autoscale from m up to Gm to prevent very large orbits from overfilling their display space Changed display font to LibertationSans (a Linux variant of Arial that's free to distribute) for the main GUI. This allows a larger font size to be used with a crisper, cleaner font that's easier to read Changed the title font to Orbitron because it's way more futuristic and just plain cool (and also free to distribute!) Changed the borders around the UI and buttons to better match the stock game and other common mods like Flight Plan and K2-D2

Updated to 0.9.7 Added display of trajectory encounter info for previous and next orbits to aid in fine-tuning encounters Updated display of Ap and Pe for previous and next orbits so that these fields autoscale from m up to Gm to prevent very large orbits from overfilling their display space Changed display font to LibertationSans (a Linux variant of Arial that's free to distribute) for the main GUI. This allows a larger font size to be used with a crisper, cleaner font that's easier to read Changed the title font to Orbitron because it's way more futuristic and just plain cool (and also free to distribute!) Changed the borders around the UI and buttons to better match the stock game and other common mods like Flight Plan and K2-D2 GitHub: https://github.com/schlosrat/ManeuverNodeController/releases/tag/0.9.7 SpaceDock: https://spacedock.info/mod/3270/Maneuver Node Controller

Nice! Looking forward to it!

So glad to hear this isn't the case! Thanks for clarifying. If I misconstrued it, that was because @Clayelasked why you got rid of the upvotes, and then you replied that you still have them internally. and went on to give what appeared to be an argument for not having an upvote system. I took that to mean that you have the data for the upvotes internally, but that on the public-facing side, they were gone now. If that's not the case, then that's a good thing!

What are you saying Rocket? Nate's posts are high in fiber? ;-) Personally, I like the UpNates for getting a sense of the creative direction and glimpses of roadmap work, but I agree that the patch notes and the bug status are dense in information. The dev diaries are very interesting for real depth and insights into what's going on, too. It's all good, and all of these have an important place in communicating from IG to our player and modding communities. I think IG has been really improving on communication lately, and this new KERB reporting is a great example. I like how this aspect of our community is evolving, though I'm a bit concerned if we've lost the ability to upvote bug reports. I found that to be a very useful way to say "Me too!" without needing to write up a whole bug report post if the OP had captured it well already.

OK. 0.8.11.1 is hot off the press and available on SpaceDock. You can get it here too: https://github.com/schlosrat/FlightPlan/releases/tag/0.8.11.1 CKAN will have it soon as well, but that does take a little time for it to catch up. Things should work much better for interplanetary travel now!

I've found the error and have fixed it, but I need to clean up a couple of things. I'll have a fix out soon.

Updated to v 0.8.11 Released on 2023-07-14 Fixed issue where FlightPlan GUI would stay up when in Tracking Station, Training Center, KSC, or VAB. GUI no correctly takes itself down when in those scenes and will automatically come back up in FlightView, or Map3DView. Improved target selection and burn time option dropdown menus for readability. While selecting an option the hovered option is highlighted yellow. Celestial bodies are properly indented to show orbital relationships (moons are indented under planets) Restored stub functionality for Advanced Planetary Transfer. When experimental features are switched on, then the Advanced Planetary Transfer button is available. Porkchop plots are displayed properly, can be zoomed and panned, etc. NOTE: Make Node will not make an Advanced Planetary Transfer at this time - this is merely stub functionality that can be observed and played with prior to completing the full functionality. Aligned FP GUI with K2-D2 a bit better for a more common look and feel.

Thanks for reporting this issue! Since making that video I've done some updates to FP and the game is on a new version, so it's possible that something is not working correctly and you're doing everything just fine. I'll make a test where I attempt to fly to Eeloo and see what happens (though going to any planet will likely reveal it if there's a problem in FP). FYI: Essentially, what FP does to determine which tabs to show is it looks at your current situation, and especially what target you've got selected. You can't get TRM Ship2Ship if you've selected a celestial, and you can't get TRM Ship2Celestial if you've selected a vessel or a part of a vessel. You can't get either one if you don't have a target selected, and there are also some checks about what you're orbiting and what the target is orbiting. The idea is to only display tabs that make sense for your current situation, but I assume you set the target to Eeloo and just left it set that way so this shouldn't be a problem. With the change to v 0.8.9 of FP I changed the GUI code from IMGUI to UITK, and that necessarily meant touching the part that controls which tabs are visible at any time. Given this, it's at least possible that something didn't get converted correctly and FP is not showing a tab that it should be showing for some reason. I'll know that soon enough, and if so then this will likely be a quick fix. OTOH, if I get this to work I may be able to turn it into a new video, which might be helpful to you and others as well.

Yep, @Cable Guy nailed it. FP requires SpaceWarp, and SpaceWarp requires UITKForKsp2. If you install from CKAN it should automatically take care of these dependencies for you. if you’ve got SW 1.3 and UITKForKsp2 and it’s still not working then please ping me. You can get my attention quicker on the KSP2 Modding Society discord, but here works fine as well. I’ll update the manual install instructions to make this clearer and call out UITKForKsp2 specifically.

That is pretty much exactly what FP does in such cases. It calculates the required burn as an impulse, applies it at the Ap, Pe, AN, whatever you pick, then works out the time offset needed and applies a “correction “ so the vector direction of the burn stays the same with an earlier time of 1/2 the burn duration. It’s definitely not as simple and just moving the node earlier as the node uses prograde, radial, normal coordinates which will rotate in an inertial frame. Effectively it’s just giving you the secant, but it does this by grabbing the node’s burn vector and converting to an inertial frame, setting the node earlier, and then rotating the resulting vector to make it like back up.

The new approach is necessitated by the more accurate way KSP2 handles the orbital calculations. While it’s certainly possible to set up well timed periapsis kick maneuvers manually, you might want to take a look at Flight Plan. It will set them up for you so they start at the precise correct time to have the midpoint of the burn on the periapsis. You can still execute the node manually if you prefer, but FP can take the guesswork out of sizing and placing the node if you like.

Sorry I missed this, the ping didn't seem to go through. You can find typically that here: "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program 2" I think they use the AppData folder so that all your games can share the same campaigns and saves. So, suppose you wanted a modded game and another one that's clean. Since the campaigns are in the AppData structure these two games can share them. You can open your modded game, load the save, play, save again, close that game and open a clean install and carry on (unless you've got parts from mods - then you're presently quite doomed)

The more I think about it, the more the arguments that (a) KSP1 is where the players are, and (b) KSP1 is the game I'm personally playing seem to make a lot of sense (thinking here in the frame of a KSP1 modder). There's no arguing with either of those - facts are facts, whether we like 'em or not. As KPS2 develops, bugs are driven out, and features driven in, well, I think the player base will gradually migrate. I believe this is inevitable. I see two things from this. First, even if KSP1 modders are disinclined to jump in now and begin modding KSP2, there's a lot of collected wisdom and perspective in that camp that we (KSP2 modders) need to tap into. Hopefully, even if they're not yet interested in modding KSP2 they may nevertheless be willing to offer some of their hard-earned wisdom and perspective. We would be very wise to listen to them! Second, we may be able to very slightly hasten this process, or at least give it a boost once the player migration begins to take hold. If we (KSP2 modders) can pave the road with some good mods that help to fill gaps players know they'd miss if they were to leave KSP1, then as the bugs are driven out and features are driven in we may just succeed in helping this migration to take place. I think we're doing exactly that, and from what I've seen I think we're succeeding. Let's not neglect Point One above, but let's press on with Point Two. A corollary to point two would be we should also be listening to KSP1 modders to help make sure we're paving the road for them as well. Again, I think (or certainly hope) that we are. With a potentially viable Patch Manager in the works and with templates and API docs, etc., I think we'll not only make our own work easier but may also help pave the road for KSP1 modders to have an easier transition themselves once they're inclined to do so. We may not be able to motivate them to come over, but we can listen to them and learn and try to make things easier for everyone down the road.