#Flight Plan

1 messages · Page 2 of 1

grizzled vale
#

I wouldn't even mind forking the Baget server project and adding those things myself, but I have literally 0 capacity for yet another high-maintenance project

#

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)

wind mica
#

You're paying for the domains?

#

Could we set up some tiny little patreon thing to cover crap like that?

grizzled vale
#

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

wind mica
#

Free is good!

grizzled vale
#

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

wind mica
#

Damn, the world we live in...

grizzled vale
#

it's probably avoidable but I'm no sysadmin and I don't really want to take that up 😄

wind mica
#

Class extension question for you.

#

So, if I want to extend class foo I just write methods that take (this.foo) as the argument?

grizzled vale
#

yeah

wind mica
#

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...

grizzled vale
#

he was talking mostly just about the physics, not the specific implementation details

#

but anyway that's beside the point right now

wind mica
#

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

wind mica
#

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.

grizzled vale
#

oh yeah I uploaded the Nuget package

#

forgot to mention

wind mica
#

Excellent! I'll fix my csproj for MNC and FP

grizzled vale
#

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

wind mica
#

Good point! Where is that again? In my user folder structure somewhere?

grizzled vale
#

yeah, C:/Users/<username>/.nuget/packages

wind mica
#

@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?

grizzled vale
#

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

wind mica
#

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?

wind mica
#

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&#xD;&#xA;&#xD;&#xA;ECHO off&#xD;&#xA;SET DEST_DIR=$(ProjectDir)..\$(ConfigurationName)&#xD;&#xA;&#xD;&#xA;if not exist &quot;%25DEST_DIR%25&quot; rmdir /s /q &quot;%25DEST_DIR%25&quot;&#xD;&#xA;if not exist &quot;%25DEST_DIR%25&quot; mkdir &quot;%25DEST_DIR%25&quot;&#xD;&#xA;&#xD;&#xA;echo d | xcopy /y /s &quot;$(ProjectDir)..\$(ModId)\&quot; &quot;%25DEST_DIR%25\BepInEx\plugins\$(ModId)\&quot;&#xD;&#xA;echo f | xcopy /y &quot;$(TargetPath)&quot; &quot;%25DEST_DIR%25\BepInEx\plugins\$(ModId)\$(ModId).dll&quot;&#xD;&#xA;if $(ConfigurationName) == Debug echo f | xcopy /y &quot;$(TargetDir)$(TargetName).pdb&quot; &quot;%25DEST_DIR%25\BepInEx\plugins\$(ModId)\$(ModId).pdb&quot;&#xD;&#xA;xcopy /y &quot;$(ProjectDir)..\LICENSE.md&quot; &quot;%25DEST_DIR%25\BepInEx\plugins\$(ModId)\&quot;&#xD;&#xA;echo f | xcopy /y &quot;$(ProjectDir)..\README.md&quot; &quot;%25DEST_DIR%25\BepInEx\plugins\$(ModId)\README.txt&quot;&#xD;&#xA;&#xD;&#xA;cd $(ProjectDir)..\batches&#xD;&#xA;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

cyan plank
#

Looking forward to your porkchop update

wind mica
# cyan plank 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.

tulip quarry
#

Perhaps adding just the first node could be a excellent first step.

wind mica
# tulip quarry 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.

tulip quarry
#

Ok, We should wait for next update then... Damit

cyan plank
wind mica
#

@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

foggy vortex
#

Go ahead, is it the text field stuff?

#

Not showing properly?

wind mica
#

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.

foggy vortex
#

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

wind mica
#

Here's the latest in-game look

foggy vortex
#

Thats w/o u setting the margins manually right?

wind mica
#

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"

foggy vortex
#

Yeah munix can help u a lot more w this since he’s more known of the css arts

wind mica
#

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

grizzled vale
#

so what exactly did you do with the font?

wind mica
#

I tried setting the Font and Font Asset

grizzled vale
#

Font itself doesn't seem to work, but making a dynamic TextCore FontAsset and assigning that should work

wind mica
#

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

grizzled vale
#

are the font assets properly getting bundled?

wind mica
#

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?

grizzled vale
#

not really, those are just the custom fonts I use

#

you're trying to use built-in ones

wind mica
#

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.

grizzled vale
#

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)

wind mica
#

So, I need to edit my FlightPlanTheme.uss file to have it point to the right thing?

grizzled vale
#

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

wind mica
#

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)

grizzled vale
#

no clue what that could be, can you send me your uss?

wind mica
#

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

grizzled vale
#

interesting, this is how it shows up for me in the UI Builder

wind mica
#

Well, that's a lot closer to what I get in game... Not the same, but a lot closer

grizzled vale
#

when I increase the size of the preview window

wind mica
#

My window is 350 x 650

grizzled vale
#

that's exactly what I used

wind mica
#

And it looks pretty much just like what I'm getting in game - may be spot on

grizzled vale
#

here's the window when previewing without KerbalUI vs. with it

#

I think there's your issue

wind mica
#

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?

grizzled vale
#

yeah, basically you're basing your style on a theme that the game isn't using

wind mica
#

Ah ha!

#

So, I just needed to add KerbalUI to the end of my styles to see what I'd get in the game

grizzled vale
#

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

wind mica
#

This is what I get when I switch to PReview and I don't have KerbalUI in the styles

grizzled vale
#

you still didn't set the preview theme to KerbalUI

wind mica
#

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?

grizzled vale
#

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

wind mica
#

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?

grizzled vale
#

well you just need to play around with the heights/margins/paddings

#

to get them to look like you want

wind mica
#

OK, having this WYSIWYG will certainly make a big difference with that. Thanks!

grizzled vale
#

for me just setting the padding to 0 on .unity-text-field made all the difference

wind mica
#

Yep, that did it!

grizzled vale
#

when an element has a set height, increasing the padding will make the content smaller

wind mica
#

Oh that's a handy chart! This definitely helps me understand better which knobs to turn when I want an effect

grizzled vale
#

or even better, here's one from Unity itself:

#

including height and width

wind mica
#

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!

topaz drift
#

css is my passion ❤️

wind mica
#

Once I get that down I'll start ripping out the IMGUI remnants to complete that transition

wind mica
grizzled vale
#

(you haven't seen him writing CSS, I sadly have)

topaz drift
#

it was a joke klueless

#

my css is special

#

munix just can’t appreciate it

wind mica
#

@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

grizzled vale
#

looks to me like you want a padding on the element?

wind mica
#

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.

grizzled vale
#

I haven't even used images in UITK myself yet

#

but I'll try to take a look

wind mica
#

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

grizzled vale
#

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

wind mica
#

Yeah, that works too

grizzled vale
#

at least this way you can click on the outside border and still get the actual button press to register

wind mica
grizzled vale
#

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

wind mica
#

OK, I'll install that. Thanks!

foggy vortex
#

either of these

#

looks great and almost all font packs have them setup to be ideal for close buttons

wind mica
#

@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.

grizzled vale
#

nope

#

it's only for IMGUI

wind mica
#

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.

wind mica
#

@grizzled vale , for swinfo.json do I just need to add this for dependency?

    {
      "id": "UitkForKsp2",
      "version": {
        "min": "1.2.0",
        "max": "*"
      }
    }```
grizzled vale
#

yeah

wind mica
#

Nothing corresponding to <PackageReference Include="UnityEngine.UITK" Version="2020.3.33.1"/>, right?

grizzled vale
#

nope, that's imported into the game by UitkForKsp2

wind mica
#

Cool. Thanks!

grizzled vale
#

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)

wind mica
#

What version of BepInEx?

grizzled vale
#

what do you mean?

#

[BepInDependency(UitkForKsp2Plugin.ModGuid, UitkForKsp2Plugin.ModVer)]

wind mica
#
    {
      "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?

grizzled vale
#

no clue

#

VS doing VS things

wind mica
#

Nope...

grizzled vale
#

well did you import the namespace in the class?

wind mica
#

Nope, should I have?

grizzled vale
#

I mean, you can't use any class without first using its namespace

wind mica
#

And it's happy now!

grizzled vale
#

weird that it didn't show some squiggly line or something

wind mica
# grizzled vale 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;
  }```
grizzled vale
#

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()}");
wind mica
wind mica
#

@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

foggy vortex
#

should be easy

wind mica
#

And the button is defined like this

foggy vortex
#

you see

#

that your width is bold rihgt?

#

try to just rightclick-Unset

wind mica
#

For the button?

foggy vortex
foggy vortex
wind mica
#

That was it! width needed to be 100%

foggy vortex
#

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

wind mica
#

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

foggy vortex
wind mica
foggy vortex
#

drop visual elements inside the foldout

#

tho what u want there is a dropdown

#

not a foldout i think

wind mica
#

Oh? Can it be variable length for the number of items and be reconfigured in game?

foggy vortex
#

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?

wind mica
#

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

foggy vortex
#

then what you want is a TreeView

#

this is a tree view

wind mica
#

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

foggy vortex
#

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

wind mica
#

I don't see that on the list of things I can add in the library. How do I get that?

foggy vortex
wind mica
foggy vortex
#

just put that whereever you want

#

BTW

#

save your files

wind mica
foggy vortex
#

inside ur unity proj

#

inside the assets folder

wind mica
#

How do you populae a list of things into that?

#

Figured it out. Comma separated list in Choices

grizzled vale
#

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

wind mica
#

Well then, ppl will just have to suffer with the current version of FP for a while longer, now won't they?

#

😉

grizzled vale
#

yeah, just wanted to let you know if you try to test it in the game and it shows an error

#

that's why

wind mica
#

Good to know.

#

Also, why did my down arrow thingy vanish?

#

It vanished before I populated choices

#

Maybe when I set the label?

grizzled vale
#

no clue honestly

wind mica
#

Yep that was it

#

If the label is set you don't get it

grizzled vale
#

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

wind mica
#

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...

grizzled vale
#

by the way, the actual popup when clicking on the dropdown won't look like that in the game

#

it takes on the styles from KerbalUI as well

#

the Builder preview just doesn't show it like that for some reason

wind mica
#

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

grizzled vale
#

it does float, otherwise it would just be a foldout

#

internally it's using a PopupTextWindow or whatever the name of the element was

wind mica
#

Excellent! That works for me

wind mica
#

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

tulip quarry
#

so many good work here !!! congratt. UITK seems really good. I'm strugling with good old unity IMGUI. UITK seems to be quite easier.

foggy vortex
#

It is! Its pretty much like building legos

#

If legos were a HTML based language 😅😅

fierce estuary
#

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?

wind mica
#

@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.

wind mica
#

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...

  1. Start with the node at the zero time (at Ap in this case)
  2. Get the world vector corresponding to the burn vector (in this case it's just the prograde vector at the time of Ap)
  3. Back off the node time so the node is bracketing the zero point
  4. Get the new burn vector as a world vector (in this case, the direction of prograde at this new time)
  5. Rotate the new burn vector so that it aligns with the old vector
  6. 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.

lucid wing
#

looks good and thanks!

wind mica
#

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!

grizzled vale
#

it looks great!

grizzled vale
#

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)

wind mica
#

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.

lucid wing
#

@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

wind mica
#

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.

lucid wing
wind mica
# lucid wing yeah awesome, Get in touch with him and get it done. Would really easy up the me...

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?

lucid wing
#

yeah the transfer broke

wind mica
#

Did it burn in the right direction, but just burned too long?

lucid wing
#

it got lost somehow on what to do and didnt stop the burn and kept burning

lucid wing
#

and you gotta love more bugs lmao this game.....

wind mica
#

So it accomplished the burn then kept going, but not in the same direction and instead in some other direction?

lucid wing
#

yeah

wind mica
#

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.

lucid wing
#

ill try

wind mica
#

How's this? Tollerable?

lucid wing
#

1px less

wind mica
#

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)

lucid wing
#

also is this even possible? it couldnt find a solution for the maneuver.

wind mica
#

Apparently it's possible. You just posted proof!

lucid wing
#

Cant make a node

#

i cant execute it

wind mica
#

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.

lucid wing
wind mica
#

It did try.

lucid wing
#

cuz now idk if i should do new ap or some other maneuver

wind mica
#

Make node always tries, and in this case it came back saying the solution was not found.

lucid wing
#

OH HELLO THERE ORBIT

wind mica
#

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

lucid wing
#

idk how to explain i feel like i got the extra broken version of the game or the mods just broke everything else

#

😅

wind mica
#

LOL

#

There is something odd going on here for sure.

wind mica
#

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.

safe nimbus
remote laurel
safe nimbus
safe nimbus
remote laurel
safe nimbus
#

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 ?

grizzled vale
safe nimbus
#

I figured as such.

grizzled vale
#

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

safe nimbus
#

Yikes, then no.

wind mica
grizzled vale
#

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

wind mica
#

Thanks! I'll take a look and get that sorted.

grizzled vale
#

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

wind mica
#

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!

tulip quarry
#

thanks to make it back. really useful for modding

still cedar
#

@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?

wind mica
# still cedar <@402620630585049088> I am having a bit of difficulty with Flight Plan when retu...

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.

wind mica
#

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.

lucid wing
#

That ui rework you did is fantastic

foggy vortex
#

UI Toolkit

remote laurel
wind mica
#

Hmmm... I would not mind knowing how I did this'

foggy vortex
#

its awall of lasers protecting kerbin

#

thank you for your service

wind mica
#

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!

foggy vortex
#

does this hurt the solar bears?

  • PETA activist
wind mica
#

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.

tulip quarry
#

i've met this once. it's like if the step for each orbit line drawing was very long....

wind mica
#

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

wind mica
#

@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!

grizzled vale
#

That looks great!

wind mica
#

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.

wind mica
#

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.

foggy vortex
wind mica
#

Transit durations are off too, moreso than departure times, significantly so for Dres!

wind mica
foggy vortex
#

I was thinking more about the performance xD

#

The image seems very good quality

#

What is it? 1000x500v

wind mica
#

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

foggy vortex
#

Oh damn and its that good

wind mica
#

Well, MJ2 was running 290 x 200 and that was acceptable, but I did need to up the game a little 😉

foggy vortex
#

Should make it 4k

wind mica
#

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

foggy vortex
#

If you ignore kerbin you’ll be there in no time

tulip quarry
#

good progress anyway !

wind mica
# tulip quarry 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.

slate wave
#

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? 🤔

foggy vortex
#

so basically

#

you want Transfer Window?

#

xD thats already a mod

#

(doesnt have timewarp tho)

slate wave
#

🤣 I suppose so.

#

Last update for transfer window was 3/15/23 🤔

foggy vortex
#

As long as the physics stay the same the mod doesnt need an update i think

#

But test it!

safe nimbus
#

I've integrated transfer angles from Transfer Window into Micro Engineer. Entries are in target window I think.

slate wave
#

Dope! It was an idea I had late last night so wanted to see if someone had it/could make it/etc

wind mica
# safe nimbus I've integrated transfer angles from Transfer Window into Micro Engineer. Entrie...

@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.

safe nimbus
#

It works in flight only, unfortunately

wind mica
#

Well then poo. But why would it be needed in the VAB? I'm not clear on that part

foggy vortex
#

so that you launch already on the right timing

#

but you can just go to the KSC and warp

safe nimbus
#

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 🙂

slate wave
# wind mica <@105462692306796544> I integrated Transfer Window with FP too, but it's not ava...

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

YouTube

17 seconds · Clipped by cvusmo · Original video "Orbital Station Assembly above Kerbin!" by cvusmo

▶ Play video
wind mica
slate wave
#

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:

  1. Match Planes
  2. Hohmann Transfer
  3. Course Correction
  4. Match Velocity
  5. 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)

wind mica
#

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?

grizzled vale
#

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

wind mica
grizzled vale
#

yeah of course

#

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

wind mica
cyan lotus
#

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

cyan lotus
#

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

cyan lotus
#

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

wind mica
#

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
        }
cyan lotus
#

yea... just a quick look at those makes me feel a bit wrong for some reason lol.

wind mica
#

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.

candid inlet
#

I assume this issue is known tho
#1078697132875317358 message

cyan lotus
#

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

gaunt fjord
grizzled vale
gaunt fjord
#

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 🙂

grizzled vale
#

I myself would very much appreciate a good PVG implementation

#

easily my most often used part of Mechjeb

wind mica
#

@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.

cyan lotus
#

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

wind mica
#

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+

safe nimbus
#

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.

wind mica
#

Thanks! I’ll take a look

safe nimbus
#

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.

safe nimbus
#

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);
}
wind mica
#

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.

lucid wing
#

i think flight plan doesnt work in the latest version 😦 Just throws invalid node errors all the time

candid inlet
#

@wind mica

lucid wing
#

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

lucid wing
#

SAVE US! 😩

gaunt fjord
#

Take your time to fix it right. It’s a little more fun to play without my favorite crutch. 😉

lucid wing
#

im basically handicapped

#

cant play without it when i want to dock

#

ther's just something satisfying about autopilot

lucid wing
#

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?

grizzled vale
#

I mean all mods have their source code public

#

you can take a look at it if you want

lucid wing
#

I got zero knowledge in coding lol

wind mica
#

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!

lucid wing
#

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

candid inlet
#

It's also the time when modders also want to relax as well lol

lucid wing
wind mica
#

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

lucid wing
#

Thanks man. But enjoy your vacation. 😄

gaunt fjord
#

I will see what I can do but no promises

tulip quarry
#

i'll try to fix it too

wind mica
#

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

grizzled vale
#

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

candid inlet
#

Note, Ill be looking into this as well tonight

grizzled vale
#

I've delegated this onto Cheese lol

wind mica
#

The other one just sets things up and then calls CreateManeuverNodeAtUT IIRC

grizzled vale
#
[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()
wind mica
#

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

grizzled vale
#

This is the exception, in case anyone finds it useful

grizzled vale
wind mica
#

Yep. I’d start with AddNodeToVessel and chase it down from there

wind totem
#

I can buy a coffee for someone who fill fix it if someone interested xD

grizzled vale
#

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

wind totem
#

So now we have to wait for a release 😄

grizzled vale
#

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

candid inlet
grizzled vale
#

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

candid inlet
grizzled vale
#

well technically PM is already on the newest version

#

these are paid addons 😛

candid inlet
#

Huh?

grizzled vale
#

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

candid inlet
#

Can I get a discount for maintaining space warp

grizzled vale
#

you could probably get a bulk discount considering how much stuff we do together lmao

candid inlet
#

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

grizzled vale
#

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

grizzled vale
#

the more people test it the better

#

and in the morning if it looks ok, I'll submit the PR

candid inlet
#

Just make a draft pr

wind totem
#

@grizzled vale I need to do something more than just replacing Node Manager?

grizzled vale
#

Did you use the 2nd zip I sent?

wind totem
#

I'm not sure

#

I'll try again

grizzled vale
#

Thanks

#

It's most likely the old one

wind totem
#

Nope, new one now, and same problem

grizzled vale
#

What does it say when you click node Manager?

wind totem
#

Here 0.7.1, but other mods require 0.7.0

grizzled vale
#

I mean the mods require 0.7.0-*

#

So anything newer should work too

#

Wtf

wind totem
#

Ah ok

#

I've deleted old node_manager directory and replaced with new unzipped

grizzled vale
#

wait do you have SpaceWarp 1.7?

wind totem
#

1.6.0

grizzled vale
#

well there's the issue

wind totem
#

Ah ok

grizzled vale
#

took me a bit to realize

wind totem
#

Will update

grizzled vale
#

I should probably make it require only 1.6, since it doesn't rely on any 1.7 stuff

#

this one should work with SW 1.6+

wind totem
#

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

grizzled vale
#

so opening Flight Plan from the menu doesn't work?

wind totem
#

I don't remember how to open Flight Plan 🤦‍♂️

grizzled vale
#

all mods are here

#

(or should be)

wind totem
#

Yeah, only K2-D2 here

grizzled vale
#

well just from that, something is seriously wrong with your whole SpaceWarp install

#

you should not be seeing those #SpaceWarp/.../... texts

wind totem
#

I've updated to 1.7.0 now, let's check

grizzled vale
#

it should default to English if you have an unsupported language set

grizzled vale
#

I'd recommend deleting the whole BepInEx folder and installing the mods again with CKAN honestly

wind totem
#

After 1.7.0 update

grizzled vale
#

oh...

#

😆

#

and what about the mod list?

#

still broken?

wind totem
#

Ok, let's test finally 🙂

#

This one?

grizzled vale
#

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

wind totem
#

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?

grizzled vale
#

can't say I've seen it before

wind totem
grizzled vale
#

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

wind totem
#

Yeah, we have fun with a lot of czech words also 😄

grizzled vale
#

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?

wind totem
#

Yeah, nodes created and executed, thanks so much for help and for bugfix obviously

grizzled vale
#

awesome, glad to hear it

#

and if you open Maneuver Node Controller and click Add Node, that works too?

wind totem
#

@lucid wing wake up mate 😄

wind totem
grizzled vale
#

thanks for being my QA department tonight lol

wind totem
#

Yeah, role reversed, used to be dev 😄

lucid wing
#

Ironic… literally going to bed rn

wind totem
lucid wing
#

Ain’t no way

wind totem
#

Yeah, landed on mun and backed home using mods

lucid wing
#

This is good news

#

Tried docking too?

#

Rendezvous with station

wind totem
#

Im not as good in KSP 😁

lucid wing
#

But only with mods

wind totem
#

Just starter 2 days ago

lucid wing
#

Ah

wind totem
#

Mun landing is my biggest success

lucid wing
#

Try minmus next

lucid wing
#

No way. I was just thinking of you munix

#

😅

grizzled vale
#

hah

lucid wing
#

Bruh

grizzled vale
#

I submitted the pull request with the fix for Node Manager @wind mica

lucid wing
#

Was gonna ask here if you sent the schlorast anything yeah

grizzled vale
lucid wing
#

Soo after it’s done it will be on ckan?

grizzled vale
#

after schlosrat uploads the new zip to SpaceDock, then it will be

lucid wing
#

Awesome. So the issue was node controller all along and that’s it. everything else should work fine

grizzled vale
#

yep

lucid wing
#

Nice

grizzled vale
#

both Flight Plan and Maneuver Node Controller issues should be fixed with this update

lucid wing
#

I was trying to run my own node with k2d2 idk it didn’t work. Like just executing it.

grizzled vale
#

that's strange, I haven't encountered any issues with that

#

(though that's also a different mod author)

lucid wing
#

Yeah

#

I’ll be trouble shooting today. We’ll see if I can find any issues with any of them

grizzled vale
wind mica
tulip quarry
#

so cool

#

excellent @grizzled vale you Rocks !

wind mica
# grizzled vale and here's the zip

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.

grizzled vale
#

Very glad to help!

vernal lichen
#

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.

wind mica
#

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.

vernal lichen
#

good to know, thank you very much for taking the time to respond 😊

wind mica
# safe nimbus Ok, managed to stumble upon a solution that works. Instead of calling `WorldPosi...

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

safe nimbus
#

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.

wind mica
safe nimbus
#

oh and good to see you back 🙂

wind mica
#

Good to be back! I may actually play this game now that For Science! is here

safe nimbus
#

it's fun now!

wind mica
#

I'm sooo frigging rusty at the code part...

#

I really do want to get FP fixed up. I wish I was smarter.

safe nimbus
#

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);
}
wind mica
#

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.

safe nimbus
#

Latitude is correct for what I've tested, only longitude was skewed. So with what you've said, only DeltaVToShiftLAN could be affected.

wind mica
safe nimbus
#

Yeah

wind mica
# safe nimbus 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?

safe nimbus
safe nimbus
#

oh and WorldPositionAtUT you see on that link I'm not using at all, so you can completely ignore that.

wind mica
#

where o is just this PatchedConicsOrbit o

safe nimbus
#

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

wind mica
#

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

grizzled vale
#

@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)

wind mica
#

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.

tulip quarry
#

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 🙂

grizzled vale
#

yeah, mostly because it still uses IMGUI instead of UITK

#

so it would first have to have that conversion done

tulip quarry
#

yes and I'm not yet ready to do this step. But it will come a day 🙂

wind mica
tulip quarry
#

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

wind mica
# tulip quarry Anyway I've tested FlightPlan in various situations and I've met some issues Th...

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.

tulip quarry
#

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

wind mica
#

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.

tulip quarry
#

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

wind mica
#

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

tulip quarry
#

what is BCI ??

wind mica
#

BCI == Body Centered Inertial. It's a non-rotating coordinate system centered on a reference body or point in the universe.

tulip quarry
#

thanks !

wind mica
#

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.

grizzled vale
#

the biggest challenge with porting over MJ code is that maneuver nodes work completely differently in KSP2

tulip quarry
#

and it's really complex features to debug

wind mica
grizzled vale
#

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

tulip quarry
#

that's a better approach because closer to what we can really do with engines

wind mica
#
        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));
        }
wind mica
#

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.

grizzled vale
#

you would probably also have to do the integration that the game itself does, to accurately simulate the resulting node

wind mica
#

I've played around with that sort of thing, but never had success with calling the games code for such things.

grizzled vale
#

a custom implementation would most likely be needed

#

but that's very far from trivial

wind mica
#
        // 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.

tulip quarry
#

pleeeeease @cyan lotus

wind mica
#

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.

wind mica
#

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

plush coral
# wind mica Well this is a bummer. I clicked on the orbit well before the encounter and told...

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...

wind mica
#

@grizzled vale I suggest a warp to SOI change, Ap, Pe as a QoL mod for the Community Fixes and Kerbal Life Hacks

wind mica
#

@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.

grizzled vale
#

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

wind mica
#

ORL!?

grizzled vale
#

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)

grizzled vale
#

and the result

#

(UITK then replaces all the "text" properties at runtime with their proper localizations)

wind mica
#

This is stunning! Honestly, I'm amazed!

grizzled vale
#

it still needs a bit more tuning, but it has achieved what I wanted - leaving a minimal amount of work needed to do manually

wind mica
#

If I'm understanding you, it sounds like I'd need to launch the game to see how the UI looks

grizzled vale
#

one that you would simply point to your localization file, and it would show the translations in Unity

wind mica
#

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!

grizzled vale
#

yep, that should be possible

wind mica
#

That would be amazing to the power of n - where n is the number of languages

grizzled vale
#

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

wind mica
#

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.

grizzled vale
#

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

wind mica
#

That's true, but hopefully this will reduce the overall scope to be much more approachable as a problem

grizzled vale
#

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

candid inlet
#

maybe once you make those binding extensions?

grizzled vale
#

this will definitely be interesting

wind mica
#

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.

grizzled vale
wind mica
#

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

wind mica
#

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...

wind mica
#

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

wind mica
#

Well, this is weird... I jetison two empty tanks and my TWR goes down?

grizzled vale
#

down?

wind mica
#

Yep, down.

grizzled vale
#

in the previous screenshot it was 0.18 though?

#

and now it's 0.19

wind mica
#

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?

grizzled vale
#

well, it is Thrust-to-weight ratio

#

not TMR for thrust-to-mass ratio

wind mica
#

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.

grizzled vale
#

depends on whether ME shows the TWR at current altitude or the surface TWR

wind mica
#

Oh that could be it.

#

Damn, Kerbol is a lot closer than I thought it was! Are you feeling warmer, too?

wind mica
#

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...

grizzled vale
#

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

wind mica
#

Does that result in duplicates of stuff, not that duplicates would matter

grizzled vale
#

technically, yes

grizzled vale
#

but it doesn't really matter

#

since you can only collect the science points once

wind mica
#

I wish lights worked from the get go without needing a save and reload, otherwise this would be prettier

plush coral
grizzled vale
#

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

grizzled vale
#

@wind mica we should probably move here

wind mica
#

Yep, right

grizzled vale
#

yep that commit is alright

#

it's automatically created when merging any pull request

wind mica
#

Excellent. Feel free to PR to Dev and I'll work there as well

grizzled vale
#

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
wind mica
#

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?

grizzled vale
#

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

wind mica
#

In that case I value the enhanced usability (localization) coupled with retaining the visual style (custom fonts) much more than the bundle size

grizzled vale
#

alrighty

wind mica
grizzled vale
#

then I'll just test the latest build one more time and then submit the PR

grizzled vale
wind mica
#

No need to make long term decisions based on temporary problems!

grizzled vale
#

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

wind mica
#

Hmmm... Come to think of it, I was downloading SORRY via CKAN, so perhaps that was pulling from GH?

grizzled vale
#

looking at its metadata, nope, it doesn't have a GitHub mirror listed

#

so it was definitely from SpaceDock

wind mica
#

OK, well that won't be an issue for FP

grizzled vale
#

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

wind mica
#

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

grizzled vale
#

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

grizzled vale
#

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

wind mica
#

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?

grizzled vale
#

the localization is not yet in place