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

[Grem]

22 hours ago, sarbian said:

Here is a new release for KSP 1.12.x only.  

2.14.0

• UI refactor of the Ascent Guidance
• Improved Principia node Execution
• Performance fix and optimization
• Stuff

Many thanks to the contributors of this release.

MechJeb2-2.14.0.0.zip

When I add the display of the number of crew in the window settings, the window breaks, it becomes empty and cannot be moved around the screen, removing the display of the number of crew, the window's workability is restored

It makes no difference in which window to add this option. She breaks every window.

I use Russian, I hope the video will be understandable.

Spoiler

 

 

MechJeb2-2.12.3.0 does not have this problem.

Edited April 1, 2022 by Grem

[sarbian]

2 hours ago, Grem said:

When I add the display of the number of crew in the window settings, the window breaks, it becomes empty and cannot be moved around the screen, removing the display of the number of crew, the window's workability is restored

It was doing it with any item that can not display a value in the Editor.

Fixed : MechJeb2-2.14.1.0.zip

 

[Grem]

@sarbianThanks! You are gorgeous! ^-^

[SkW3rL]

On 12/3/2021 at 12:55 PM, SkW3rL said:

Apologies if this has been brought up before.  I am playing non-RSS/RO/RP/Scaled KSP version 1.12.2 and was attempting to perform SpaceX style booster return burns with MechJeb version 2.12.3 based on an older video on YouTube (for reference, the version of MechJeb on this video was 2.9.2). I followed the streamers directions to a tee and could not land my rocket back at KSC or on a SpaceX style drone ship; not with any degree of accuracy, at least. The difference I noticed in the video (v2.9.2), as the rocket re-entered the atmosphere, the booster performed a "deceleration burn", but would not perform the same burn in the newer 2.12.3 version. My rocket would continue plummeting towards Kerbin, gaining speeds in excess of 1000m/s and would finally kick on the engines at roughly 300-500m above Kerbin, which would not be enough to stop.  Without the deceleration burn, the rocket would land in the water, or at KSC, 1-3km away from my designated landing zone target. The MechJeb 'Landing Guidance' pop-up showed as "Coasting to deceleration burn", but the burn was never performed, regardless of how fast, or slow, I was going. I went through the GitHub files and found there was a version history and a few changes to the decelerationburn.cs & coursecorrection.cs (obviously other changes were made to other files too, but I didn't feel the other changes affected this instance) between 2.9.2 and 2.12.3, but I am only smart enough to know there was a change, and not what that change actually does or means. I then reverted my downloaded version of MJ to 2.9.2 and the landing guidance worked. Flawlessly! 100% of the time. The rocket would slow down enough, even with atmosphere (I had read in a lot of places MJ couldn't calculate the atmospheric landing guidance very well), landed perfectly, within a half a meter or so. So, in short, v2.9.2 landing guidance works perfectly. V2.12.3, not so much (in my case).

So far, 2.9.2 has not given me any problems on my 1.12.2. install, but to be honest, I only used it for the Landing Guidance and nothing else. Maybe you know about this, maybe you don't, but this is what I found. It's a great mod for what I have used it for, and look forward to learning its other functions in the future. I really wish I could help further, and would like to learn how to do this, but as of now, this is the best information I can provide. I can provide all logs, if necessary, but didn't feel this was relevant to any issue on my machine. If this is not the correct or desired format to list an issue, please let me know. I just want to help and would like to assist as much as possible.

If this is a mistake on my part, please let me know, and I will attempt to make this work on the newer version. Thanks!

Hey there. I retested the same thing on the updated v2.14.1.0 with the same issues as laid out above. I have attached the logs below, and on GitHub. Thank you!

MJ 2.14.1.0

[schlosrat]

Is there any guidance / instruction / manual for the scripting module? This doesn't appear to be documented in the online manual.

What I'm looking to do is set up a brachistochrone trajectory flight. Roughly what I think I want the script to do is this.

• With a target selected, point towards target
• Fly towards that target at a configured max acceleration (set via MechJeb utilities, or whatever the throttle limit is for the active engine)
• At midpoint cut thrust to 0, flip to retrograde, set thrust back to same level as before and begin deceleration burn to the target
• If the target is a planet, then attempt to enter orbit once within the SOI
  • Set inclination to 0 at fixed time (immediately)
  • Set periapsis to 100 km at fixed time (immediately)
  • Circularize at periapsis
• If the target is a ship then attempt to perform a rendezvous with it

Yes, this may produce some crazy long burns. I plan to use Better Time Warp with up to 20x timewarp to try to keep that manageable, but first I need to figure out how to program things like this in the MechJeb scripting module.

Any tips?

 

Edited April 13, 2022 by schlosrat

[schlosrat]

After some playing around with it I think I've determined the MechJeb scripting engine simply can't be used for my purpose. It seems there are zero ways to record a variable or do any math (other than what's done for you behind the scenes in the various MechJeb modules). I'm sure it's fine for a lot of things, but this limitation is... well... rather limiting!

I've switched gears and moved over to using kRPC and python scripts to control my Brachistochrone trajectory. One cool thing with the kRPC is that it's possible to also use it to send commands to MechJeb! This is really nice since the kRPC autopilot suffers from considerable lag compared to what SmartASS can do in game.

I'll be posting my kRPC script on GitHub soon and will post a link back here if anyone is interested. Since it does employ MJ for establishing and cleaning up the final orbit at the destination as well as making use of MJ to control the vessel pointing during the flight maybe it's at least somewhat relevant here.

The SW I'm using is kRPC 0.4.9 compiled for KSP 1.12.1 along with kRPC.MechJeb 0.6.1 (which is compatible with MJ 2.8, but seems to work mostly OK with MJ 2.14, minus a few things that have changed in the MJ interface since 2.8)

Edited April 24, 2022 by schlosrat

[vipAvoS]

Greetings to all dear members of the forum, and separately to the author of this wonderful sarbian mod.

I already drew attention to the problem with the "automatic acceleration of time" from MJ.
To my regret, I have to raise this issue again.
Watch this video. I am sure that you also have the ability to automatically translate videos into your language.

 

[Cagz]

Need a bit of help. I did something (I think it was the action of uninstalling Real Fuels and Solver engines and re-installing them) and now Remote Guidance Units lost their internal MechJeb, so did stock command pods. 

Not a massive issue for new crafts as I can attach a MechJeb on the side but big problem for the ones already in orbit, all of a sudden several modules in orbit no longer have MechJeb

How can I add it back to Remote Guidance Units and Command Pods ? Uninstalling / re-installing mechjeb didn't help.

Many thanks

[schlosrat]

6 hours ago, Cagz said:

Need a bit of help. I did something (I think it was the action of uninstalling Real Fuels and Solver engines and re-installing them) and now Remote Guidance Units lost their internal MechJeb, so did stock command pods. 

Not a massive issue for new crafts as I can attach a MechJeb on the side but big problem for the ones already in orbit, all of a sudden several modules in orbit no longer have MechJeb

How can I add it back to Remote Guidance Units and Command Pods ? Uninstalling / re-installing mechjeb didn't help.

Many thanks

You might try the MechJebForAll mod. https://spacedock.info/mod/1854/MechJebForAll

This is what I use to ensure all my command pods have MJ functionality.

[Cagz]

20 hours ago, Cagz said:

Need a bit of help. I did something (I think it was the action of uninstalling Real Fuels and Solver engines and re-installing them) and now Remote Guidance Units lost their internal MechJeb, so did stock command pods. 

Not a massive issue for new crafts as I can attach a MechJeb on the side but big problem for the ones already in orbit, all of a sudden several modules in orbit no longer have MechJeb

How can I add it back to Remote Guidance Units and Command Pods ? Uninstalling / re-installing mechjeb didn't help.

Many thanks

This patch fixes it:

@PART[*]:HAS[@MODULE[ModuleCommand]]
{
     MODULE
     {
         name = MechJebCore
     }
}

[Jacke]

On 4/25/2022 at 6:31 AM, Cagz said:

This patch fixes it:

@PART[*]:HAS[@MODULE[ModuleCommand]]
{
     MODULE
     {
         name = MechJebCore
     }
}

You actually need a bit more to unlock the functions at all tech levels:

// MM.MechJeb2.MC+KS.<date-version>.cfg
//
// Version 20190205a
// for KSP v1.6.1
//
// Powered by ialdabaoth and sarbian's ModuleManager
//      http://forum.kerbalspaceprogram.com/index.php?/topic/50533--/
// ModuleManager config coding by KSP forum user Jacke
//      http://forum.kerbalspaceprogram.com/index.php?/profile/103694-jacke/
// Copyright 2019 by Jacke
// Licence GNU General Public Licence version 3
//      https://www.gnu.org/licenses/gpl-3.0.en.html
//
// Include this file with Kerbal Space Program
//
// for MechJeb >= 2.1.1
//
// add MechJeb functions to all parts with MODULE ModuleCommand and/or KerbalSeat
// enable these functions from Start of careers
//
// 2019 Feb 05 Tue  confirmed good for KSP 1.6.1 and recent MM and MechJeb2
// 2017 Aug 21 Mon  split code for ModuleCommand and KerbalSeat as '|' in HAS not working
// 2017 Aug 19 Sat  75 Anniversary of the Dieppe Raid - Lest We Forget
//                  confirmed good for MechJeb2 version 2.6.1.0-735
// 2016 Dec 24 Sat  changed to recreate existing MODULE MechJebCore to change the unlockTechs
// 2016 Dec 13 Tue  changed to one @PART block using '|' in :HAS code
// 2016 Dec 12 Mon  added :NEEDS[MechJeb2], added code block for KerbalSeat
//                  similar to Mahal's StockPlugins,
//                  renamed this file from MMJ-Graphotron-ModuleCommand
//                  to MMJ-MechJeb-MC+KS
// 2016 Apr 20 Wed  updated links for KSP new forum
// 2015 May 12 Tue  updated coding
// 2015 May 07 Thu  updated for KSP 1.0.2 and recent changes
// 2014 Aug 30 Sat  changed order of HAS tests
// 2014 Feb 20 Thu  MM coding by Jacke
//
// where    GameData/zzzFinal/
// what     parts with MODULE ModuleCommand and/or KerbalSeat
// files    part config files with MODULE ModuleCommand or KerbalSeat
// nodes    PART's with MODULE ModuleCommand or KerbalSeat
//
//
// Standard Command Modules and Kerbal carrying parts
//
@PART[*]:HAS[@MODULE[ModuleCommand]]:NEEDS[MechJeb2]:FINAL
{
	-MODULE[MechJebCore] {}		// delete any existing MODULE MechJebCore to change unlochTechs
	MODULE
	{
		name = MechJebCore
		MechJebLocalSettings {
			MechJebModuleCustomWindowEditor { unlockTechs = start }		// flightControl
			MechJebModuleSmartASS { unlockTechs = start }			// flightControl
			MechJebModuleManeuverPlanner { unlockTechs = start }		// advFlightControl
			MechJebModuleNodeEditor { unlockTechs = start }			// advFlightControl
			MechJebModuleTranslatron { unlockTechs = start }		// advFlightControl
			MechJebModuleWarpHelper { unlockTechs = start }			// advFlightControl
			MechJebModuleAttitudeAdjustment { unlockTechs = start }		// advFlightControl
			MechJebModuleThrustWindow { unlockTechs = start }		// advFlightControl
			MechJebModuleRCSBalancerWindow { unlockTechs = start }		// advFlightControl
			MechJebModuleRoverWindow { unlockTechs = start }		// fieldScience
			MechJebModuleAscentGuidance { unlockTechs = start }		// unmannedTech
			MechJebModuleLandingGuidance { unlockTechs = start }		// unmannedTech
			MechJebModuleSpaceplaneGuidance { unlockTechs = start }		// unmannedTech
			MechJebModuleDockingGuidance { unlockTechs = start }		// advUnmannedTech
			MechJebModuleRendezvousAutopilotWindow { unlockTechs = start }	// advUnmannedTech
			MechJebModuleRendezvousGuidance { unlockTechs = start }		// advUnmannedTech
		}
	}
}
//
@PART[*]:HAS[@MODULE[KerbalSeat]]:NEEDS[MechJeb2]:FINAL
{
	-MODULE[MechJebCore] {}		// delete any existing MODULE MechJebCore to change unlochTechs
	MODULE
	{
		name = MechJebCore
		MechJebLocalSettings {
			MechJebModuleCustomWindowEditor { unlockTechs = start }		// flightControl
			MechJebModuleSmartASS { unlockTechs = start }			// flightControl
			MechJebModuleManeuverPlanner { unlockTechs = start }		// advFlightControl
			MechJebModuleNodeEditor { unlockTechs = start }			// advFlightControl
			MechJebModuleTranslatron { unlockTechs = start }		// advFlightControl
			MechJebModuleWarpHelper { unlockTechs = start }			// advFlightControl
			MechJebModuleAttitudeAdjustment { unlockTechs = start }		// advFlightControl
			MechJebModuleThrustWindow { unlockTechs = start }		// advFlightControl
			MechJebModuleRCSBalancerWindow { unlockTechs = start }		// advFlightControl
			MechJebModuleRoverWindow { unlockTechs = start }		// fieldScience
			MechJebModuleAscentGuidance { unlockTechs = start }		// unmannedTech
			MechJebModuleLandingGuidance { unlockTechs = start }		// unmannedTech
			MechJebModuleSpaceplaneGuidance { unlockTechs = start }		// unmannedTech
			MechJebModuleDockingGuidance { unlockTechs = start }		// advUnmannedTech
			MechJebModuleRendezvousAutopilotWindow { unlockTechs = start }	// advUnmannedTech
			MechJebModuleRendezvousGuidance { unlockTechs = start }		// advUnmannedTech
		}
	}
}
//
// END OF MM.MechJeb2.MC+KS.<date-version>.cfg

 

[Rodger]

I think the lead time adjustment in mechjeb node autopilot might be bugged - it stops warp early when I increase the lead time (as expected), but it only starts the burn at 50% burntime-to-node. So adjusting the lead time doesn't change when the burn starts.

[vipAvoS]

A very simple question. I create a maneuver in the "maneuver planner". Create and execute. Immediately MJ begins to become maneuverable. After that, it accelerates time, makes 3-4 orbits, turns off the acceleration of time and again begins to become maneuverable. Question - why? Why perform the same action twice? It just wastes time...

[Rodger]

Sounds like it's trying to hold attitude to the node, but during time warp it will drift, and so needs to re-align. When it drifts too far out of alignment, it will drop out of warp to re-align, then re-warp until it's time to burn for the node.

[vipAvoS]

This is absolutely understandable. But, if it's obvious, then why do it twice? Isn't it more reasonable to "become a maneuver" only in the immediate vicinity of the very point of maneuver?

[LTQ90]

3 hours ago, vipAvoS said:

This is absolutely understandable. But, if it's obvious, then why do it twice? Isn't it more reasonable to "become a maneuver" only in the immediate vicinity of the very point of maneuver?

Hi. From my experience, if there is too much error in alignement (aim the blue cross), then MJ will stop the warp near 9 minutes before the start of the burn, realign and restart the warp.

[SciMan]

@vipAvoS

I have encountered this behavior as well, however I think I have a more complete understanding of why it needs to be this way.

It's all about how high your orbit is. And there's a very specific altitude (different for each planet and moon) below which you will see this happen.

At the core, the problem is with how KSP handles reference frames.
Let's take Kerbin as an example.
Any orbit above 70km will never come back down, everyone who has played for long enough knows this.
But there's another threshold altitude, and it is this 2nd, higher threshold altitude that causes problems. For Kerbin, any craft below 120km ASL will be in the same (rotating) reference frame as the surface of Kerbin.
Because of how the game is coded, this means that your craft will rotate relative to the skybox at the same rate that Kerbin itself rotates. Since Kerbin rotates once every 6 hours (6 hour Kerbin days), that's actually quite rapid when you're in time warp.
The problem is that the Maneuver Node does NOT rotate along with Kerbin (it can't, or either the trajectory would end up wrong or the math to figure out where the maneuver node should point would be needlessly much more complex).
But this means that in on-rails time warp below 120km on Kerbin, the craft's prograde vector and the maneuver's intended vector will phase in and out of alignment at the rate of 1 revolution every 6 hours, unless the intended maneuver's vector is directly parallel to the rotational axis of Kerbin.

Because MechJeb is pretty smart, it keeps track of this misalignment even in on-rails time warp. It does this to prevent the misalignment from getting to the point where it can't handle it.
For example, if you come out of time warp, but you're 90 degrees off course because of frame of reference rotation with say 10 seconds left before the burn should start, in a slow turning ship, you just created a situation that neither MechJeb nor the best manual pilot in existence is equipped to handle well, so your maneuver will not be as precise as it could have been.
So instead of letting it get that bad, MechJeb will automatically drop the craft out of time warp if it gets any more than 10 degrees misaligned with the maneuver vector, re-align the ship with the maneuver vector, and then if there's still enough time before the maneuver it will enter time warp again.
As far as I can tell, this is fully intended behavior. The alternative, which would be aligning to where the maneuver node WILL be pointing (accounting for the rotation induced by the rotating reference frame) takes quite a bit more math, and the existing solution works well enough for my personal purposes, even with me making ships that are indeed quite slow to turn due to their size (they have plenty of control authority thanks to RCS, but they're usually several hundred meters long at least, because of a radioactive drive system mounted on a long truss to connect it to the payload/habitation section, like you'd expect a high performance orbit-to-orbit spacecraft to look like IRL).

So in short, the reason it does that is because it's better than the alternative of messing up your maneuver node you may or may not have spent so much time planning out.
And that's fine by me.

[vipAvoS]

Thank you so much for such a comprehensive answer! I am impressed! I will definitely test the situation at altitudes over 120.
However. If this problem? or feature? is known, it’s still not clear why you need to maneuver twice?
In my opinion, I do not pretend to be true, it would be easier to start the acceleration of time and turn the ship to the desired position a few minutes before the maneuver.
And, of course, I completely agree, it is necessary to take into account the ship's ability to maneuver. What one person can do in a couple of seconds, another may take more than a minute.

[vipAvoS]

Once again I want to express my admiration for your knowledge!!!
I just checked the above statement and I can honestly say that you were right! At an altitude of 150 MJ, I immediately set the ship to maneuver and did not apply any more adjustments! Fantasy!!!
Excuse me for being too enthusiastic. Moreover, I also, purely by chance, discovered another wonderful property of this mod. I have not seen any mention of this feature before, so I will tell you about it in my video on the channel
https://www.youtube.com/channel/UC_kEcllvH6r9XMpwCx7up3g/featured
Please note - all the best is born only in close cooperation!

[SciMan]

@vipAvoS

One thing to keep in mind with that thing I was talking about: The altitude at which your spacecraft's heading stops changing in on-rails time warp relative to the skybox, is different for each planet and moon in the Kerbal Kerbol system. I am unsure if there's a specific way to figure it out other than just writing down the numbers in a table.

The thing you're looking for is the "rotating to non-rotating reference frame transition altitude" or something along those lines, but I don't think that information is given to you in-game. It should be available on the Wiki tho, if that's been being kept up-to-date (which I am unsure of but am hopeful).

Edited May 2, 2022 by SciMan

[llamaskywalker]

When i try to Hohman transfer to the mun at optimum time,  It sends me on a collision course. I am orbiting at 400k km and have default settings.

[rmaine]

13 hours ago, llamaskywalker said:

When i try to Hohman transfer to the mun at optimum time,  It sends me on a collision course. I am orbiting at 400k km and have default settings.

Yep; that's typical. I set up the transfer that way and then subtract a few m/s from the maneuver.

[Mokmo]

I've made a new install and I can't get the delta-v window inside the VAB or in flight to work. I put a pod to start, I go to the Custom Window and I can't add anything inside a new custom window as it's not giving me items to add. 

Anything known that could cause this ? 

Edit: Might've found my conflict between some MM scripts to unlock some options. reloading game... 

Edit #2: MM version conflicts, still nothing fixed, looking into what's spamming my debug menu... Clickthroughblocker missing ? 

Final Edit: ClickThroughBlocker and one of its dependencies! It works now!

Edited May 7, 2022 by Mokmo
new info

[jebstwin]

Can anyone please help me. Aircraft autopilot seems to not work for me. I set altitude hold to 3000m but my plane doesn't do anything. I also set my speed hold to 200ms but my speed still keeps rising

[GoldForest]

1 hour ago, jebstwin said:

Can anyone please help me. Aircraft autopilot seems to not work for me. I set altitude hold to 3000m but my plane doesn't do anything. I also set my speed hold to 200ms but my speed still keeps rising

Are you making sure that the check boxes next to altitude and speed are checked and that you pressed "Engage autopilot"?