#Flight Plan
1 messages · Page 2 of 1
and the only viable alternatives are paid
and I don't feel like paying for even more SpaceWarp stuff, I think it's enough that I'm paying for the domains lmao
(sorry for the unwarranted rant)
You're paying for the domains?
Could we set up some tiny little patreon thing to cover crap like that?
heh someone has to
I mean it's almost nothing, it was like around 30 € for 2 years I think
and I'm using a free Oracle Cloud account to host the wiki and the nuget server
it's really slow and really restrictive
but it's free
Free is good!
I wouldn't even mind paying a small subscription, but I'm not a fan of pay-as-you-go because I can never be sure that suddenly page visits won't spike, or even something like a DDoS, which could rack up the bill significantly
Damn, the world we live in...
it's probably avoidable but I'm no sysadmin and I don't really want to take that up 😄
Class extension question for you.
So, if I want to extend class foo I just write methods that take (this.foo) as the argument?
yeah
Good, cause I may need to extend Obriter. I can't for the life of me get it to produce a list of patched conics unless I add an actual node and I desperately need that list for the Advanced Planetary Transfers. The whole point of that is to zero in on the node you need before having to make it, and I think that whatever is happening when I make the node and eventually get the list, it's taking way to long.
I've been through MJ in a debug KSP1 and know what it's doing on the MJ side of the fence, but the KSP1 function it calls has no analog I've been able to find in KSP2
This goes counter to Got's argument that so much is the same - this part is not.
I'm going to wade into what it's doing when you do add a node that eventually gives a patch list, and so there's some hope I may yet stumble across an existing KSP2 solution...
he was talking mostly just about the physics, not the specific implementation details
but anyway that's beside the point right now
Well why wouldn't the physics be the same? Physics hasn't changed recently and they're both Unity
Anyway, I've been beating my head against the wall trying to get a patch list that KSP1 will happily generate at the drop of a bat for MJ. If I can't find an existing KSP2 solution to that, then I'll have to implement my own.
Not my idea of fun, really - but it is what it is, and right now it has me quite stumped
I'll be pushing the update to NM on GitHub momentarily. Things seem to work fine in both MNC and FP with this
NM 0.5.5 is released on SpaceDock and updated on the forum.
I'll push out new releases for MNC and FP once that's up.
Excellent! I'll fix my csproj for MNC and FP
you'll also want to delete the NM folder from your nuget cache, just to make sure you're now getting it from the nuget repo
since it will be cached in there from your local folder
Good point! Where is that again? In my user folder structure somewhere?
yeah, C:/Users/<username>/.nuget/packages
@grizzled vale , I've had this weird issue with my projects, which I've not updated to the latest template though I suspect that might help. I'm using some batch files that @tulip quarry added in with a post build that calls those. They do a fantastic job of putting files where I need them to be and getting a release zip all ready, but when I've got that in the post build event then I don't get a nuget package. If I sawp back to the old way I get the nuget package, but I don't get the rest of the stuff those batches do.
What is it that actually makes the nuget package happen? Maybe I can add that to my batches?
well that's weird
<GeneratePackageOnBuild>true</GeneratePackageOnBuild> is what makes the nuget package build automatically
but yes, the 1.2 template has custom post-build actions for zipping a Release, for Deploy to the game folder, and for DeployAndRun the game
I've got that line in my csproj, at least in NodeManager for sure. I should check FP too. It's good to know it's not something missing in my batches though.
What's the process for moving an existing project to the new template?
I just tested this again, and in Node Manager with <GeneratePackageOnBuild>true</GeneratePackageOnBuild> in my csproj and this for PostBuild I get a release zip but not a nuget package.
<Target Name="PostBuild" AfterTargets="PostBuildEvent">
<Exec Command="REM copy dll, pdb images infos ands readme to the Debug or Release Dir

ECHO off
SET DEST_DIR=$(ProjectDir)..\$(ConfigurationName)

if not exist "%25DEST_DIR%25" rmdir /s /q "%25DEST_DIR%25"
if not exist "%25DEST_DIR%25" mkdir "%25DEST_DIR%25"

echo d | xcopy /y /s "$(ProjectDir)..\$(ModId)\" "%25DEST_DIR%25\BepInEx\plugins\$(ModId)\"
echo f | xcopy /y "$(TargetPath)" "%25DEST_DIR%25\BepInEx\plugins\$(ModId)\$(ModId).dll"
if $(ConfigurationName) == Debug echo f | xcopy /y "$(TargetDir)$(TargetName).pdb" "%25DEST_DIR%25\BepInEx\plugins\$(ModId)\$(ModId).pdb"
xcopy /y "$(ProjectDir)..\LICENSE.md" "%25DEST_DIR%25\BepInEx\plugins\$(ModId)\"
echo f | xcopy /y "$(ProjectDir)..\README.md" "%25DEST_DIR%25\BepInEx\plugins\$(ModId)\README.txt"

cd $(ProjectDir)..\batches
call post_build.bat $(ConfigurationName) $(ModId)" />
</Target>```
When I swap that out for this then I do get a nuget package, but I don't get a release zip
Looking forward to your porkchop update
Me too, but we both may be waiting a while. Although I've had success making the porkchop plot, the part of the process that comes after that is failing due to the fact that KSP1 did things very differently than KSP2 does. The MechJeb process takes information about the point you click on (the departure time and delta-v), and then calls functions that KSP1 provided to generate patched conic orbits so it can (a) see when and how well you're encountering the target, and then (b) optimize the ejection burn to give you a good encounter. I can get the same point info from the plot that MechJeb gets, but that's about it, and that's only the start of the process.
This might be possible in KSP2, but so far I've had no luck using the KSP2 methods for making a patch list. I can run MechJeb in a debug build of KSP1 and single step through the code to see exactly what it's doing, but unfortunately the magic is happening inside a KSP1 method that doesn't exist in KSP2. The nearest equivalent KSP2 methods I've found do return a patch list, but they never include a patch with an encounter and all I get are the patch in the SOI of the origin planet, and then a single patch in the Kerbol SOI that appears to not even encounter the target. In KSP1 you get those two patches along with another for the target encounter.
Perhaps adding just the first node could be a excellent first step.
I tried that, actually. There area apparently differences in how KSP2 does its ManeuverPlanSolver such that adding the first node only get's you two patches. The first patch is the ejection from the current SOI, and the second patch is in orbit around Kerbin without an encounter of the target. My hope is that this relates to the SOI transition bug and that when they fix that then the second patch will get an encounter and the problem becomes solvable.
Ok, We should wait for next update then... Damit

@grizzled vale I'm about to embark on migrating FP to UITK. I think I know how generally based on what I've learned with @foggy vortex helping me with MNC. That said, I've got a problem in MNC' s UITK adaptation that will surly be a problem with FP too.
IF you have a little time and can help get me unstuck with style sheets that would really help both of these projects
In general its the non-WYSIWYG nature of things in Unity.
I can make the UI look the way I want there, including text fields and buttons, but I'm having issues getting that to be the case in the game.
I think I sorted out the buttons part without needing to resort to setting margin and padding on the lowest level element, but now I've got a problem with the text fields again.
I think that that might be a problem on how munix implemented the documents? Or how the KerbalUI is written and its overwritting your style
@grizzled vale
Basically the textfield input margins that he writes in his css are being overwritten with kerbalUIs
Thats w/o u setting the margins manually right?
the good news here is that I've got the buttons set using styles and without resorting to hard coding the margin and padding on each button
Yep, and here it is in Unity Editor
The font looks different, both colors and "thickness"
Yeah munix can help u a lot more w this since he’s more known of the css arts
The text fields are very different
I may like the new brighter look for the fonts in the UITK version of my GUI, but I'd like them to appear "crisper", and the changes I've tried making in the Unity Editor are not seeming to have any visible impact. Even if I do like things a little brighter, I'd also like to be able to control it effectively, which I can't seem to do rn
so what exactly did you do with the font?
I tried setting the Font and Font Asset
Font itself doesn't seem to work, but making a dynamic TextCore FontAsset and assigning that should work
I've got some that seem to have come with the "template"
I just now tried changing the font asset to RobotoMono-Italic and all the text inside the text fields disappeared
Here's another test with a different font asset Arial SDF
And here it is unset
are the font assets properly getting bundled?
Probably not, but this is in the unity editor, not in the game
Do I need to do something in order to be able to use those fonts?
This is a clue maybe?
not really, those are just the custom fonts I use
you're trying to use built-in ones
I'm also trying to learn in general how do I manipulate the font. I'd like to control things so I can see the effect in Unity and know that's what I'll get in the game.
So far I get to use the default or I don't get anything.
all I can tell you is you need the TextCore asset somewhere in your Assets folder (so that you can actually reference it) and then just set the -unity-font-definition to it
like in KerbalUI.uss:
(the things starting with -- are just custom properties/variables, which are referenced using the var(...) syntax)
but regularly you can just write something like -unity-font-definition: url('/Assets/Theme/Fonts/JetBrainsMono/JetBrainsMono-Regular SDF.asset');
this is pretty much as far as I've gone working with UITK fonts
oh and you create FontAssets from regular font files such as .ttf like this:
(after right-clicking on the font file)
So, I need to edit my FlightPlanTheme.uss file to have it point to the right thing?
like this?
well the visual editor probably does the same thing
haven't really tried editing USS that way so I'm not sure
I'd say the most important thing is to make sure your font assets are actually in your Assets
I have no clue how using a built-in font would work
OK, I think this is enough to help we set the font the way I like. What you've described makes sense, and I'd like to take a shot at that.
The other thing though was the weird effect ont he text input fields - how they're getting smooshed down in the game
This
Left is UITK GUI, and right is IMGUI (both are still present in MNC atm)
no clue what that could be, can you send me your uss?
Sure.
That's what's in MNC rn and giving me the smooshed fields shown above
There's the uxml if that's also helpful
interesting, this is how it shows up for me in the UI Builder
Well, that's a lot closer to what I get in game... Not the same, but a lot closer
when I increase the size of the preview window
My window is 350 x 650
that's exactly what I used
And it looks pretty much just like what I'm getting in game - may be spot on
here's the window when previewing without KerbalUI vs. with it
I think there's your issue
So, KerbalUI is messing with things in game, and I'm not seeing it in Unity because I'm not using that, so what can I do? Apply KerbalUI in Unity and modify something after that?
yeah, basically you're basing your style on a theme that the game isn't using
Ah ha!
So, I just needed to add KerbalUI to the end of my styles to see what I'd get in the game
not really
you just need to toggle the preview theme
like I showed in the screenshots above
having KerbalUI applied before and after your styles might mess something up
Ahh! Got it
So, now I'm WYSIWYG, this is good
But what can I do to get this looking as I'd like it?
as for the font, you can either try out the non-bold variant of JetBrains Mono, or just download some open-source/royalty-free font of your choice and use that instead
Better
And I now get what I need to do to really go places with the font
But what about the smooshed nature of the text input field?
well you just need to play around with the heights/margins/paddings
to get them to look like you want
OK, having this WYSIWYG will certainly make a big difference with that. Thanks!
for me just setting the padding to 0 on .unity-text-field made all the difference
Yep, that did it!
when an element has a set height, increasing the padding will make the content smaller
Oh that's a handy chart! This definitely helps me understand better which knobs to turn when I want an effect
Nice!
I'm gonna go play with this and see if I can't get MNC looking just the way I want it to in UITK now. I think I can!
css is my passion ❤️
Once I get that down I'll start ripping out the IMGUI remnants to complete that transition
I'm really glad it is. Somebody needs to love it!
@grizzled vale icon image asset question. I'm using this for my close button, but I'd like the gray background behind it to be a bit larger
Like this
When I try to fix this with border I end up with something like this
looks to me like you want a padding on the element?
OK I'll play with that
I'm getting this, which doesn't seem to be respecting the border
Setting the padding isn't helping, anything more than 0 makes it worse
I've tried different scale modes and those don't seem to affect it
Slice does bad things
Here's slice 4
@grizzled vale it seems like unity is just not respecting my desire to scale the texture. The boarder is doing what I'd like it to, but unity is allowing the texture to spill over the boarder.
Thanks!
Other than that, I think the new UI is looking great.
The functionality in the new UI seems to all be good, so I'm going to start ripping out the old IMGUI code.
I've faked it out by adding another visual element to contain the button and giving that element the boarder and radius I want
I was going to suggest the opposite, putting a visual element inside the button and setting the image as the background of the inner element
that way you still retain any :hover/:active styles on the button etc
not the same image, but it works as it should
at least this way you can click on the outside border and still get the actual button press to register
Things are workiong well, but I am getting a click through effect I was hoping would not be present in UITK. Here I've placed the MNC gui so that one of it's text inputs is over the Cheat Menu icon. Is this the expected behavior?
yes, there's no built-in click-through blocking in any of the UI libraries
which is why KSP 1 modders had to build one for themselves
I do have an experimental version of one, but it's very limited - currently only blocks click-through on the game's UI controls when clicking on a UITK or IMGUI window
it doesn't handle interactions between 2 UITK windows, 2 IMGUI windows, or between a UITK and an IMGUI window
OK, I'll install that. Thanks!
use the multiplication unicode char
either of these
looks great and almost all font packs have them setup to be ideal for close buttons
@grizzled vale , @foggy vortex OK, I'm ready to start ripping out the old IMGUI code. I assume I still need OnInitilized since it's got the code that brings up the new UITK gui and creates the app bar button, but I won't need some things it was doing that relate to the old IMGUI code. I think I don't need anything in Awake though. What's there now is just this
void Awake()
{
windowRect = new Rect((Screen.width * 0.7f) - (windowWidth / 2), (Screen.height / 2) - (windowHeight / 2), 0, 0);
}```
Do I still need OnGUI? I assume so, though I'm not sure.
Looks like I may need some things out of OnGUi and presumably in Update. Commenting out the whole thing gave me NREs for some things that are set there.
@grizzled vale , for swinfo.json do I just need to add this for dependency?
{
"id": "UitkForKsp2",
"version": {
"min": "1.2.0",
"max": "*"
}
}```
yeah
Nothing corresponding to <PackageReference Include="UnityEngine.UITK" Version="2020.3.33.1"/>, right?
nope, that's imported into the game by UitkForKsp2
Cool. Thanks!
also should add a BepInDependency attribute in your plugin class
similarly to the one for SpaceWarp
(though that dependency is kinda redundant because SpaceWarp depends on UitkForKsp2 anyway, but it's good to list all plugins you directly depend on explicitly, anyway)
What version of BepInEx?
what do you mean?
[BepInDependency(UitkForKsp2Plugin.ModGuid, UitkForKsp2Plugin.ModVer)]
{
"id": "BepInEx",
"version": {
"min": "1.2.0",
"max": "*"
}
},```
Oh you mean there!
OK, my swinfo.json dependencies are these
"dependencies": [
{
"id": "SpaceWarp",
"version": {
"min": "1.2.0",
"max": "*"
}
},
{
"id": "UitkForKsp2",
"version": {
"min": "1.2.0",
"max": "*"
}
},
{
"id": "NodeManager",
"version": {
"min": "0.5.5",
"max": "*"
}
}
],```
Why is the new one white and not green like the others?
Nope...
well did you import the namespace in the class?
Nope, should I have?
I mean, you can't use any class without first using its namespace
weird that it didn't show some squiggly line or something
I'm having an odd issue where when I close using the close button, the app bar button stays highlighted on and I have to hit it twice (turn off, then back on) to get the app back up that way. My close button calls my old GUI's ToggleButton method, which in turn calls SetEnabled in the MncUiController
public void ToggleButton(bool toggle)
{
interfaceEnabled = toggle;
GameObject.Find(ToolbarFlightButtonID)?.GetComponent<UIValue_WriteBool_Toggle>()?.SetValue(interfaceEnabled);
controller.SetEnabled(toggle);
}```
```cs
public void SetEnabled(bool newState)
{
if (newState) _container.style.display = DisplayStyle.Flex;
else _container.style.display = DisplayStyle.None;
}```
and there's this in InitializeElements
```cs
_container.Q<Button>("CloseButton").clicked += () => ManeuverNodeControllerMod.Instance.ToggleButton(false);
Hitting the close button does bring down the GUI, so I know SetEnabled is being called correctly, and I don't think I've changed anything with ToggleButton other than to add the call to SetEnabled
I tried changing ToolbarFlightButtonID to (it was public const string)
public static string ToolbarFlightButtonID = "BTN-ManeuverNodeControllerFlight";```
and adding this to SetEnabled
```cs
public void SetEnabled(bool newState)
{
if (newState) _container.style.display = DisplayStyle.Flex;
else _container.style.display = DisplayStyle.None;
GameObject.Find(ManeuverNodeControllerMod.ToolbarFlightButtonID)?.GetComponent<UIValue_WriteBool_Toggle>()?.SetValue(newState);
}```
but that didn't help - same results. I can bring the app up fine with the hot key using this code
```cs
void Update()
{
if (Input.GetKey(KeyCode.LeftAlt) && Input.GetKeyDown(KeyCode.N))
{
ToggleButton(!interfaceEnabled);
Logger.LogInfo("Update: UI toggled with hotkey");
}
// Stuff from OnGUI that we still need to do at least once each frame
GUIenabled = false;
var gameState = Game?.GlobalGameState?.GetState();
if (gameState == GameState.Map3DView) GUIenabled = true;
if (gameState == GameState.FlightView) GUIenabled = true;
MNCUtility.RefreshActiveVesselAndCurrentManeuver();
currentTarget = MNCUtility.activeVessel?.TargetObject;
}```
No clue why that would happen, calling the exact same thing works just fine for me
but if you want to know where it's going wrong, you need to debug the successive calls separately
something like this
var button = GameObject.Find(ManeuverNodeControllerMod.ToolbarFlightButtonID);
Logger.LogInfo(button == null ? "didn't find button" : "button found");
var component = button?.GetComponent<UIValue_WriteBool_Toggle>()
Logger.LogInfo(component == null ? "didn't find component" : "component found");
component?.SetValue(interfaceEnabled);
Logger.LogInfo($"Component value: {component?.GetValue()}");
@foggy vortex I want to make my button gobble up all the horizontal space it's able to, but it won't let me. Before Unity game me the big FU this morning I had that working, but I'll be damned if I can replicate whatever I was doing before. My hierarchy and styles are like this
I set the icon h and w in #LargeIcon, and that works. I set the row, button box, and button with the styles I've got set up. I know that when I had a solution for this before I could switch between what I've got now and auto-max width buttons by just changing Grow to 1 instead of 0.
The row is defined like this
The button box is defined like this
should be easy
And the button is defined like this
For the button?
also put your row as Witdh 100%
yes
That was it! width needed to be 100%
tbf it wasnt suposed to be just that xD
basically you'd need the row width to be 100%
and the buttons too
but set them to Shrink and Grow
basically that would say "Row, ocuppy all the widht of the window"
"Buttons, fight for the space inside the row", since hte buttons are allowed to both grow and shrink they'd come to a "status-quo" state
you migh need to make it so that all buttons under the row have 100% width tho
Setting row to 100% had a bad effect. It respected the left margin but ran over the right
Here's row width set to auto
And here it is set to 100%
Here it is with 5 icons, which maxes it out - it's not possible to have more than 4 available at any time as they're situational
huh well then if it works keep as it was xD
How do you set up a fold out menu?
drop visual elements inside the foldout
tho what u want there is a dropdown
not a foldout i think
Oh? Can it be variable length for the number of items and be reconfigured in game?
download this if u want to use the dropdowns
they are hidden
or i might be mistaken
doesnt that show a list of the celestial bodies?
That one will, but (a) someday we'll visit other systems, and (b) I need to also use this interface for selecting non-celestial targets (ships and docking ports)
The button to the left will toggle between populating it with celestials vs ships
OK, I think that works well for celestials where they would be ordered by planet, then alphabetically by moon
It could work the same for vessels and docing ports
Then you just toggle if you want to see celestials or vessels
But how do I put in a tree view?
I've got the latest UITK for KSP2
i need to make one control for that 😭
it is on 2023 but not 2020
for you to make it work with a foldout will not be easy tbh
i think its better to just use the dropdown for now
I don't see that on the list of things I can add in the library. How do I get that?
OK, I downloaded that file. When you say put it anywhere do you mean it just needs to be in my vs project? Wouldn't it need to be in Unity some how?
Yay!
How do you populae a list of things into that?
Figured it out. Comma separated list in Choices
also, just saying, it won't work unless you use UitkForKsp2 1.3 which isn't released yet
(in-game I mean)
I'm working on getting it out today though
Well then, ppl will just have to suffer with the current version of FP for a while longer, now won't they?
😉
yeah, just wanted to let you know if you try to test it in the game and it shows an error
that's why
Good to know.
Also, why did my down arrow thingy vanish?
It vanished before I populated choices
Maybe when I set the label?
no clue honestly
these controls are probably experimental, which is why they don't show up in the Builder by default
so they may have bugs like that
This is perfect! It doesn't mess with the rest of the GUI!
Is there, or could there be, a way to tab indent some options?
This works...
It does not like /t tab characters...
by the way, the actual popup when clicking on the dropdown won't look like that in the game
this is what it looks like when you play the scene
it takes on the styles from KerbalUI as well
the Builder preview just doesn't show it like that for some reason
Does the dropdown float over the other visual elements below it or would it push them out of the way to make room? If the latter I might want turn the elements below it off when activating the dropdown
it does float, otherwise it would just be a foldout
internally it's using a PopupTextWindow or whatever the name of the element was
Excellent! That works for me
Making progress toward tabs!
The buttons to activate tabs will be situationally made available in the TabBar, and selecting one of them will have a radio-button-like effect of making all panel elements be set to Display = None except the selected tab's corresponding panel which will be Display = Flex
so many good work here !!! congratt. UITK seems really good. I'm strugling with good old unity IMGUI. UITK seems to be quite easier.
how does this work? from what I can see it can get to places automatically but Im not a coder and don't understand much, is there a guide/video?
@fierce estuary There is a guide, of course - and several videos too. You can find information about it on Space Dock (https://spacedock.info/mod/3359/Flight Plan), on GitHub (https://github.com/schlosrat/FlightPlan), and of course on the KSP2 Forum thread(https://forum.kerbalspaceprogram.com/topic/216393-flight-plan/). Essentially what you do with Flight Plan is to set up maneuver nodes. You can execute those by hand, or you can have K2-D2 execute them for you (assuming you've got the mod installed). Flight Plan is also compatible with Maneuver Node Controller which you can use to fine tune your nodes.
0.8.8 for KSP2 0.1.2.0 | Download: 1007.48 KiB | Released on: 2023-05-23
Plan your (Space) Flight, Fly Your Plan! Handy tools to help you set up maneuver nodes to get you where you want to be. Making spaceflight planning easier for KSP2 one mission at a time.
Flight Plan Plan your (Space) Flight! Fly your Plan! Handy tools to help you set up maneuver nodes that will get you where you want to be. Making spaceflight planning easier for Kerbal Space Program 2 one mission at a time. NOTE: This mod draws heavily on some core MechJeb2 code that has been ada...
Here is the problem that poor Valentina now finds herself in... What ever may she do?
As you can see, her circularization burn is composed entirely of Prograde since it was planned to be at the next Ap. That makes sense! However, FP has backed her node off from the Ap as nodes should be centered on the point you want them applied, also sensible. But look! Given the arc of her trajectory and the long duration of the burn (52 seconds), this means she's not pointing her craft in more-or-less the same direction as what Prograde would mean when she get's to the Ap if she didn't start her burn early.
If she accepted the craptacular situation FP has presented to her, then instead of a nice circular orbit she would get an new Ap of 286km, followed by first some hard aerobreaking, and then some very hard lithobreaking. Not good!
If she delays her purely prograde burn to start at Ap, then that improves things, but not very much...
Her new orbit will surely decay and likely not even be an orbit as this has her dipping all the way into a Pe of 48km. Essentially, she'd over corrected by putting the start of her node at the Ap. Let's see what she can gets if she pulls this node back a few seconds... How about just 6?
Viola! The node now starts about 6 seconds prior to Ap and results in a modestly circular 80 x 93 km orbit.
Well... Not so much viola... That was Val having to poke and prod this beast to get what she wanted, and even then it wasn't quite what she wanted...
All kidding aside, I think what I'm going to need to do here is significantly tweak my burn time offset approach. Maybe something like this...
- Start with the node at the zero time (at Ap in this case)
- Get the world vector corresponding to the burn vector (in this case it's just the prograde vector at the time of Ap)
- Back off the node time so the node is bracketing the zero point
- Get the new burn vector as a world vector (in this case, the direction of prograde at this new time)
- Rotate the new burn vector so that it aligns with the old vector
- Profit!... Er... Burn, baby! Burn!
God, I wish it was as simple as just backing off the time for the node...
@lucid wing The missing orbital stuff and the rocket deleting itself... I think those may be bugs in FP and not something the devs have done. Were you using the FP target selection feature? I know I recently found and squashed a bug in that where if you were trying to select other vessels (like for a rendezvous) it would do some weird things and delete vessels. It also played havoc with the orbits. I began noticing this in 0.1.3.1, but it may have been there longer.
The good news there is that the new version of FP that I've got cooking now doesn't do those things. I was going to hold off pushing it out as a few other things are still in work, but if it's causing rockets to go missing then I'd better put what I've got out sooner rather than later.
This new version (shown in the screen shots above) is mostly about a UI overhaul, but there are some other bug fixes that go into it too. The look and feel should be similar, though slightly different that what you've been using.
looks good and thanks!
OK, I've pushed out 0.8.9. Please take it for a spin to see if that solves the disapearing ships and orbits bug
This fix will not help poor Valentina in the scenario above. That will take more effort on my part, but I'd sure like to know if this new version works OK otherwise.
@grizzled vale , FYI - the latest version of FP is now a UITK mod. Thought you might want to know!
it looks great!
regarding this whole thing, I think it's caused by what I already briefly mentioned in #🔴mod-dev today
unlike KSP 1, which treated maneuvers as instantaneous impulses, KSP 2 integrates the burn over its duration
so the MJ code just won't work the same way
and will need to be custom-written for KSP 2's new system
(I think)
That's completely true. You're spot on here, but I've know this for months now. The odd thing is that only just now do I see how badly my previous simple attempt was doing.
Previously I thought I'd cleverly solve it by just backing off the node start time. What I see now, in this case, is that's oversimplistic simply because the node is defined in local instantaneous coordinates of Prograde, Normal, and Radial. Moving such a vector a short distance in time may not be perfect but is close enough to seem ok. Moving a bigger vector like this one where the trajectory arc is changing direction more rapidly... Now that drives home the problem!
Thus my hunch to put the vector into world coordinates prior to relocating it in time, then transform it back into the local burn vector coordinate system.
@wind mica The new UI Looks very bulky and out of place this time. The bezels are too thick and the icons got lower resolution now. For me some parts are shaped bad.
i really like the minimalistic look like k2d has done
this means that MND would also need to adjust its UI
later when every mod becomes a Mechjeb collection this would be kinda odd when every window looks a bit not like it belongs there
https://www.youtube.com/watch?v=Ter1C3tCsuA
also check out this BUG that just happened to me
Well fortunately, making changes to the look of the UI is easy and doens't even impact the code. Now that I'm using UITK it's possible to fix things like that in the Unity editor, build a new asset bundle, and then just recompile. The only time code changes is if I'm changing the name of something in the UI or adding/deleting things. Changing their appearance is actually quite easy.
I believe @tulip quarry plans to one day migrate K2-D2 to use UITK. When that happens it should be easy to get all these mods on the same page. We can share style sheets for that matter.
For my part, I can try to update MNC and FP to be more like K2-D2 is today - but that's making a UITK thing look like an IMGUI thing. Not hard, just that it may be a bit of a moving target. I'd prefer to coordinated on the coordinated look and feel with cfloutier involved. He's a genius at making things look and work really smooth.
yeah awesome, Get in touch with him and get it done. Would really easy up the menus on the yes. Maybe in the future even add a UI Scale slider for windows. And global text size.
That's why I pinged him in the post above! He'll notice and get around to this thread in due time. We can ponder the path forward, but of course the good news is that it should be fairly easy to update the UITK GUIs, and once he's gotten traction with his own update to UITK then I suspect coordination will flow more easily. He's contributed a lot to FP in the past and he and I are both invested in collaborating on these things.
So, that bug... Some sort of weird runaway burn?
What happened there? What led up to it?
Looks like you were working on a Hohmann transfer somewhere?
well i just did everything as planed and when it told me to do the maneuver it just messed it up.
yeah the transfer broke
Did it burn in the right direction, but just burned too long?
it got lost somehow on what to do and didnt stop the burn and kept burning
too long and then in the wrong direction
and you gotta love more bugs lmao this game.....
So it accomplished the burn then kept going, but not in the same direction and instead in some other direction?
yeah
Curious... I've not seen that one. Off hand it sounds like a K2-D2 bug, but it's been a long time since we've seen one like that. Back when K2-D2 was still early in development there were some points in its development where it might burn too long, but never that I recall where it would both overshoot and then also point in the wrong direction - more like just missing its mark to stop and so it keeps burning in the same direction. But as I said, it's been a long time since we've seen anything like that, so it's surprising. Cfloutier did recently release a 0.9.3, so maybe something unfortunate snuck in then?
Can you reproduce it? That's probably the most important thing. We will need to be able to reproduce it to be able to dig down to the root cause and fix it.
ill try
1px less
I think Valentina may be saved! She's comming up on an Ap of 94.294, and FP has generated a node that will put her in a 96.565 x 89.488 km orbit (e = 0.005)
also is this even possible? it couldnt find a solution for the maneuver.
Apparently it's possible. You just posted proof!
That's because FP thinks the solution is not possible. It either rejected the node it made or came back with an error when trying to make it - ergo no node, and thus no K2-D2 button and nothing to execute.
Note that the two vessels have barely 1/2 degree of difference between their planes. I would not waste time or gas on making a plane change when things are so close.
But the error is interesting. I can look into that.
i mean it should still try to find a solution.
It did try.
cuz now idk if i should do new ap or some other maneuver
Make node always tries, and in this case it came back saying the solution was not found.
OH HELLO THERE ORBIT
It's advising you to do a course correction, not a match planes.
What's up with the big burn to go to some crazy Ap? How did that get there and why isn't there a KSP2 BURN.TIMER on your screen if there's a red burn line and a gold new orbit line?
You should see something like this on your screen
Not that exactly, of course. But something like it
idk how to explain i feel like i got the extra broken version of the game or the mods just broke everything else
😅
Updated to 0.8.10 with the fix for CreateManeuverNode. This update should reliably back off the node time with a correct rotation of the node vector for the time offset so that the end result orbit form the node is much closer to the desired orbit.
Released on SpaceDock, and posted to the forum. CKAN may have it shortly if it doesn't already.
If everything is too big for you, in Settings UITK has an option to adjust global scale, so you can play around with it. Though note that everything made in UITK will scale together by changing that
Could this parameter be included in "I Wish They Made UI Customizable" (and BTW, enroll the mod on CKAN too)?
I mean it's already part of the "UITK for KSP2" which is a dependency for Space Warp and for other mods using new UITK, so no real point integrating it elsewhere. You go to Settings -> Mods -> UITKFORKSP2 -> adjust manual UI Scale.
One other thing that would make sense is UI scaling per mod. Maybe something @grizzled vale could think about 🙂
As for CKAN question, I requested it to be added to CKAN a month and a half ago, but for some reason guys from CKAN aren't doing any new additions for KSP2, don't know why. We're trying to reach them about them, but no luck so far
Yes, I already found the flag+parameter as the automatic scaling doesn't provide satisfying results on my screen resolution; Didn't you ping HebaruSan on CKAN discord directly? He's always very responsive
A couple of us posted on their discord without any response. I didn't want to ping HebaruSan dirrectly as he mentioning going on vacation, but @wind mica mentioned he pinged him dirrectly. Did he respond @wind mica ?
There's no way I can easily do that without giving each mod its separate PanelSettings, which is a very bad idea performance-wise
I figured as such.
Either the mods have to implement their own scaling strategy or I could try to make some sort of an API for it, but it would be pretty complicated to do generally to support all mods
I'd have to recursively go through every UI element of every mod and "manually" change the size, and also somehow do that whenever a new element is added to the hierarchy dynamically
Yikes, then no.
I pinged him yesterday on the SpaceDock forum and have not heard back. In the past he's been quick to respond. The last post I see from him on the SpaceDock general forum is from 6/27 - so more than a week ago.
I did get an email yesterday from the NetKAN GitHub about him trying to merge it but the action failed because the version_check in Lazy Orbit Boosted swinfo.json is incorrect
Thanks! I'll take a look and get that sorted.
You have https://raw.githubusercontent.com/schlosrat/LazyOrbit/master/lazy_orbit/swinfo.json but it needs to be https://raw.githubusercontent.com/schlosrat/LazyOrbit/master/LazyOrbit/swinfo.json
Ahhh yes, the old name! So easy to miss... So easy to fix!
Lazy Orbit Bosted has been... boosted! to 0.5.3 with a new and improved version_check. Hopefully that will enable it to be picked up by CKAN. Thanks for the tip!
thanks to make it back. really useful for modding
@wind mica I am having a bit of difficulty with Flight Plan when returning from Eeloo to Kerbin. Specifically, both the transfer window AND the calculated burn are incorrect. I've got a screenshot below that you can look at.z
For starters, the Transfer Window mod shows that I'm at the appropriate phase angle to transfer, but Flight Plan says the next window is 1 year 26 days and change away. You will also see in the screenshot that the burn does NOT include an SOI change from Kerbol to Kerbin, which means I have to adjust either the ejection burn OR I have to do a mid-course correction burn.
I have the latest version of everything, having updated it through cKAN once I got the latest SOI hotfix. Is there something I'm missing here?
You're not missing anything Scarecrow. The issue seems to be that what I've got in FP now is a port of the MJ2 Transfer to another Planet capability. I've noticed the same thing, both for getting to other planets and for getting back. If you fire up KSP1 with the latest MJ2 as your only mod and then attempt to use the MJ2 Transfer to another Planet capability you'll see that it, too, often gives very poor results. What most people are accustomed to is not using TtaP, but instead using the Advanced Transfer to another Planet and selecting from a porkchop plot. Those results are generally quite good, or at the least acceptable.
My operating theory is that MJ2 has either not seen much work on the TtaP capability (presumably since it's got a nicely working and easily superior Advanced transfer option), or the work that has been done on that simply hasn't met with much success. In any case MJ2 also gives very poor results with TtaP, generally no intercept, and invariably the maneuver it gives keeps you in the plane of the body you're currently orbiting - so transfers to/from Jool may be mostly OK, but getting to Dres or Eeloo where there's a significant difference in relative inclination of planes is just not gonna happen without a significant course correction (if you take the solution that TtaP gives you).
Since what I've got in FP is a clone of TtaP, we get similarly poor results. I've begin the work of porting ATtaP, and so far the visual and UI part works great! I can make a spiffy porkchop plot, you can pick the lowest Delta V or ASAP. You can pan and zoom the plot. You can tell it to include the capture burn or not - all the UI stuff you'd see in MJ2. Beyond that, it does not work at all, and this appears to come down to fundamental differences in how KSP1 and KSP2 handle orbital predictions. I would dearly love to solve that problem! So far, though, I've met with zero success. I'm not done working on it, but I also don't have any end in sight.
FYI, the Transfer Window mod you've got looks like the old one ABritInSpace made. As he isn't actively maintaining or developing that, I absorbed his code and functionality into FP. If there are differences then we can explore why they're there pretty easily.
OK, so there's been something of a breakthrough on this... maybe...
The thing is, I've tried all sorts of things and I can't get KSP2 to show me when I've got an encounter on a patch - even when I know full well there is one.
And if I can't get it to tell me if or when there's an encounter, then I can't optimize such an encounter.
So then I stumbled onto this...
This is... goofy. This is... weird. This... may mean that there's something I'm not doing correctly when I make a new node.
The crazy thing is, MNC and FP both just call Node Manager to make nodes.
MNC can modify nodes directly, but it doesn't create (or delete) them directly - it calls NM, just like FP does.
So... I can make a perfectly good Hohmann transfer from Kerbin to Mun. Granted, it was initially a suicide mission with lithobreaking at Mun, but even just one small nudge in MNC can change that.
But notice that editing the node did not change the info on the encounter. However, adding one lousy stinking empty node after the hohmann transfer node does!
If I could get KSP to give me that info straight off, I could toss the prospective advanced planetary transfer node on the map and then just optimize it by making edits, and forcing or letting it update.
Not quite how MJ does it, but who cares? If it could give you some kind of optimized node at the end would you care that it got there by figuring it all out in advance and making one nice pretty node, or by plasing an aproximate node on the map and itteratively editing it until it gives you the results you want? Who would care either way? End result would be an optimized node!
Now here's also an interesting thing... Try placing one empty node first, then construct the Hohman transfer! Sounds like, fun right? Guess what we get! Or just play this video and see for yourself
Weird, huh? Two node for the price of one! But we only asked for one? This is most likely a bug of some kind in how FP creates it's node or how NM manages nodes, or both. It really shouldn't do this. It should, at most, add one stinking node, not two, and certainly not make a new one and change another one after it like this.
That ui rework you did is fantastic
UI Toolkit
On the Kerbal French Program discord server (https://discord.gg/CdjEgthNrA), you may find references on a very interesting document describing the various orbital math elements as used in KSP#1 (more formulas than french speaking, so that should not be too hard).
I call it the planetary defense grid, and I'm shipping a free one with every purchase of Flight Plan.
Notice how it very carefully does not intersect with the atmosphere? That's by design! No atmospheric attenuation for this space laser!
does this hurt the solar bears?
- PETA activist
Curiously no. In fact we accomplish this by strategically locating solar bears in the planetary defense grid. Their shiny silvery fur coats are near perfect reflectors, and so they serve in place of much more costly mirrors to bounce the space laser's rays around the planet.
i've met this once. it's like if the step for each orbit line drawing was very long....
I've tracked down what was giving me funcky porkchop plots in Flight Plan! This is a big step forward, though not done with gfixing Advanced Interplanetary Transfer by any means. Here's what you get from KPS1 at the start of the Epoch using MJ2
And here's what you now get from Flight Plan
@grizzled vale , check it out! You were right - my porkchop plots were funny looking! They are substantially less funny looking now. Still room to go, but this is progress!
That looks great!
If you look closely you'll see the minimum delta V seems a bit funky in some cases.. Also, the nodes I'm getting from this mode are absolute crap now - they make what I had before seem almost acceptable, but the good news is I've run to ground a major problem and that same issue is probably in a few other places. Once I've rooted it out more thoroughly I may actually be able to get a decent advanced transfer node!
Also, the target periapsis doesn't track quite right. I think MJ is trying to put that as low as it can, and FP is taking whatever it had previously and using that if it doesn't interset the atmo. Look at Jool and the Eeloo for FP...
I created these working outwards from Moho, so Jool was done right before Eeloo. That's try for both the MJ and FP examples.
Correction! The comparison above had goofed up MJ2 delta v's for Dres and Jool (I must have clicked somewhere moving it off the actual minimum deltaV. So, my FP minimum delta Vs are not as wildly off as I'd first thought. They are lower in 4 cases and higher in 2. The departure times are off a bit, too - though Duna and Eeloo are nearly spot on the same. The only one that's off a lot in departure is Dres, and I think KPS2 changed the Dres orbit, so maybe that makes sense.
Transit durations are off too, moreso than departure times, significantly so for Dres!
Yes, but both examples are take within the first hour of the actual start of the game - so Year 0, Day 0, Hour 0, and some few minutes
I was thinking more about the performance xD
The image seems very good quality
What is it? 1000x500v
Oh, the perfromance isn't terryibly different I think if you watch the videos above.
It's 330 x 200 in KPS2 and 290x200 in KSP1
Oh damn and its that good
Well, MJ2 was running 290 x 200 and that was acceptable, but I did need to up the game a little 😉
Should make it 4k
Unfortunately, my nodes are kinda horible... Here's what I'm getting rn with a minimum dv trip to Moho
I would not want to book passage on that flight!
It's interesting that it told me the minium delta V 1as 2.144 km/s, but it gave me a node with 4.882 km/s and in a farily horibly wrong direction at that
Wym thats right
If you ignore kerbin you’ll be there in no time
good progress anyway !
Yeah, I make some progress, then get stuck again... I'm getting the weirdest stuff. I've gone into KSP1 and played around in MJ2 in debug mode and got this out of it for an advanced transfer to Moho from near Y0D0H0
And then this for the same operation in KSP2 using FP at essentially the same time
What I've found is that the CalcLamberDVs is giving an exitDV that is nearly the same, but scrambled where the KSP2 exitDV.x ~= KSP1's exitDV.y, and KSP2's exitDV.y ~= KSP1's exitDV.z, but KSP2's exitDV.z ~= (-1)*exitDV.x in KSP1.
There's a similar scramble in vsoi, and position, but with velocity x ~= y, y ~= z, and z ~= x, and in maneuver.dV it's x ~=z, y ~= x, and z ~= y (no sign flips)
It seems like I've got some kind of coordinate system transformation error, but I've not been able to find it.
Could you make a lightweight version of flight plan that simply calculates the launch window when you're in OAB/flight view and you can timewarp to the beginning of the transfer window? 🤔
so basically
you want Transfer Window?
xD thats already a mod
(doesnt have timewarp tho)
As long as the physics stay the same the mod doesnt need an update i think
But test it!
I've integrated transfer angles from Transfer Window into Micro Engineer. Entries are in target window I think.
Dope! It was an idea I had late last night so wanted to see if someone had it/could make it/etc
@slate wave I integrated Transfer Window with FP too, but it's not available in the VAB. If ME's capability is, then you're covered for the VAB - but I think none of the options allow you to time warp to the window. Well... Sort of. With FP you can create a node, then you could move that node around with MNC if you didn't like the time FP gave you. You could use K2D2 to warp to the node I think. Not as nice as a one-button Warp to Start of Window. I'll look into that to see if I can make it simpler for you.
It works in flight only, unfortunately
Well then poo. But why would it be needed in the VAB? I'm not clear on that part
so that you launch already on the right timing
but you can just go to the KSC and warp
I mean technically we could make it that it works from OAB too, but I'm not keen on touching that part of the code again if it's not really important 🙂
Good to know. I'll experiment more this week. I struggled with using flight plan today LOL. Once I figured out the order of things for rendezvous it went super smooth.
the smoothest rendezvous ever:
https://youtube.com/clip/UgkxlB4m2Mvh3XX-604NnQVayLd6buqaaN1Z?si=gyEoNOOX9hDqXxMA
17 seconds · Clipped by cvusmo · Original video "Orbital Station Assembly above Kerbin!" by cvusmo
Thanks! I tried to make the hints reasonably good at guiding. If you find some thing that need more work or are not intuitive please let me know. The planetary transfer stuff is still under construction, but I do hope to get that sorted soon
Not sure how easy it would be to add hints so when you hover over the button it say something like "match planes first" or even just have a instructions button that pops up a window that says:
"To Rendezvous:
- Match Planes
- Hohmann Transfer
- Course Correction
- Match Velocity
- Intercept"
it makes the monotony of building a space station fun. i do like that it does go in order of how you do things. but overall its really solid. some weird bugs happened today, not sure if its the game, mods and the game, not really sure. i couldnt duplicate it either. basically what happened is i left my second craft's SAS on, and it decided to just wobble itself to death. causing a huge debris field which really confused me as I was attempting to set up maneuver nodes to it and they kept changing for some weird reason (what it was trying to dock to blew up)
The buttons already have a tooltip text defined (in most cases), but for whatever reason tooltips are not displayed. @grizzled vale, is there an easy way to get tooltips to work in UITK?
Weird
as far as I know, those are only implemented for the editor, not for runtime (in-game) UITK
so you'd have to create some custom controls for tooltips
Rather than custom controls which each modder would need to develop, could it be added to UITK for KSP2? I'm just wondering how we could standardize it.
yeah of course
also there's this repo with some UITK scripts: https://github.com/plyoung/UIElements
and it does have a tooltip control
I've been thinking of just adapting all those custom controls into UitkForKsp2 anyway
so I might as well do that
the color picker, tooltips and popups seem especially useful
Those would be very nice!
Ahh totally missed this channel somehow lol.
Ok so I don't think the only issue is when making the node if it is at all because the vectors are all WAY off well before we even get to that point
OK so I made a new game in ksp1 and put a simple ship in a 100km orbit using the cheat menu and fast forwarded 1 day to make the date and time match my save in ksp2.
These numbers for positions and velocities for both games are wildly different.
ks1
Origin: Kerbin
Origin Velocity: [-7823.2892582034, -4999.80984608297, 0] : 9284.50070356553
Origin Position: [-7323669563.72694, 11459472898.439, 0] : 13599840256
Destination: Sun
Destination Velocity: [7784.22719812762, 1061.5434805349, 7.03219473601753] : 7856.27883192156
Destination Position: [3197337587.84172, -19562757950.3962, 11239627.3351978] : 19822325610.4231
CalcLambertDVs: detarture at UT 226 d 5:10:36.36, exitDV = [-731.257, -466.934, 14.553] = 867.742 m/s
SOI_intercept: Exit Kerbin's SOI at UT 231 d 2:08:13.60 = 4,997,293.599 s
CalcLambertDVs: vsoi = [-729.807, -465.693, 14.521] = 865.852 m/s
vinf = [-687.745, -438.853, 13.684] = 815.949 m/s
private void CalcLambertDVs(double t0, double dt, out Vector3d exitDV, out Vector3d captureDV, bool debuglog = false)
{
double t1 = t0 + dt;
CelestialBody originPlanet = _origin.referenceBody;
var v10 = originPlanet.orbit.getOrbitalVelocityAtUT(t0).ToV3();
var r1 = originPlanet.orbit.getRelativePositionAtUT(t0).ToV3();
var v21 = _destination.getOrbitalVelocityAtUT(t1).ToV3();
var r2 = _destination.getRelativePositionAtUT(t1).ToV3();
if (debuglog)
{
Debug.Log($"Origin: {originPlanet?.name}");
Debug.Log($"Origin Velocity: {v10} : {v10.magnitude}");
Debug.Log($"Origin Position: {r1} : {r1.magnitude}");
Debug.Log($"Destination: {_destination.referenceBody?.name}");
Debug.Log($"Destination Velocity: {v21} : {v21.magnitude}");
Debug.Log($"Destination Position: {r2} : {r2.magnitude}");
}
ksp2
Origin: Kerbin
Origin Velocity: [-1934.88754207193, 0, 9080.64774749268] : 9284.50070356554
Origin Position: [13301238561.9703, 0, 2834203187.18887] : 13599840256
Destination: Kerbol
Destination Velocity: [-1765.17568137999, 7.01286286065931, -7654.47860190503] : 7855.37631392684
Destination Position: [-19429588439.179, 11319605.0847779, 3938246200.37659] : 19824702221.8271
CalcLambertDVs: detarture at UT 227 d 2:20:20.93, exitDV = [-169.516, 14.544, 850.517] = 867.367 m/s
SOI_intercept: Exit Kerbin's SOI at UT 231 d 5:18:39.93 = 5,008,719.929 s
CalcLambertDVs: vsoi = [-168.816, 14.512, 848.737] = 865.485 m/s
vinf = [-159.078, 13.675, 799.778] = 815.559 m/s
private void CalcLambertDVs(double t0, double dt, out Vector3d exitDV, out Vector3d captureDV, bool debuglog = false)
{
double t1 = t0 + dt;
var originPlanet = _origin.referenceBody;
var v10 = originPlanet.Orbit.GetOrbitalVelocityAtUTZup(t0).SwapYAndZ.ToV3();
var r1 = originPlanet.Orbit.GetRelativePositionAtUT(t0).ToV3();
var v21 = _destination.GetOrbitalVelocityAtUTZup(t1).SwapYAndZ.ToV3();
var r2 = _destination.GetRelativePositionAtUT(t1).ToV3();
if(debuglog)
{
FlightPlanPlugin.Logger.LogInfo($"Origin: {originPlanet?.Name}");
FlightPlanPlugin.Logger.LogInfo($"Origin Velocity: {v10} : {v10.magnitude}");
FlightPlanPlugin.Logger.LogInfo($"Origin Position: {r1} : {r1.magnitude}");
FlightPlanPlugin.Logger.LogInfo($"Destination: {_destination.referenceBody?.Name}");
FlightPlanPlugin.Logger.LogInfo($"Destination Velocity: {v21} : {v21.magnitude}");
FlightPlanPlugin.Logger.LogInfo($"Destination Position: {r2} : {r2.magnitude}");
}
It almost looks like X has become Z, Z became Y and Y became X oddly
Destination Position: [-2566200964.81032, -19672955275.4862, 11804793.129343] ```
vs
Destination Position: [-19429584237.5643, 11319588.3922197, 3938264420.15119] ```
and thats for the position which we are not even using SwapYAndZ
pretty close to the same thing for origin velocity too
Origin Velocity: [-7823.2892582034, -4999.80984608297, 0] : 9284.50070356553
vs
Origin Velocity: [-1934.88754207193, 0, 9080.64774749268] : 9284.50070356554
where if you move the numbers all right 1 slot they make more sense lol
honestly I have NO clue how this is actually making the heatmap almost the exact same for both games while being soooooooo vastly different other then the magnitudes actually match up pretty well equally for everything
I think i doo need to look into the node managers code cause honestly the games code itself says that these vectors should produce an encounter
So I am wondering if node manager is somehow inverting something or not inverting something?
ok so yea I am thinking something is wrong with node manager because when I manually put in DV's to the node controller its making slightly different nodes each time I press the abs button even though the number is the same
ok well I gotta head to work. I'll be back maybe tonight maybe tomorrow
IF you're curious, here are all the MJ files instantiated in Node Manager
Of these, my guess is that the issue might be in OrbitExtensions given some of the things you've found. for example:
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static Vector3d WorldOrbitalVelocityAtUT(this PatchedConicsOrbit o, double UT) // KS2: OrbitalVelocity // was: SwappedOrbitalVelocityAtUT
{
// return o.getOrbitalVelocityAtUT(UT).xzy
return o.referenceBody.transform.celestialFrame.ToLocalPosition(o.ReferenceFrame, o.GetOrbitalVelocityAtUTZup(UT).SwapYAndZ); // from KS2
}
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static Vector3d WorldBCIPositionAtUT(this PatchedConicsOrbit o, double UT) // KS2: RelativePosition // was: SwappedRelativePositionAtUT
{
// return o.getRelativePositionAtUT(UT).xzy
return o.referenceBody.transform.celestialFrame.ToLocalPosition(o.ReferenceFrame, o.GetRelativePositionAtUTZup(UT).SwapYAndZ); // From KS2
}
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static Vector3d WorldPositionAtUT(this PatchedConicsOrbit o, double UT) // was: SwappedAbsolutePositionAtUT
{
// return o.referenceBody.Position.localPosition + o.WorldBCIPositionAtUT(UT);
return o.referenceBody.transform.celestialFrame.ToLocalPosition(o.ReferenceFrame, o.referenceBody.Position.localPosition + o.GetRelativePositionAtUTZup(UT).SwapYAndZ); // from KS2
}
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static Vector3d OrbitNormal(this PatchedConicsOrbit o) // KS2: OrbitNormal // was: SwappedOrbitNormal
{
// return -o.GetOrbitNormal().xzy.normalized
return o.referenceBody.transform.celestialFrame.ToLocalPosition(o.ReferenceFrame, -o.GetRelativeOrbitNormal().SwapYAndZ).normalized; // From KS2
}
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static Vector3d OrbitNormal(this IKeplerOrbit o) // KS2: OrbitNormal // was: SwappedOrbitNormal
{
// return -o.GetOrbitNormal().xzy.normalized
return o.referenceBody.transform.celestialFrame.ToLocalPosition(o.ReferenceFrame, -o.GetRelativeOrbitNormal().SwapYAndZ).normalized; // From KS2
}
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static Vector3d NormalPlus(this PatchedConicsOrbit o, double UT)
{
// return o.OrbitNormal();
return o.referenceBody.transform.celestialFrame.ToLocalPosition(o.ReferenceFrame, o.GetRelativeOrbitNormal().SwapYAndZ.normalized); // From KS2
}
yea... just a quick look at those makes me feel a bit wrong for some reason lol.
Those got set that way months ago when my initial approach was not working at all. I'd tried a number of things, and was getting horrible results, then found that untoldwind's KS2 mod was computing these things this way and getting good results, so I copied his approach. This code may work fine for all the other things FP does, but when you mentioned what you'd found with local position it made me think - what if what's here only works right if you're not looking too far in the future.
I assume this issue is known tho
#1078697132875317358 message
umm.....
hrmm not that that really changes the issue though. just makes the node tilt the other direction
vinf = [-687.745, -438.853, 13.684] = 815.949 m/s
vinf: maneuver.dV = [-894.658, 115.608, 513.464] = 1,037.990 m/s
[Info :Flight Plan] vinf = [-159.062, 13.660, 799.824] = 815.602 m/s
[Info :Flight Plan] vinf: maneuver.dV = [801.655, 644.852, 115.706] = 1,035.313 m/s
this is just straight odd tbh
If you're taking feature requests, please consider adding a gravity turn takeoff. There's a few different examples out there, including linuxgurugamer's Gravity Turn Continued at https://github.com/linuxgurugamer/GravityTurn
not really my place to decide that, but I'd say that belongs more so into https://discord.com/channels/1078696971088433153/1085507549392015370, which is like the autopilot counterpart of this mod
K2D2 does have a lift, but it's not as sophisticated as I would have hoped -- certainly no gravity turn support heh
That being said, I did just mention it there 🙂
I myself would very much appreciate a good PVG implementation
easily my most often used part of Mechjeb
@cyan lotus, did you have a PR for Flight Plan in the works? I know you said you'd found some things to fix in it. I'd like to get whatever you've got ready that can improve things rolled in. I'm not GitHub-savvy enough to figure out how to do that from your fork though.
Tbh the stuff I have so far is useless unless I can figure out why the numbers going into it are all inverted from ksp1
Updated to 0.9.0 for KSP2 0.1.5+ and Unity 2022.3.5f1. Requires Node Manager 0.7.0+, SpaceWarp 1.5.2+, and UitkForKsp2 2.0.0+
hey @wind mica, I took a peek in Flight Plan at how you're calculating positions, latitude and longitude for a given UT and found this function: https://github.com/schlosrat/FlightPlan/blob/master/FlightPlanProject/MJ/OrbitalManeuverCalculator.cs#L49.
However when I applied it to my scenario, I found it was a bit wrong. You can see in the screenshot what the function thinks the flight path will be, marked with a "dotted" line, while the real flight path is marked with a "full" line.
So I discovered it didn't take into account the rotation of the planet.
I then came up with this, which corrects the longitude for the given dt.
longitude -= GetLongitudeOffsetDueToRotationAtDeltaUT(vessel.Orbit.referenceBody, deltaUT);
if (longitude < -180f)
longitude += 360f;
public static double GetLongitudeOffsetDueToRotationAtDeltaUT(CelestialBodyComponent body, double deltaUT)
{
var circumference = 2 * body.radius * Math.PI;
var lengthOfDay = body.rotationPeriod;
var rotationDifferenceAtEquator = (deltaUT * circumference) / lengthOfDay;
return (rotationDifferenceAtEquator / body.radius) * (180 / Math.PI);
}
If you're using this function somewhere in Flight Plan, you might want to take a look at this.
Thanks! I’ll take a look
There's also another bug somewhere, but I can't understand where and why. For Kerbin it works ok, but on Eve the GetLatLonAltFromRadius returns latitudes and longitudes that don't correspond to actual values. I tested it by passing the same current UT into those functions and comparing to regular latitudes and longitudes and there's a difference, a static offset. I don't understand why, the position system is confusing to me still.
I'm assuming that GetLatLonAltFromRadius works correctly, but the position that gets passed into it isn't correct.
Ok, managed to stumble upon a solution that works. Instead of calling WorldPositionAtUT (mechjeb library) which was giving weird results, I just called vessel.Orbit.GetRelativePositionAtUT and it seems to return correct positions.
This is the full code if you're interested.
public static void GetOrbitalParametersAtUT(VesselComponent vessel, double UT, out double latitude, out double longitude, out double altitude)
{
var position = new Position(vessel.Orbit.ReferenceFrame, vessel.Orbit.GetRelativePositionAtUT(UT));
vessel.Orbit.referenceBody.GetLatLonAltFromRadius(position, out latitude, out longitude, out altitude);
longitude += GetLongitudeOffsetDueToRotationForAGivenUT(vessel.Orbit.referenceBody, UT);
if (longitude < -180f)
longitude += 360f;
}
public static double GetLongitudeOffsetDueToRotationForAGivenUT(CelestialBodyComponent body, double UT)
{
// C (circumference) = 2rπ
// length of day = time it takes for 1 full rotation, i.e. C)
// dt = delta T from now to the given UT
// longitude difference = (horizontal distance / radius of the planet) * (180 / π)
var circumference = 2 * body.radius * Math.PI;
var lengthOfDay = body.rotationPeriod;
var deltaUT = ScanUtility.UT - UT;
var rotationDifferenceAtEquator = (deltaUT * circumference) / lengthOfDay;
return (rotationDifferenceAtEquator / body.radius) * (180 / Math.PI);
}
Thanks! I need to look at this. It may offer a clue for why my return from moon function isn’t working right and possibly some other things.
i think flight plan doesnt work in the latest version 😦 Just throws invalid node errors all the time
@wind mica
idk if this even shows anything except invalid node lol
do nodes need to show up on the map after creating them, Cuz if yes thats also broken
SAVE US! 😩
Take your time to fix it right. It’s a little more fun to play without my favorite crutch. 😉
im basically handicapped
cant play without it when i want to dock
ther's just something satisfying about autopilot
Damn he hasn’t been online one whole month. Hope he’s alright and it’s just holiday vacation
No one else got access to his stuff to see what fix there is?
I mean all mods have their source code public
you can take a look at it if you want
I got zero knowledge in coding lol
Well this is disappointing. I’d really hoped that For Science would not break Flight Plan. Unfortunately For Science released 1 day after I left on a 3 week vacation and the only computer I’ve got access to is my Mac laptop. There is literally nothing I can do to test or resolve this until I get back home in January.
If some intrepid soul would like to take a swing at this while I’m away then please be my guest. If you do sort out the issue just give me a PR on GitHub and I’ll be happy to push out the fix. Or, you can wait until I’m back home and able to look into this. So sorry for the inconvenience!
Awh man. Yeah we need someone to fix this. It’s holidays and a lot of people want to chillax in ksp. This mod is like supper essential for lots of people
It's also the time when modders also want to relax as well lol
Yeah I know. The argument goes against it self 😄
I was really bummed when they announced the release date as 1 day into my vacation. I would love to fix this for you guys and do promise to get right on it once I’m back
Thanks man. But enjoy your vacation. 😄
I will see what I can do but no promises
i'll try to fix it too
Thanks guys! If anyone makes progress and gets a working version we can probably work together to post it on SpaceDock. I just can’t compile, debug, or test anything on my Mac. I suspect it’s an issue in Node Manager, BTW, and possibly not in FP itself since it’s also impacting MNC
Yes, it's in Node Manager's CreateManeuverNodeAtUT method
(possibly the other CreateManeuverNode... method as well, haven't gotten around to testing that)
It's not immediately obvious what's wrong since the game's API that this method calls is not different
Note, Ill be looking into this as well tonight
I've delegated this onto Cheese lol
The other one just sets things up and then calls CreateManeuverNodeAtUT IIRC
[Error : Unity Log] NullReferenceException: Object reference not set to an instance of an object
Stack trace:
KSP.Sim.impl.ManeuverPlanComponent.UpdateNodeDetails (KSP.Sim.Maneuver.ManeuverNodeData node) (at <dd6137ea2e634c0ba20d8eb5ac23d499>:0)
KSP.Sim.impl.ManeuverPlanComponent.AddNode (KSP.Sim.Maneuver.ManeuverNodeData nodeData, System.Boolean rebuilding) (at <dd6137ea2e634c0ba20d8eb5ac23d499>:0)
KSP.Sim.Maneuver.ManeuverProvider.AddNodeToVessel (KSP.Sim.Maneuver.ManeuverNodeData node) (at <dd6137ea2e634c0ba20d8eb5ac23d499>:0)
NodeManager.NodeManagerPlugin.CreateManeuverNodeAtUT (Vector3d burnVector, System.Double burnUT, System.Double burnDurationOffsetFactor) (at C:/Games/KSP Stuff/KSP 2 Modding/Mods/NodeManager/NodeManagerProject/NodeManagerPlugin.cs:589)
FlightPlan.FlightPlanPlugin+<CreateManeuverNode>d__49.MoveNext () (at <ef0c6a3fb0734d88bb8567e806c1bbb3>:0)
UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <241ca07620644274b99c2f9d1288d0ab>:0)
UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator)
FlightPlan.FlightPlanPlugin:CreateManeuverNodeCaller(Vector3d, Double, Double)
FlightPlan.FlightPlanPlugin:SetNewAp(Double, Double, Double)
FlightPlan.FpUiController:MakeNode()
UnityEngine.EventSystems.ExecuteEvents:Execute(GameObject, BaseEventData, EventFunction`1)
ModifiedInputModule:ProcessMousePress(MouseButtonEventData, MouseButton)
ModifiedInputModule:ProcessMouseEvent(Int32)
ModifiedInputModule:ProcessMouseEvent()
ModifiedInputModule:Process()
UnityEngine.EventSystems.EventSystem:Update()
It might be as simple as looking at the API function NM calls in a decompiled version of the game to see what’s different
This is the exception, in case anyone finds it useful
Yeah, I suspect doing a diff for the involved methods might make it clear
Yep. I’d start with AddNodeToVessel and chase it down from there
I can buy a coffee for someone who fill fix it if someone interested xD
Fixed! They moved the initialization of the maneuver node's transform outside of the constructor of ManeuverNodeData into a separate method, so to fix it all I had to do was call the initialization method after creating the data object
Congratulations ❤️
So now we have to wait for a release 😄
feel free to test
I only made like 2-3 nodes and didn't extensively test it
both MNC's Add Node button and everything in Flight Plan should work with this
and if it looks like everything works, I'll submit the pull request to schlosrat
ooh actually I changed the version in one place and not the other
so it might not load
a sec
this one should be fine
We literally made an entire template to avoid this
yeah, and this actually used it I think
but a very old version
time for an upgrade
I won't include it in the PR, but I'm open to doing it for anyone who wants
including schlosrat
I've upgraded so many mods to newer template versions at this point that it's like second nature to me lol
PM next :p
So I can add the nuget stuff
Huh?
I should start providing MSaaS
modding support as a service
paid one

buy a license to SpaceWarp.Template for just $12/month, or $120/year, with unlimited technical support
Can I get a discount for maintaining space warp
you could probably get a bulk discount considering how much stuff we do together lmao
I feel like of the major things, uitk and the template are the ones you do solely by yourself
Ksp2unitytools is the one i mostly do by myself
and PM is like 90% you, I basically just did the backend at the beginning
lmao
anyway, sorry for hijacking this thread with these shenanigans
let me know if the new Node Manager works fine
.
the more people test it the better
and in the morning if it looks ok, I'll submit the PR
Just make a draft pr
@grizzled vale I need to do something more than just replacing Node Manager?
Did you use the 2nd zip I sent?
Nope, new one now, and same problem
What does it say when you click node Manager?
Here 0.7.1, but other mods require 0.7.0
wait do you have SpaceWarp 1.7?
1.6.0
well there's the issue
Ah ok
took me a bit to realize
Will update
I should probably make it require only 1.6, since it doesn't rely on any 1.7 stuff
here's yet another version
this one should work with SW 1.6+
Ok, no errors now, I will test in game
I don't know, it looks like Flight Plan and Maneuver Node Controller are deactivated, I can't enable them and during creating node nothing happens, Alt+N shortcut does not work
so opening Flight Plan from the menu doesn't work?
I don't remember how to open Flight Plan 🤦♂️
well just from that, something is seriously wrong with your whole SpaceWarp install
you should not be seeing those #SpaceWarp/.../... texts
I've updated to 1.7.0 now, let's check
it should default to English if you have an unsupported language set
I'm more so questioning whether you might have some old files left over somewhere
I'd recommend deleting the whole BepInEx folder and installing the mods again with CKAN honestly
After 1.7.0 update
goddamit
how did that break
well nevermind, that's a completely unrelated issue most likely
I'll look into that tomorrow
it looks fine for me even with Polish
Do you know issue (not sure it's caused by mods or game itself) when I'm zooming with scroll on map view and it snaps to my ship and I can't zoom in or out anymore?
can't say I've seen it before
I have doubled GRA JEDNOOSOBOWA instead of MODS in menu 😄
Polish is funny
(I'm Czech so I can understand a lot of it but at the same time almost nothing)
it's kinda crazy lol
Yeah, we have fun with a lot of czech words also 😄
but yeah, I would still suggest getting rid of the BepInEx folder and reinstalling the mods fresh
hopefully it will fix the mod list issue
what about Flight Plan, have you given it a try?
Yeah, nodes created and executed, thanks so much for help and for bugfix obviously
awesome, glad to hear it
and if you open Maneuver Node Controller and click Add Node, that works too?
@lucid wing wake up mate 😄
Will try, used only Flight Plan transfer to Mun
thanks for being my QA department tonight lol
Yeah, role reversed, used to be dev 😄
What’s up
Ironic… literally going to bed rn
We have bug fixed
Ain’t no way
Yeah, landed on mun and backed home using mods
Im not as good in KSP 😁
But only with mods
Just starter 2 days ago
Ah
Mun landing is my biggest success
Try minmus next
hah
Bruh
I submitted the pull request with the fix for Node Manager @wind mica
Was gonna ask here if you sent the schlorast anything yeah
😭😂
and here's the zip
Soo after it’s done it will be on ckan?
after schlosrat uploads the new zip to SpaceDock, then it will be
Awesome. So the issue was node controller all along and that’s it. everything else should work fine
yep
Nice
both Flight Plan and Maneuver Node Controller issues should be fixed with this update
I was trying to run my own node with k2d2 idk it didn’t work. Like just executing it.
that's strange, I haven't encountered any issues with that
(though that's also a different mod author)
Yeah
I’ll be trouble shooting today. We’ll see if I can find any issues with any of them
Flight Plan should work with this fixed version of Node Manager: https://github.com/jan-bures/NodeManager/releases/tag/v0.7.1-fork
And I’ve merged the PR. I’ll go upload the zip you’ve shared here on SpaceDock. Thanks @grizzled vale!
Thanks, again, @grizzled vale! I've pushed the zip up to Space Dock and released it there as 0.7.1 noting that it's specific to 0.2.0 and requires SpaceWarp 1.6.0, etc. I think that should sort it out. I've marked FP and MNC as compatible with 0.2.0 based on this. Couldn't have done this without your generous help! I'm not sure if this will enable Kerbals to Fly Safe, but at least they can generate the nodes they need more easily.
Very glad to help!
copying this over from #1083306468540960768 : will Flight Plan/K2D2 automatically wait for the perfect time to do an interplanetary transfer burn, or will it just pick the most efficient burn time in the next orbit? I want to set up a series of probes in LKO ready to transfer to the other planets, but none are currently in the right window to do so.
I'm unable to test this in 0.2.0 as I'm on vacation and so away from my desktop where I develop and test FP. The last time I tested this interplanetary transfers were not working well. Sometimes you would get a good one, and sometimes not. I've got some ideas for how to improve it, but I'm unable to work on those presently.
Also, note that there is an Interplanetary Transfer capability and also an Advanced Interplanetary Transfer capability - just like in MJ. If you're familiar with the KSP1 MJ Advanced Interplanetary Transfer, then you probably only ever used that and never bothered with the other one. Sadly, it's the Advanced one that you would want, and that's the one that's not working. I can make porkchop plots just like KSP1 MJ, and they seem to have the right initial conditions set, but then I can't find the intercept - that's the part that doesn't work. The non-advanced method actually works about as well in either MJ/KSP1 or FP/KSP2 - which is to say that it works poorly and is unreliable. In particular it doesn't like it when the target isn't in more-or-less the same plane.
That said, what it's supposed to do is to find the right window and not just set up a maneuver for the next orbit. Last time I looked, it does do that, but the results are not spectacular. Getting the Advanced Interplanetary Transfer to work as well in FP/KSP2 as you would expect in MJ/KSP1 is on my list of things to do. In fact, that's the main reason I've not advanced FP to 1.0 status.
good to know, thank you very much for taking the time to respond 😊
Sooo... I've finally gotten around to looking into this, and it's curious. You mentioned WorldPositionAtUT but I assume you were referring to WorldBCIPositionAtUT. That's actually in NodeManager, although FP calls it. One curious thing about it is that from the code I can see that the old MJ method it's based on was just a call to GetRelativePositionAtUT
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static Vector3d WorldBCIPositionAtUT(this PatchedConicsOrbit o, double UT) // KS2: RelativePosition // was: SwappedRelativePositionAtUT
{
// return o.GetRelativePositionAtUT(UT).SwapYAndZ;
return o.referenceBody.transform.celestialFrame.ToLocalPosition(o.ReferenceFrame, o.GetRelativePositionAtUTZup(UT).SwapYAndZ); // From KS2
}```
The code I use here was lited from KS2 some time ago, and I've not checked to see if untoldwind has made any changes to that code (I should).
I deviated from what MJ was doing because I was getting some truely insane results with the commented out code. With the KS2 version I could get very sane results for lots of basic maneuvers like changing Pe/Ap/inc, etc.
There are similar deviations in WorldOrbitalVelocityAtUT and WorldPositionAtUT.
When I swap the old way back in it just gives me insane results, and I don't appear to be smart enough to sort out what to do here other than to borrow the code that does work from KS2.
My fear is that what I'm doing here may work for many things but (given what you've found) may also be why I'm having trouble with things like interplanetary transfers and return from moon.
With the KS2 code, just now I was able to get a very sane return from Mun where I was seeking a 100km Pe at Kerbin
However teleporting to the same orbit at Minmus gives me insanity (and a Kerbin ejection) when trying to return
It's possible to merely shift the time on the wacky return to get something not horrible, but it takes a lot of adjustment as the departure burn is at totally the wrong place in the orbit
I was looking into FlightPlan code to see how I could get Latitude and Longitude at a given UT in the past, so I found the GetLatLon method which has o.WorldPositionAtUT(UT). (this line: https://github.com/schlosrat/FlightPlan/blob/7f64e8b8035fe0cffa40d92feb28758302aa881c/FlightPlanProject/MJ/OrbitalManeuverCalculator.cs#L48C1-L48C1)
But that didn't give me good results, so I pretty much guessed with various other stuff and came up with this which worked: https://github.com/Falki-git/OrbitalSurvey/blob/master/src/OrbitalSurvey/Utilities/OrbitUtility.cs#L15 - var position = new Position(vessel.Orbit.ReferenceFrame, vessel.Orbit.GetRelativePositionAtUT(UT)); so basically replacing o.WorldPositionAtUT(UT) with vessel.Orbit.GetRelativePositionAtUT(UT).
I can't help you much as I don't understand it, but just wanted to give you my results if they can help you.
You're much better than me with vectors and positions.
oh and good to see you back 🙂
Good to be back! I may actually play this game now that For Science! is here
it's fun now!
I'm sooo frigging rusty at the code part...
I really do want to get FP fixed up. I wish I was smarter.
my case was looking into the past to get the position, you're looking into future, maybe that's why you're getting different results, don't know
this is the exact line from Orbital Survey that is giving me 100% correct results for a given UT in the past:
var position = new Position(vessel.Orbit.ReferenceFrame, vessel.Orbit.GetRelativePositionAtUT(UT));
then I get lat & lon from that: vessel.Orbit.referenceBody.GetLatLonAltFromRadius(position, out latitude, out longitude, out altitude);
but what I've found is that the latitude, I mean longitude wasn't correct, cause it didn't take into account the rotation of the planet, so I had to do a bit of math to correct it:
public static double GetLongitudeOffsetDueToRotationForAGivenUT(CelestialBodyComponent body, double UT)
{
// C (circumference) = 2rπ
// length of day = time it takes for 1 full rotation, i.e. C)
// dt = delta T from now to the given UT
// longitude difference = (horizontal distance / radius of the planet) * (180 / π)
var circumference = 2 * body.radius * Math.PI;
var lengthOfDay = body.rotationPeriod;
var deltaUT = Utility.UT - UT;
var rotationDifferenceAtEquator = (deltaUT * circumference) / lengthOfDay;
return (rotationDifferenceAtEquator / body.radius) * (180 / Math.PI);
}
Interesting. I've got three functions that all work similarly and that I use each in just one place each
public static double GetLatitude(this PatchedConicsOrbit o, double UT)
{
double latitude, longitude, altitude;
Position position = new Position(o.referenceBody.coordinateSystem, o.WorldPositionAtUT(UT));
o.referenceBody.GetLatLonAltFromRadius(position, out latitude, out longitude, out altitude);
return latitude; // * UtilMath.Rad2Deg;
}
public static double GetLatLon(this PatchedConicsOrbit o, double UT, out double longitude)
{
double latitude, altitude;
Position position = new Position(o.referenceBody.coordinateSystem, o.WorldPositionAtUT(UT));
o.referenceBody.GetLatLonAltFromRadius(position, out latitude, out longitude, out altitude);
// longitude *= UtilMath.Rad2Deg;
return latitude; // * UtilMath.Rad2Deg;
}
public static double GetLongitude(this PatchedConicsOrbit o, double UT)
{
double latitude, longitude, altitude;
Position position = new Position(o.referenceBody.coordinateSystem, o.WorldPositionAtUT(UT));
o.referenceBody.GetLatLonAltFromRadius(position, out latitude, out longitude, out altitude);
return longitude; // * UtilMath.Rad2Deg;
}```
I use GetLongitude only in DeltaVToShiftNodeLongitude for example.
'GetLatLon' is only used in DeltaVToShiftLAN, and 'GetLatitude' is only used in DeltaVToChangeInclination
Of those, I'm fairly sure DeltaVToChangeInclination works reliably, but I only ever do it with the intent to chang inc some time soon (next ascending node, descending node, cheapest, etc.)
I could swap out my approach in these for something like what you've done and see what I get. I've never really trusted what it was doing for shifting LAN.
Latitude is correct for what I've tested, only longitude was skewed. So with what you've said, only DeltaVToShiftLAN could be affected.
I suspect DeltaVToShiftNodeLongitude would also be affected then
Yeah
do you add GetLongitudeOffsetDueToRotationForAGivenUT to the longitude you get from GetLatLonAltFromRadius?
Also, what is Utility.UT? Is that just the current UT for the vessel?
Yes, but the position that I pass to GetLatLonAltFromRadius is different than yours. You can see here everything I'm doing: https://github.com/Falki-git/OrbitalSurvey/blob/master/src/OrbitalSurvey/Utilities/OrbitUtility.cs
Yes, that's just the current UT
oh and WorldPositionAtUT you see on that link I'm not using at all, so you can completely ignore that.
Do these two lines resolve to different positions for the same UT? Did you test that?
// Position position = new Position(o.referenceBody.coordinateSystem, o.WorldPositionAtUT(UT));
Position position = new Position(o.ReferenceFrame, o.GetRelativePositionAtUT(UT));
where o is just this PatchedConicsOrbit o
I'm trying to remember, it was a while ago 🙂 . From what I see I wrote here, I remember that on Kerbin the position was fine, but when I tested it on Eve it was wrong, so I replaced it with the 2nd line you wrote and that gave correct results for any planetary body
So on Eve they should resolve to different positions, you could test that
Curiously, the New LAN function works OK if you're setting the burn option to be ASAP, but if it's at next Ap or Next Pe then it may give poor results when those don't happen to be close to now
This is with your code for position and longitude offset
@wind mica I see someone on the forums is interested in Flight Plan localization
UITK for KSP2 has support for it built-in
if you want, I can set it up for you
(plus, it would also be a good opportunity to convert the project to the newest template)
If you’d like to take a shot at that I’d welcome the help for sure! My concern is that it may be a bigger job than you realize. I de-localized it when porting the old MJ code as it had its own way of doing that and I didn’t want to port that whole system. There is quite a lot to localize. So many buttons on the UI, status messages, etc.
yes for sure you could need a help for that
I can try to work with you on that
from my side K2D2 is absolutely not ready for such a thing 🙂
yeah, mostly because it still uses IMGUI instead of UITK
so it would first have to have that conversion done
yes and I'm not yet ready to do this step. But it will come a day 🙂
The UITK conversion for FP wasn't as hard as I had thought it would be - though it was a learning curve.
It could be a good step. But I've created so many UI components like the compas. It will be harder for K2D2
Anyway I've tested FlightPlan in various situations and I've met some issues
The circularise at altitude is wrong. As I can see it, it is probably a latitude longitude issue. Perhaps planet rotation is not taken in account. I'll try to post a PR to help you
Ah, that is likely. @safe nimbus found a similar thing where WorldBCIPositionAtUT (in Node Manager) was not accounting for planet rotation. But why are you trying to circularize at altitude? It is much easier to circularize at Ap. Have you tried it that way? Let K2D2 Lift run until it's coasting. This will give you a good AP, and you can circularize at Ap reliably I think. Circularize at altitude is intended more for when you're in an eliptical orbit and want to circularize at some place otehr than Pe or Ap.
Yes K2D2 use the circulirize at AP
but I sometime use the circularize at altitude for having a precise altitude
and I know it is less efficient than changin at ap or pe
FYI, this is my main focus for where I see a need to improve FP - and I feel the need is urgent given exploration mode in For Science! When I was first porting MJ2 code to KSP2 I was having a terrible time with things until I started borrowing some code form KontrolSystem 2. Some of the code I use in Node Manager's OrbitExtensions.cs is directly from KS2. In that file you can still see what I had from MJ2 commented out as it didn't work and I still don't know why. When I switched to KS2's method many of the maneuvers did work - but now I see that the price is that I'm not accounting for planet rotation.
/// <summary>
/// Get the orbital velocity at a given time in left handed world coordinates. This value will rotate
/// due to the inverse rotation tick-to-tick.
/// </summary>
/// <param name="o">Orbit</param>
/// <param name="UT">Universal Time</param>
/// <returns>World Velocity</returns>
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static Vector3d WorldOrbitalVelocityAtUT(this PatchedConicsOrbit o, double UT) // KS2: OrbitalVelocity // was: SwappedOrbitalVelocityAtUT
{
// return o.GetOrbitalVelocityAtUTZup(UT).SwapYAndZ;
return o.referenceBody.transform.celestialFrame.ToLocalPosition(o.ReferenceFrame, o.GetOrbitalVelocityAtUTZup(UT).SwapYAndZ); // from KS2
}
/// <summary>
/// Get the body centered inertial position at a given time in left handed world coordinates. This value
/// will rotate due to the inverse rotation tick-to-tick.
/// </summary>
/// <param name="o">Orbit</param>
/// <param name="UT">Universal Time</param>
/// <returns>BCI World Position</returns>
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public static Vector3d WorldBCIPositionAtUT(this PatchedConicsOrbit o, double UT) // KS2: RelativePosition // was: SwappedRelativePositionAtUT
{
// return o.GetRelativePositionAtUT(UT).SwapYAndZ;
return o.referenceBody.transform.celestialFrame.ToLocalPosition(o.ReferenceFrame, o.GetRelativePositionAtUTZup(UT).SwapYAndZ); // From KS2
}
For example, the code above. There you can see that in MJ2 the corresponding functions would be the simple calls to GetOrbitalVelocityAtUTZup and GetRelativePositionAtUT respectively. There are a handfull of other places where I've also borrowed code from KS2 - each time with notes to that effect in the comments.
If I comment out the KS2 approach and go back to the MJ2 approach things dont' work at all for all sorts of simple maneuvers.
for the circle at altitude it is more the determination of the UT that does not work
the result of the node is a perfect circle but at a wrong time
However, Falki found that if he uses NodeManager's WorldBCIPositionAtUT that will not account for planet rotation - something that he needs obviously for his Orbital Survey
what is BCI ??
This is an interesting clue as I'm having some real issues with setting some nodes in the future - like in the Moon Return (just an escape + Hohmann transfer), or especially in Interplanetary Transfer. The further ahead in UT from now that the node is, the worse things seem to be.
BCI == Body Centered Inertial. It's a non-rotating coordinate system centered on a reference body or point in the universe.
thanks !
My plan for now is to go back and do another Diff between my code and MJ2 to catalog all the places where there are significant differences, and to also go in via debug and compare the results from these two methods for various test cases where the requested UT is progressively further out from now. I hope to unravel what's the matter. Hopefully, if I can sort this out, it will solve the issues with Moon Return and Interplanetary Transfer while making other things perhaps slightly better or at least not worse.
the biggest challenge with porting over MJ code is that maneuver nodes work completely differently in KSP2
and it's really complex features to debug
That part at least I think I've got solved.
MJ assumes a maneuver node is a single point in time where the entire impulse is applied, KSP2 assumes a maneuver takes some time, and starts at the beginning, not in the middle, and the burn is integrated over the time duration
that's a better approach because closer to what we can really do with engines
public static Vector3d DeltaVToManeuverNodeCoordinates(this PatchedConicsOrbit o, double UT, Vector3d dV)
{
return new Vector3d(Vector3d.Dot(o.RadialPlus(UT), dV),
Vector3d.Dot(o.NormalPlus(UT), dV), // was -o.NormalPlus(UT). This aligns with KS2
Vector3d.Dot(o.Prograde(UT), dV));
}
Oh that, I've got that solved too, and it works great for burns that are not crazy long.
When the burn time gets long (like in low thrust / high Isp) things are not so good and I'm not sure what to do.
you would probably also have to do the integration that the game itself does, to accurately simulate the resulting node
I've played around with that sort of thing, but never had success with calling the games code for such things.
a custom implementation would most likely be needed
but that's very far from trivial
// Adjust the time on the node so it will start earlier (or later? when would you ever want later?)
if (burnOffsetFactor != 0)
{
// Calculate the time needed for the adjustment
double nodeTimeAdj = _currentNode.BurnDuration * burnOffsetFactor;
// Apply the time adjust
ManeuverPlanComponent maneuverPlanComponent = (_activeVessel?.SimulationObject)?.FindComponent<ManeuverPlanComponent>();
maneuverPlanComponent.UpdateTimeOnNode(_currentNode.NodeID, _currentNode.Time += nodeTimeAdj);
Logger.LogInfo($"CreateManeuverNode: Updated Node.Time = {FPUtility.SecondsToTimeString(_currentNode.Time - UT)} from now");
// Convert the new burnVector to deltaV (at this point _currentNode.Time should have been updated to be at the new time, right?)
Vector3d newDeltaV = orbit.BurnVecToDv(_currentNode.Time, _currentNode.BurnVector);
Logger.LogInfo($"CreateManeuverNode: newDeltaV [{newDeltaV.x:F3}, {newDeltaV.y:F3}, {newDeltaV.z:F3}] m/s = {newDeltaV.magnitude:F3} m/s");
// Compute the change needed for this newDeltaV to equal the original
Vector3d deltaDeltaV = deltaV - newDeltaV;
Logger.LogInfo($"CreateManeuverNode: deltaDeltaV [{deltaDeltaV.x:F3}, {deltaDeltaV.y:F3}, {deltaDeltaV.z:F3}] m/s = {deltaDeltaV.magnitude:F3} m/s");
// Convert this to a burnVector
Vector3d newBurnParams = orbit.DeltaVToManeuverNodeCoordinates(_currentNode.Time, deltaDeltaV);
Logger.LogInfo($"CreateManeuverNode: newBurnParams [{newBurnParams.x:F3}, {newBurnParams.y:F3}, {newBurnParams.z:F3}] m/s = {newBurnParams.magnitude:F3} m/s");
maneuverPlanComponent.UpdateChangeOnNode(_currentNode.NodeID, newBurnParams);
maneuverPlanComponent.UpdateNodeDetails(_currentNode);
}
That's my approach to centering the burn, or part of it. I use the game to compute a burn duration and then offset the time for the node by half that with an adjustment to the burn direction so that it will align with what it would have been at the instantaneous node time since burn is in body coordinates (prograde, normal, radial)
This works fine for most burns using chemical or nuclear engines.
But, yeah, this would need to be more sophisticated for low thrust burns. That would be tricky.
Is @cyan lotus still around here? I'd be curious if he'd like to help tackle this problem since he's got some KSP1 MJ2 experience.
pleeeeease @cyan lotus
Fooling around with the Interplanetary Transfer and I was able to get this with just a small amount of MNC tweaking
Essentially, what I did was go to the Orbital Transfer Maneuvers: Planet tab and look at the Next Window line. When I started this, it was saying the next window was more than 84 days away and the transfer node ingenerated was complete crap. No amount of MNC tweaking could save it. I time warped until the next window was only minutes away and was quickly able to get something that wasn't horrible and did give me some sort of encounter. Nudging that with MNC I was able to get an encounter as shown above.
So, the key thing is to close the time gap to the window before making the node. I believe this confirms that the problem is related to how far in the future the node is.
Weirdly, the node it creates is a good 20 days out from the time I was able to get it to make a reasonable node. I fooled around with MNC and pulled that in to get this
OMW... Let's see how good it does
Seems like I'm on a collision course, not bad
After exiting Kerbin SOI it no longer looks like a collision course, but it is still an intercept/encounter
Well this is a bummer. I clicked on the orbit well before the encounter and told the game to warp to that point and it warped right past the encounter. That sucks.
We need a way to warp to an encounter that doesn't warp right past it.
Trying this again, with a little more fine tuning
Was not hard to get both an Ike and Duna encounter - but that's a lot of luck with Ike being in the right place for the time of the encounter
Oh yeah this totally happens. It's even worse for something like a Minmus encounter where there are two orbital lines very close together that are of the same colour (I still cannot fathom why they decided to bin the colour change upon SOI change), so you can get the game-warps-past-encounter bug OR accidentally click on the wrong orbit. We really need sticky points on SOI changes, Ap/Pe and so on...
@grizzled vale I suggest a warp to SOI change, Ap, Pe as a QoL mod for the Community Fixes and Kerbal Life Hacks
@tulip quarry I've noticed an interesting thing between FP and K2D2. I wanted to make a node while paused so I could place it close to my vessel in the orbit for a quick burn so I paused the game and used MNC to make and empty node, adjust time and burn vector on the node. MNC (and in particular Node Manger) will happily let you do this, which I don't think is any sort of issue. Once I had the node to my liking, I clicked the K2D2 button on FP and guess what? K2D2 began rotating my craft to point in the correct direction while the game was paused! Essentially, with the game paused, K2D2 can and will rotate the vessel, and the game lets you! Probably not what they intended. I think this may constitute hacking an orbit.
The behavior I would have expected would be that K2D2 didn't do anything with the node until the game was unpaused, and then it would react and begin turning the vessel to execute the node. Maybe it should be possible to queue up execution of of a node while paused, but not actually begin rotating the craft. I don't know if this effect is only with FP, but you might try setting up a node in MNC while paused and then see what happens if you can make K2D2 try to execute the node while still paused.
so about what I said earlier with the new template version and localization - I've got the first one done and working on the second one
ORL!?
I created an editor script that is so far still pretty specifically geared towards FP, but I think it could be very useful for others as well
it finds all elements in a UXML file that have either a "text" or "label" property, creates localization keys for them, replaces them with those, and creates a .csv file with the localization
so far I'm pretty happy with the results
though it does still require some preparation beforehand
(like naming most of the elements you want localized - which was easy in this case because FP already has nearly all elements named)
Wow! That's amazing!
and the result
(UITK then replaces all the "text" properties at runtime with their proper localizations)
This is stunning! Honestly, I'm amazed!
it still needs a bit more tuning, but it has achieved what I wanted - leaving a minimal amount of work needed to do manually
Although this part is not so great it seems. Won't this make it really hard for me to see in Unity whether I've laid out the UI in a way that will fit the content?
If I'm understanding you, it sounds like I'd need to launch the game to see how the UI looks
that it will - though it shouldn't be too difficult to add a simple component to the UITK editor package that you could attach to an object with the UI Document
one that you would simply point to your localization file, and it would show the translations in Unity
OK, now we're back to amazing!
If that could be done, then conceivably one could see how the UI works with the various languages they've got localized!
yep, that should be possible
That would be amazing to the power of n - where n is the number of languages
note that none of this will work in the UI Builder itself - I don't think you can run any code inside it
but it will work in play mode
Which, as we know, would be seriously amazing!
Play mode is fine I think. So long as I could test things out in Unity it means I can test without needing to build and launch and all that.
there will still need to be some more work done in the C# code of FP, since not all text is directly written in the UXML, some is dynamically set from code
That's true, but hopefully this will reduce the overall scope to be much more approachable as a problem
and I will most likely need to add support for string interpolation into the localization component of UITK, because currently it only allows to fully replace strings, with no parameters
maybe once you make those binding extensions?
this will definitely be interesting
in case you're interested, I have all this in my fork for now: https://github.com/jan-bures/FlightPlan
Fooling around with an interplanetary transfer process - not a fix really, just an experiment to see how good/bad things might be for Jool.
The theory is that if I create the node when I'm close to the window it might be ok-ish, or at least something that MNC can tweak without too much trouble. Here I've warped to about 1 day before the next transfer window.
Let's see what kind of node it gives me.
that is definitely what I've been seeing widely reported
Node is 13 days in the future, not what I'd hoped for.
Not a good encounter, but maybe salvageable?
That was with the burn option being "at the next transfer window", which the dumb thing tells me is only a day away. Let's see what "as soon as possible" gives me...
Significantly better I'd say, but a bit underpowered. Let's see if MNC can save it.
Hmm, took about 3 or four clicks considering Jools SOI is so freaking huge
More than a few clicks to get this, but still fairly trivial
Though it is over 2K delta-v when departing from an fairly high Kerbin orbit (which made time warping to the transfer window much easier)
Not that bad a solution maybe. Going back to "at the next transfer window give an orbit without an encounter and takes 1.95K m/s
Hmmm... I've been unable to salvage the "at next transfer window" node at all. The encounter is just horrible.
Going back to the "asap" transfer, it's actually just 1 click of Prograde >> away from an Jool encounter - not a great encounter, but still, just one click.
With the right view, tweaking in MNC is pretty darn easy
More than a few clicks, but dead easy
Let's see if this really works - but why wouldn't it?
With a 0.26 TWR and a 2K m/s burn this is gonna take a while just to get going...
Looks good so far, but we're still in Kerbin's SOI
Basically the same after exiting Kerbin SOI. I call this a good Jool transfer trajectory
Well, this is weird... I jetison two empty tanks and my TWR goes down?
down?
Yep, down.
Oh, you're right. I must have been looking at the wrong thing. I thought it was previously 0.3-something
It was! Look further up. It was 0.32 - but that was inside Kerbin's SOI. Not that I'm in Kerbol's SOI it's a measly 0.19
Thrust should be thrust, and mass should be mass... TWR ought to be about mass, not weight, and why would it change due to SOI change?
Well that is true, and it's unitless, so it's force / force, not force / mass
Maybe it's curious that the "weight" went up when I exit Kerbin's SOI. I know Kerbol is big, but damn it's a long way away. It seems strange that the "weight" of the craft goes up when the dominant body is damn far away.
depends on whether ME shows the TWR at current altitude or the surface TWR
Oh that could be it.
Damn, Kerbol is a lot closer than I thought it was! Are you feeling warmer, too?
I'm having some fun here building a Jool armada
Here are 6 probes lashed together to fly there. They've each got two drop tanks, so I lashed them together in a line. I'll probably be able to jettison the drop tanks once I finish my departure burn. When I get this mess to Jool it will enter as a unit, then once captured split up into 6 individual probes for the planet and moons.
The only problem will be collecting some of the science for return. That could be tricky, but the craft that can bring it all home is already headed there, so I could just launch a small roustabout with a docking port and let it run around collecting the data to transfer to the actual return ship.
Speaking of which, is it even possible to force some science to transfer from one docked vessel to another? Hmmm...
whenever two vessels dock, they share science with each other
so you can collect science with one, dock to second, undock, and recover second to get all the science
Does that result in duplicates of stuff, not that duplicates would matter
Perfect! That will work
technically, yes
for this
but it doesn't really matter
since you can only collect the science points once
I wish lights worked from the get go without needing a save and reload, otherwise this would be prettier
I would still like for the samples to be transferred rather than copied, raises the stakes on successfully returning to Kerbin
yeah, the system is currently in a pretty early stage, so I wouldn't be surprised if they keep working on it and make those changes
@wind mica we should probably move here
Yep, right
yep that commit is alright
it's automatically created when merging any pull request
Excellent. Feel free to PR to Dev and I'll work there as well
I had one more question before I do
If you want to make Chinese/Japanese/Korean localizations possible, the fonts you use need to have the appropriate fonts for the languages listed as fallbacks. I already do that with the base fonts in UITK for KSP2, so mods that just use those don't need to include anything extra, but since you use custom fonts, I will need to add the CJK fonts as fallbacks to those separately, and that will mean that your bundle size will grow from ~300 kB to ~50 MB, is that ok with you?
The options are basically the following:
- not allowing translations to Chinese, Japanese or Korean
- switching to using the default UITK for KSP2 fonts
- having the large bundle
The larger bundle is fine. There are lots of bigger mods and I don't think this will be a significant down side. I assume the cost is primarily a slightly longer download, and the there probably isn't a big impact to launching the game and no impact to performance while the game is running - right?
Yeah, it's mostly just about the download times
(Which should be fine for GitHub and CKAN, since CKAN can now use GitHub as the primary download location even for SpaceDock mods)
however, yesterday it took me like 30 minutes to download a 100 MB mod from SpaceDock

In that case I value the enhanced usability (localization) coupled with retaining the visual style (custom fonts) much more than the bundle size
alrighty
Wow, that is weird. I downloaded SORRY recently (which I think is much bigger than 50MB) and it was a bit long, but not 30 min I think
then I'll just test the latest build one more time and then submit the PR
it was most likely a temporary issue with the servers
No need to make long term decisions based on temporary problems!
but the fact is that SpaceDock is pretty slow even on a good day
it was one of the main reasons why CKAN added support for the multiple download mirrors for mods
Hmmm... Come to think of it, I was downloading SORRY via CKAN, so perhaps that was pulling from GH?
looking at its metadata, nope, it doesn't have a GitHub mirror listed
so it was definitely from SpaceDock
OK, well that won't be an issue for FP
also, the project doesn't exactly follow how the template works, I had to do a lot of customization to maintain compatibility with everything, because the project itself is called FlightPlan, but the mod folder is called flight_plan, the GUID is com.github.schlosrat.flight_plan, and the assembly name is com.github.schlosrat.flight_plan
keeping the default mod folder name (FlightPlan) would result in confused users who install it manually and get two different folders with the same mod, and keeping the default assembly name (FlightPlan) breaks K2-D2 integration (and the GUID shouldn't be changed for obvious reasons)
so I modified the project files and build events to rename those manually
oh and I've just noticed one more incompatibility - the assembly name is supposed to be com.github.schlosrat.flight_plan, but the name of the assembly file should be flight_plan.dll instead
Does this mean we need to change the mode name from com.github.schlosrat.flight_plan to just flight_plan? What would the impact be?
I thought I was basically stuck with the longer one
nah like I said, the GUID shouldn't be changed
it should all be resolved now, it was just slightly challenging with the inconsistencies between project name/mod folder name/assembly name/assembly filename/mod GUID
since the template assumes all of these are the same thing
but I hopefully have that all sorted out now
I just had to change up a lot of stuff to give the same exact results as before
Thanks!
alright, submitted the PR
I tested briefly whether all the basics work, like creating a few types of nodes, and K2-D2 and MNC integration, but I would still recommend doing some more thorough testing before continuing work on it
Merged! I'll need to take this for a spin and see how it does. Asside from the normal operations that I'll test, what would I need to do to test the localization?
the localization is not yet in place
