[1.12.x] Anatid Robotics / MuMech - MechJeb - Autopilot - [2.14.3] [4th March 2023]

[KevinMatt]

sorry, every time I try to use the auto-landing modules and switch my view to map, the game will crash and the Unitycrashhandle will apear, here are the logs from KSP, can you help me? 

[LOG 23:39:15.699] KK: [KerbalKonstructsSettings] Start: Career Module Start Called
[LOG 23:39:15.726] [Part TE.18.DRAGONV2.POD] [ModuleB9PartSwitch 'TE_Service'] Switched subtype to Ore
[LOG 23:39:15.824] [MechJeb2] Loading Mechjeb Dev #946 Sarbian
[LOG 23:39:15.955] [Rendezvous]: Now tracking Ghidorah 9 + Rodan 探测器 vs. Kerbin空间站
[LOG 23:39:15.955] [Rendezvous]: Tracking Ghidorah 9 + Rodan 探测器 vs. Kerbin空间站 ended.
[LOG 23:39:15.963] [Part TE.19.C.Dragon.Decoupler (Ghidorah 9 + Rodan 探测器)] [ModuleB9PartSwitch 'decoupling'] Switched subtype to Rodan Decoupler
[WRN 23:39:15.963] [FlagDecal Warning!]: Flag quad object is given as Decal, but no object found in model with that name
[LOG 23:39:15.963] [Part TE.19.F9.S2.Tank] [ModuleB9PartSwitch 'TE_Fuel'] Switched subtype to LFO
[LOG 23:39:15.966] [ModularFlightIntegrator] MFI Start
[LOG 23:39:15.966] [ModularFlightIntegrator] Start. VesselModule on vessel : 
  ModularFlightIntegrator
  AxisGroupsModule
  CommNetVessel
  KerbetrotterEngineVesselControl

[LOG 23:39:16.188] [UiApp] Awake: CurrencyWidgetsApp
[LOG 23:39:16.188] [UiApp] Awake: ResourceDisplay
[LOG 23:39:16.188] [UiApp] Awake: KSPedia
[LOG 23:39:16.188] [UiApp] Awake: Missions App
[LOG 23:39:16.188] [UiApp] Awake: DeltaVApp
[LOG 23:39:16.188] [UiApp] Awake: ActionGroupsApp
[LOG 23:39:16.188] [ApplicationLauncher] OnSceneLoadedGUIReady: scene FLIGHT ShouldBeVisible() True ShouldBeOnTop() True iIsPositionedAtTop False
[LOG 23:39:16.188] [ApplicationLauncher] SpawnSimpleLayout: VerticalTopDown
[LOG 23:39:16.190] ScaleModList: listSize 164 maxListSize 879
[LOG 23:39:16.191] ScaleModList: listSize 205 maxListSize 870
[LOG 23:39:16.192] ScaleModList: listSize 246 maxListSize 870
[LOG 23:39:16.192] ScaleModList: listSize 205 maxListSize 870
[LOG 23:39:16.193] ScaleModList: listSize 246 maxListSize 870
[LOG 23:39:16.193] [KnowledgeBase] OnAppLauncherReady 25742
[LOG 23:39:16.236] [UIApp] OnDestroy: Contracts
[LOG 23:39:16.304] ScaleModList: listSize 287 maxListSize 870
[LOG 23:39:16.315] [MessageSystem] Reposition 0.02 25743
[LOG 23:39:16.315] [GenericAppFrame] Reposition 0.02 25743
[LOG 23:39:16.315] [GenericAppFrame] Reposition 0.02 25743
[LOG 23:39:16.471] [SmokeScreen ModelMultiShurikenPersistFX] Found TweakScale. Rescaling by 1.000 final scale 2.700
[LOG 23:39:16.474] [SmokeScreen ModelMultiShurikenPersistFX] Found TweakScale. Rescaling by 1.000 final scale 2.000
[LOG 23:39:16.475] [SmokeScreen ModelMultiShurikenPersistFX] Found TweakScale. Rescaling by 1.000 final scale 1.000
[LOG 23:39:16.477] [SmokeScreen ModelMultiShurikenPersistFX] Found TweakScale. Rescaling by 1.000 final scale 1.000
[ERR 23:39:16.477] PrefabParticleFX: Cannot find transform of name 'smokePoint'

[LOG 23:39:16.595] [FlightIntegrator]: Reloaded drag cube for zeroed cube root part landerCabinSmall (Kerbin空间站) on vessel Kerbin空间站
[LOG 23:39:16.606] [FlightIntegrator]: Vessel Kerbin空间站 has been unloaded 99.9200000203564, applying analytic temperature 228.347557309683
[LOG 23:39:16.607] [FlightIntegrator]: Reloaded drag cube for zeroed cube root part TE.19.C.Dragon.Decoupler (Ghidorah 9 + Rodan 探测器) on vessel Ghidorah 9 + Rodan 探测器
[LOG 23:39:16.607] [FlightIntegrator]: Vessel Ghidorah 9 + Rodan 探测器 has been unloaded 99.9200000203564, applying analytic temperature 305.507311136552
[LOG 23:39:16.687] DragCubeSystem: Creating drag cubes for part 'TE.19.C.Dragon.Decoupler'
[LOG 23:39:16.776] [PlanetariumCamera]: Focus: Kerbin空间站
[LOG 23:39:16.852] [UIApp] Adding ResourceDisplay to Application Launcher
[LOG 23:39:16.853] ScaleModList: listSize 287 maxListSize 829
[LOG 23:39:16.853] [UIApp] Adding ResourceDisplay to Application Launcher
[LOG 23:39:16.854] ScaleModList: listSize 287 maxListSize 788
[LOG 23:39:16.870] [ResourceDisplay] OnAppStarted(): id: -933446
[LOG 23:39:16.872] [GenericAppFrame] Reposition 0.1631217 25747
[LOG 23:39:16.873] [ResourceDisplay] OnAppStarted(): id: 262234
[LOG 23:39:16.873] ResourceDisplay already exist, destroying this instance
[LOG 23:39:16.873] [UIApp] OnDestroy: ResourceDisplay
[LOG 23:39:16.874] ScaleModList: listSize 287 maxListSize 788
[LOG 23:39:16.896] [UIApp] Adding ActionGroupsApp to Application Launcher
[LOG 23:39:16.897] ScaleModList: listSize 287 maxListSize 788
[LOG 23:39:16.897] [UIApp] Adding Missions App to Application Launcher
[LOG 23:39:16.898] ScaleModList: listSize 287 maxListSize 747
[LOG 23:39:16.899] CURRENCY WIDGET False False False
[LOG 23:39:16.900] [UIApp] OnDestroy: CurrencyWidgetsApp
[LOG 23:39:16.919] [ActionGroupsApp] OnAppStarted(): id: -933470
[LOG 23:39:16.920] [GenericAppFrame] Reposition 0.2079149 25749
[LOG 23:39:16.921] [UIApp] Adding DeltaVApp to Application Launcher
[LOG 23:39:16.922] ScaleModList: listSize 287 maxListSize 706
[LOG 23:39:16.923] [MissionsApp] OnAppStarted(): id: -933458
[LOG 23:39:16.923] MissionsApp does not execute in this game mode, destroying this instance
[LOG 23:39:16.923] [UIApp] OnDestroy: Missions App
[LOG 23:39:16.923] ScaleModList: listSize 287 maxListSize 706
[LOG 23:39:16.942] [GenericAppFrame] Reposition 0.2329155 25750
[LOG 23:39:16.965] [UIApp] Adding KSPedia to Application Launcher
[LOG 23:39:16.966] ScaleModList: listSize 287 maxListSize 706
[WRN 23:39:16.988] HighlightingSystem : Framebuffer depth data is not available and can't be used to occlude highlighting. Highlighting occluders enabled.
[LOG 23:39:17.224] Flight State Captured
[LOG 23:39:17.224] Saving Achievements Tree...
[LOG 23:39:17.224] Saving Achievements Tree...
[LOG 23:39:17.225] KK: [WindowManager] SavePresets: 
[LOG 23:39:17.225] KK: [WindowManager] SavePresets: Saving: KSCManager : (0.5, 0.5)
[LOG 23:39:17.226] KK: [KerbalKonstructsSettings] OnSave: KKScenario saving career state
[LOG 23:39:17.231] [MASPersistent] OnSave(): 2 registered flight computers
[LOG 23:39:17.232] [MessageSystem] Save Messages
[LOG 23:39:17.307] Game State Saved as persistent
[LOG 23:39:17.900] Unpacking Kerbin空间站
[LOG 23:39:18.009] [UIMasterController]: ShowUI
[LOG 23:39:45.719] [ModularFlightIntegrator] MFI Start
[LOG 23:39:45.719] [ModularFlightIntegrator] Start. VesselModule on vessel : 
  ModularFlightIntegrator
  AxisGroupsModule
  CommNetVessel
  KerbetrotterEngineVesselControl

[LOG 23:39:47.370] [FLIGHT GLOBALS]: Switching To Vessel Ghidorah 9 + Rodan ---------------------- 
[LOG 23:39:47.370] [PlanetariumCamera]: Focus: Ghidorah 9 + Rodan
[LOG 23:39:47.376] InternalSeat: Cannot find portraitCamera of name 'PilotCam'
[LOG 23:39:47.376] InternalSeat: Cannot find portraitCamera of name 'PilotCam'
[LOG 23:39:47.376] InternalSeat: Cannot find portraitCamera of name 'PilotCam'
[LOG 23:39:47.376] InternalSeat: Cannot find portraitCamera of name 'PilotCam'
[LOG 23:39:47.407] [MechJeb2] Focus changed! Forcing Kerbin空间站 to save
[LOG 23:39:47.453] [MechJeb2] Loading Mechjeb Dev #946 Sarbian
[LOG 23:39:47.472] ScaleModList: listSize 287 maxListSize 706
[LOG 23:39:47.713] ScaleModList: listSize 287 maxListSize 706

[Brigadier]

10 hours ago, KevinMatt said:

sorry, every time I try to use the auto-landing modules and switch my view to map, the game will crash and the Unitycrashhandle will apear, here are the logs from KSP, can you help me?

First, welcome to the forums.  I hope we can get you an answer.

Second, I would recommend not posting log extracts.  They can be extremely annoying to those reading the forums on small devices and might not tell the whole story (clearly there's no error in what you've posted).  Third, see the link in my sig block below for information on problem reporting and posting a link to your full log uploaded to a file sharing site.  It'll help those trying to assist you when they can see more information, such as KSP and mod version, list of all mods you've installed, other errors, etc.

You'll often see a comment from modders, "No log...no support".  Sarbian is one of them

[oversoul]

Greetings. While running MJ v292 #492 in KSP 1.9, I get this weird issue in the VAB dV calculator. I build the top stage, with a certain dV. Then when I add the second and third stages, the dV of the stages above decline. I don't recall this issue in v290, this is new. Maybe I will revert. I don't see anything in the github patch notes of #493+ that address this.

= edit =

Noticed something else. I launched a station core, intended for Minmus orbit. I launched a tug section, and docked with the core. I created a Hohmann transfer node to Minmus. I was already in the correct orbital plane. The MJ generated maneuver node was pointing straight down into Kerbin at the designated burn time. I have enough sense to abort and investigate. That's never happened before.

Edited February 19, 2020 by oversoul

[Bogey71]

Hi all,

sorry to just jump in here. I have restarted playing KSP since a looong break (2 years) and now I try to start running everything.

I have KSP 1.7.3 and my biggest problem right now is starting MechJeb2. I have downloaded Version 2.9.1.0, loaded its contents into the Gamedata folder.

The game starts but no Mechjeb controls visible. Anything I need to do? Maybe somebody can post a link to a forum post I missed...?

Thanks ahead

Chris

[Starwaster]

8 hours ago, Bogey71 said:

Hi all,

sorry to just jump in here. I have restarted playing KSP since a looong break (2 years) and now I try to start running everything.

I have KSP 1.7.3 and my biggest problem right now is starting MechJeb2. I have downloaded Version 2.9.1.0, loaded its contents into the Gamedata folder.

The game starts but no Mechjeb controls visible. Anything I need to do? Maybe somebody can post a link to a forum post I missed...?

Thanks ahead

Chris

That's not the correct version of MJ for KSP 1.7.3

Either update KSP or downgrade MJ.

[Mudwig]

Can anyone explain how to stop this from happening?

Spoiler

Why would it pitch down to -29.2° when it isn't even half way to the top of the atmosphere ( and less than 20 seconds to apoapsis )? I've had no problem launching other rockets with the same settings, but with anything using multiple 1st stage boosters like Delta II or Atlas V it just goes nuts and nose-dives immediately after booster separation.

Any help would be appreciated.

[Kerlix]

52 minutes ago, Mudwig said:

Can anyone explain how to stop this from happening?

  Hide contents

Why would it pitch down to -29.2° when it isn't even half way to the top of the atmosphere ( and less than 20 seconds to apoapsis )? I've had no problem launching other rockets with the same settings, but with anything using multiple 1st stage boosters like Delta II or Atlas V it just goes nuts and nose-dives immediately after booster separation.

Any help would be appreciated.

Do you have multiple command pods and/or guidance units under that fairing? I sometimes noticed that after 1st stage burnout, MJ would use an incorrect (180* opposite) orientation and attempt to flip the rocket around. Obviously not conducive to reaching orbit.

If I ever have any doubts, I'll just insert a guidance unit somewhere on the 2nd stage and click "Control from Here" and it would use the proper orientation into orbit. 

I would either then ditch that stage if there were 3, or just select to control from a command pod or docking port at the top of the ship once the fairing was jettisoned.

 

If this has nothing to do with your problem, then I apologise for taking up time with a useless solution. Just the first thing that popped into my head.

[Jimbodiah]

What's the latetst devbuild that will work on 1.8.1?

[Mudwig]

14 minutes ago, Kerlix said:

Do you have multiple command pods and/or guidance units under that fairing? I sometimes noticed that after 1st stage burnout, MJ would use an incorrect (180* opposite) orientation and attempt to flip the rocket around. Obviously not conducive to reaching orbit.

If I ever have any doubts, I'll just insert a guidance unit somewhere on the 2nd stage and click "Control from Here" and it would use the proper orientation into orbit. 

I would either then ditch that stage if there were 3, or just select to control from a command pod or docking port at the top of the ship once the fairing was jettisoned.

 

If this has nothing to do with your problem, then I apologise for taking up time with a useless solution. Just the first thing that popped into my head.

No. It's just a regular Centaur with 1.25m ore tanks as a payload mass simulator under the fairing.

[Ciko]

Is there a special version or "RSS switch" in MJ ? Since MJ advanced transfer to some planets make game freeze and only exit from game help. For example calculation from Earth high orbit to Saturn...

[Jim DiGriz]

17 hours ago, Mudwig said:

Can anyone explain how to stop this from happening?

  Hide contents

 

Why would it pitch down to -29.2° when it isn't even half way to the top of the atmosphere ( and less than 20 seconds to apoapsis )? I've had no problem launching other rockets with the same settings, but with anything using multiple 1st stage boosters like Delta II or Atlas V it just goes nuts and nose-dives immediately after booster separation.

Any help would be appreciated.

For PVG you need to read this:

https://github.com/KSP-RO/RP-0/wiki/TroubleshootingMechJebPVG

For that specific problem, I can't guess how you got there or what went wrong.  PVG diagnosis is dramatically easier with a full video of the launch compared to a screenshot.  All I can tell from that screenshot is that something has definitely broken, which you already know.

[Jim DiGriz]

6 hours ago, Ciko said:

Is there a special version or "RSS switch" in MJ ?

Since MJ advanced transfer to some planets make game freeze and only exit from game help. For example calculation from Earth high orbit to Saturn...

No, there is no RSS switch, the configuration of the planets don't matter at all.

If you are using 1.8 or 1.9 you should be on the latest dev release which has the major overhaul of the advanced transfer planner that I posted the message about awhile back.  If you are not on that version then that behavior is due to known bugs.  If you are playing on 1.7 there is no real solution, except that you need to be in the plane of the ecliptic and need to be in a circular parking orbit.  If you're on the dev version in 1.8/1.9 then I'd need a better bug report.

[Mudwig]

@Jim DiGriz  Thanks for the link.

I tried to use some of the suggestions on that page - including severely limiting pitch rate and QA limit, which helps with the initial ascent - but it still turns towards the horizon at ~20km no matter what I do.

If I use a shorter fairing and a transfer-orbit payload simulator, rather than a low-orbit payload simulator, it flies fine, so I still don't know what the problem is, but I can at least use the Atlas V for the sort of launches it's actually used for.

Edit: Turns out that pressing the button labelled "Reset Guidance (DO NOT PRESS)" right when things go awry makes them go un-awry almost immediately. So I would say do press... when necessary.

Edited February 21, 2020 by Mudwig

[Jim DiGriz]

4 hours ago, Mudwig said:

Edit: Turns out that pressing the button labelled "Reset Guidance (DO NOT PRESS)" right when things go awry makes them go un-awry almost immediately. So I would say do press... when necessary.

Yeah so that button IS there for a reason.

The problem is that I see too many twitch streamers playing with KSP + MJ thinking that they can just button mash, and mashing reset guidance is guaranteed to screw up your day eventually.

You've now figured out when + why you should actually go ahead and press that button.

It should maybe say "pressing this button voids your warranty" -- if it works, great, if it kills your launch you were warned.

[DBowman]

Hi @sarbian thanks for all the great work on an essential mod!

I thought to pass on something that came up for me when I was making MechVal, a bunch of kOS scripts that help you generate large sets of maneuvers to support low thrust trajectory construction. MechJeb wants to match deltaV for the maneuver, but if you are doing Pe kicks the most important thing to match is Ap because that determines the orbit period and ensures that you are in the right place at the right time for the next kick. I guess there might be a similar effect for interplanetary transfers. Low thrust maneuvers have more off-prograde error so this effect matters more the lower your thrust.

Anyway thanks again to you and anyone else making MechJeb so useful.

[Xd the great]

@sarbian Is the airplane landing autopilot on Island runway 09 off? It crashes my plane at the last moment.

[Alexoff]

Well, in 1.9 MJ 947 has broken advanced transfer to another planet.

Spoiler

Some kind of madness for lowest dV...

 

[VoidSquid]

4 hours ago, Alexoff said:

Well, in 1.9 MJ 947 has broken advanced transfer to another planet.

Ooops... yeah, looks like it. After downgrading to #942 (if I read the change log properly, the big changes started with #943), the dv values are back to normal, and the transfer window dates are almost identical with Alex Moons planner. And porkchop graphics are back in line with that planner too again.

@Jim DiGriz in #943, "working circularization at target planet (commit: 5b98db4)" had been introduced, can this be disabled?

Edited February 23, 2020 by VoidSquid

[Jim DiGriz]

4 hours ago, Alexoff said:

Well, in 1.9 MJ 947 has broken advanced transfer to another planet.

  Reveal hidden contents

Some kind of madness for lowest dV...

 

What is in the logs?

Also it helps if you annotate what the different screengrabs are, otherwise I'm stuck looking for clues as to what you're doing and what you are trying to highlight (sometimes it is obvious, but without seeing the buttons you were pressing sometimes its hard to tell what you are actually doing).

Also, it is expected that the porkchop plots will differ from all the other existing transfer planners now.  The calculations that MJ uses now takes into account noncoplanar elliptical inclined parking orbits.  Alex Moon's planner specifies that it is from circular, equatorial orbits only (and I don't know if he's squashed the solar system down into a plane or not to keep the math simple).  MJ used to use a circular approximation (so elliptical orbits were entirely broken) and the code was somewhat unreadable and might or might not have supported inclined non-coplanar parking orbits correctly.

So far I'm having a somewhat difficult time replicating this, although I did notice that at first "box drawing" on the porkchop plot seemed to be entirely broken, although when I hit "create node" once after trying to draw boxes that it picked a completely insane transfer (incredibly expensive but it worked), then I clicked "reset" and it went back to normal.  So it was like it was drawing the boxes and zooming into a section of the porkchop plot but wasn't display it back properly.  IDK how that happened, and it seemed to magically fix itself.

EDIT:  Oh I seem to have figured it out.  First create a node so you have a transfer and "initial orbit cannot be hyperbolic" comes up.  Then draw a box somewhere reasonably expensive (like a small box around some "green" stuff).  The porkchop display will not change, but the box selection will have been made.  The press "remove all nodes" followed by "create node" and get some relatively insane ~4000 m/s transfer even though the display is saying that there should be much better transfers.  Press "remove all nodes" followed by "reset" and then you can go back and draw correctly and it all makes sense.   That seems to just be a UI bug rather than a math bug if that's the problem.

Edited February 23, 2020 by Jim DiGriz

[Alexoff]

1 hour ago, Jim DiGriz said:

What is in the logs?

Also it helps if you annotate what the different screengrabs are, otherwise I'm stuck looking for clues as to what you're doing and what you are trying to highlight (sometimes it is obvious, but without seeing the buttons you were pressing sometimes its hard to tell what you are actually doing).

Also, it is expected that the porkchop plots will differ from all the other existing transfer planners now.  The calculations that MJ uses now takes into account noncoplanar elliptical inclined parking orbits.  Alex Moon's planner specifies that it is from circular, equatorial orbits only (and I don't know if he's squashed the solar system down into a plane or not to keep the math simple).  MJ used to use a circular approximation (so elliptical orbits were entirely broken) and the code was somewhat unreadable and might or might not have supported inclined non-coplanar parking orbits correctly.

So far I'm having a somewhat difficult time replicating this, although I did notice that at first "box drawing" on the porkchop plot seemed to be entirely broken, although when I hit "create node" once after trying to draw boxes that it picked a completely insane transfer (incredibly expensive but it worked), then I clicked "reset" and it went back to normal.  So it was like it was drawing the boxes and zooming into a section of the porkchop plot but wasn't display it back properly.  IDK how that happened, and it seemed to magically fix itself.

EDIT:  Oh I seem to have figured it out.  First create a node so you have a transfer and "initial orbit cannot be hyperbolic" comes up.  Then draw a box somewhere reasonably expensive (like a small box around some "green" stuff).  The porkchop display will not change, but the box selection will have been made.  The press "remove all nodes" followed by "create node" and get some relatively insane ~4000 m/s transfer even though the display is saying that there should be much better transfers.  Press "remove all nodes" followed by "reset" and then you can go back and draw correctly and it all makes sense.   That seems to just be a UI bug rather than a math bug if that's the problem.

I prefer to use TWP as you can see, I did report about annoying bug and nothing else

[VoidSquid]

I'll do some testing with different MJ versions, @Jim DiGriz, if you want me to.

The reason I was reverting when planning a Kerbin-Duna transfer from a circular equatorial LKO is that required dv was around 2700 m/s, instead of the usual 1600-1700 (incl. capture burn), and the time of the transfer was more than 30 days off from the TWP, that seemed pretty wrong to me, and Kerbin and Duna have an almost zero relative inclination, so everything is almost perfectly coplanar.

Edited February 23, 2020 by VoidSquid

[Jim DiGriz]

1 hour ago, VoidSquid said:

I'll do some testing with different MJ versions, @Jim DiGriz, if you want me to.

The reason I was reverting when planning a Kerbin-Duna transfer from a circular equatorial LKO is that required dv was around 2700 m/s, instead of the usual 1600-1700 (incl. capture burn), and the time of the transfer was more than 30 days off from the TWP, that seemed pretty wrong to me, and Kerbin and Duna have an almost zero relative inclination, so everything is almost perfectly coplanar.

So the porkchop plotter for the transfers WHEN including the transfer burn will be off by a bit.  Currently it is still just taking the difference between the helocentric transfer orbit and the helocentric velocity of the target planet and calling that the "capture burn".  So there's a discrepancy of 200 m/s extra that I find when I actually plot it.  That's a known issue.

Oh yeah, delta-V maps have kerbin LEO to duna intercept of about 1060 and 600 to capture.  And visibly it just looks poor to my eye, the transfers burn isn't very tangential to the parking orbit.  And since it affects the porkchop plot equally, and from the logs it doesn't look like the optimization of the maneuver node is changing the dV much, it looks like its a bug in the new analytical burn calculator.  Okay, that repos really simply.

There's no workaround, I probably just have a math bug someplace to track down.

[Grem]

Hi guys! Could you answer a couple of questions?!

1. MechJeb in career mode is now available from the start and integrated into all the pods?

2. Is the link from the topic header "Small MechJeb touchscreen case an alternative model for the part" no longer available? Can I use this little nice model and where can I find it now?

Thanks!

[VoidSquid]

10 hours ago, Jim DiGriz said:

There's no workaround, I probably just have a math bug someplace to track down.

Thanks for looking into this, and again, let me know if I can help with doing some testing.

16 hours ago, VoidSquid said:

#943, "working circularization at target planet (commit: 5b98db4)" had been introduced, can this be disabled?

Reasons I asked: as per my experience (my old career going for 2.5 years, KSP 1.3.1 - 1.7.3), in particular with long transfer burns (5+ minutes), more often than not I didn't even get an encounter anymore after the transfer burn, and had to make a correction burn of approx. 10-60 m/s just minutes later. From this, it makes no sense to me to have a target circularization burn already calculated with the transfer burn. Also, I almost always make little correction burns on my way to the target CB, thus naturally invalidating any pre-calculated other burns. And finally, quite often I don't want to make an immediate cirularization when entering the target SOI, sometimes I prefer to go into an elliptical orbit, sometimes I just want to do a flyby, or something else (think e.g. of satellite contracts  requiring a very specific orbit).

Last question: am I correct that #942 is the last version doing the "classic" coplanar calculations?

Thanks again for all your great work, and I'm looking forward to hear from you.

Edited February 24, 2020 by VoidSquid

[Jim DiGriz]

17 hours ago, VoidSquid said:

Thanks for looking into this, and again, let me know if I can help with doing some testing.

Reasons I asked: as per my experience (my old career going for 2.5 years, KSP 1.3.1 - 1.7.3), in particular with long transfer burns (5+ minutes), more often than not I didn't even get an encounter anymore after the transfer burn, and had to make a correction burn of approx. 10-60 m/s just minutes later. From this, it makes no sense to me to have a target circularization burn already calculated with the transfer burn. Also, I almost always make little correction burns on my way to the target CB, thus naturally invalidating any pre-calculated other burns. And finally, quite often I don't want to make an immediate cirularization when entering the target SOI, sometimes I prefer to go into an elliptical orbit, sometimes I just want to do a flyby, or something else (think e.g. of satellite contracts  requiring a very specific orbit).

Last question: am I correct that #942 is the last version doing the "classic" coplanar calculations?

Thanks again for all your great work, and I'm looking forward to hear from you.

Yeah MJ really needs a proper finite burn executor.  There's already a button though to omit the circularization burn completely from the porkchop and then you don't get the maneuver node.  I've got plans of extending the UI to support targeting an inclination and an apoapsis (or SMA + ECC).  I can probably include a button though to omit the second burn.  At some point though I'm going to want to implement a flyby finder which will necessarily require dropping maneuver nodes on every flyby.  There needs to be some kind of better solution to this -- ideally a multinode finite burn executor that target a list of orbits rather than a list of maneuver nodes and which can be suspended in the background and will wake itself up like KAC. 

#942 looks right.

Still working on the buggy behavior, I went barking up the wrong tree last night, got a few things to try today.  I don't think I have any need for more replication cases, it is pretty obviously broken in the coplanar case (I did a lot of testing in awful non-coplanar, elliptical cases that I assumed would be the best problems to find bug but never bothered much with the trivial cases).

EDIT: I figured it out, just needed to keep reading further in the paper I was implementing.  Replicated some values for Kerbin->Duna from Alex Moon's transfer planner in Matlab.  Might have it fixed in a couple days.

 

Edited February 25, 2020 by Jim DiGriz