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

[sarbian]

Oh noes !  This was such a well-kept secretz!

[NewsDude]

Hey, so I tried the version 2.12.0, and I keep getting an error. "MechJeb2 is not compatible with KSP version 1.12.1". So I tried the Dev Build (2.12.0.0-1088). I also can't seem to locate the logs. Could anyone help me find the logs at least? I tried to follow the directions listed here but it didn't work. I am running MacOS Big Sur (11.3.1).

[ZionTheRocketMan]

3 hours ago, NewsDude said:

Hey, so I tried the version 2.12.0, and I keep getting an error. "MechJeb2 is not compatible with KSP version 1.12.1". So I tried the Dev Build (2.12.0.0-1088). I also can't seem to locate the logs. Could anyone help me find the logs at least? I tried to follow the directions listed here but it didn't work. I am running MacOS Big Sur (11.3.1).

same with me, but sorry I can't help you because you're using MacOS, while I'm only using windows, maybe we should wait for the mod to be updated, just be patient my friend

[Oman395]

Any idea when we'll get 1.12 support?

[Snark]

Hello, and welcome to the forums! 

35 minutes ago, Oman395 said:

Any idea when we'll get 1.12 support?

The author has already helpfully supplied an answer, just a few posts above.  I'd suggest referring to that. 

And no, the answer isn't very specific, which is clearly the author's intention, meaning "it'll be ready when it's ready".  If they were prepared to give a more specific date, presumably they would have done so.  So, best thing to do is simply to :

1. be patient
2. reflect on how fortunate we are that modders choose to continue their precious and scarce free time to give us these shiny toys for free
3. wait for whenever it happens to come out.  Doubtless there will be an announcement about it here, so watch this space.

[HansAcker]

3 hours ago, Snark said:

So, best thing to do is simply to :

I'd add:

4. Give it a try and report if and what features are not working.

The message at startup is not an error, just an informational warning. MechJeb appears to be working  in 1.12 for me.

[artwhaley]

I'll also add - most of what I know about unity development...  I learned by helping to update mods when KSP versions changed.  I don't mean this in a facetious way at all - but if you're smart enough to play KSP, you're smart enough to code in C# and you might find a new hobby by getting into it!   

Roll back your game install to 1.11.  Download the source, open it in visual studio, resolve the references (usually to the DLLs in the game directory), get it compiling (ask questions if you have trouble!)  Upgrade your game to 1.12.   Click the compile button.   You'll get a list of errors.   Start double clicking through them and play detective with the auto-complete text to figure out what's changed and fiddle with it until it stops giving that error on compile.   Move to the next one.    When all the error messages are fixed, load the game with your DLL instead of Sarbian's in the mechjeb directory.   Test all the things you think you touched.    If it all works, make a pull request.   @sarbian will then tell you all the things you screwed up.   Fix those things.   Make another pull request.    If he uses any of your fixes, celebrate.  There's nothing cooler than knowing 10 lines of Mechjeb code are your work and every body playing the game has you to thank for it.    It's even more appreciated for the less maintained mods.   I don't know if @linuxgurugamerstill maintains 4 zillion mods...  but a few years back, every update he was buried and was profuse with the thanks if you could error check a couple of little ones for him.   

It sounds daunting but it's really not that bad.   Follow one of the 'make your first plugin' tutorials to make sure you have the build process figured out before you wade into other people's mods...   then pitch in.   It's really not any harder than orbital rendezvous and it can be a rewarding hobby all it's own.  And once you start messing with mods, you've opened up the next 1000 hours of fun you can get out of this game.  I've probably spent as much time modding as I have actually playing.  

 

[Sesshaku]

I think I found a small bug in autolanding that might help Sarbian.

The problem occurs when playing with Principia and RO. When autolanding, sometimes Mechjeb will try to position to the node, warp, and then start suicide burn. Now that's fine. The problem is that Principia and RO have each their own version of "persistent rotation" while warping (you have to choose one of those, I have the Principia one, but still, both mods have one).

That means that Mechjeb will sometimes position to the node, warp, but because of persistent rotation, if will caught itself in a loop of warping for 1 second, reposition, warping, reposition, warping, reposition, etc.

In other words, I believe Mechjeb can't handle persistent rotation. A quick solution (at least gameplay wise) is to just not give the order of landing until you're close to the suicide burn window, that way it will just burn without warping. But still, perhaps there's a more "official" solution to the problem.

 

Also since we're on it. It would  be cool to have a mod that could create transfer maneuvre nodes for Principia. Doesn't have to be super precise, just the general transfer window you get with Mechjeb on stock KSP.

Edited July 1, 2021 by Sesshaku

[Starwaster]

@SesshakuI’ve seen that happen with stock. Persistent rotation not required. 

[FrancoisH]

23 hours ago, Oman395 said:

Any idea when we'll get 1.12 support?

I hope before people starts to read previous posts answering this very same question (like just a page before). Who am I fooling, it can only be before that as it will never happens.

[Sesshaku]

7 hours ago, Starwaster said:

@SesshakuI’ve seen that happen with stock. Persistent rotation not required. 

Oh, then there goes my idea of what's causing it.

[dlrk]

The BetterController, HybridController and the MJAttitude Controller handle aerodynamic surfaces (At least with FAR) very poorly, but the KOSAttitudeController works great. Would it be possible to take a look at this and improve the other controllers handling?

Edited July 2, 2021 by dlrk

[Nightmare]

21 hours ago, FrancoisH said:

I hope before people starts to read previous posts answering this very same question (like just a page before). Who am I fooling, it can only be before that as it will never happens.

That reminds me of a thing with linuxgurugamer who is also streaming on twitch:

 

Guy comes in the stream and asks hey when is mod xyz ready for the new ksp release.

Anwer: Hey you see iam just working on it

The only thing i saw of this guy was the thing left channel...

 

One thing i noticed that seems to have quit working right is auto dock.

When i set a dockingport for control from here it seems to mess up the axis and the ship never tries to dock with the port forward mostly 90 degrees to the side.

 

But i am shure this will be handeld in time.

[kfsone]

4 hours ago, Nightmare said:

One thing i noticed that seems to have quit working right is auto dock.

When i set a dockingport for control from here it seems to mess up the axis and the ship never tries to dock with the port forward mostly 90 degrees to the side.

 

But i am shure this will be handeld in time.

I've seen the same issue but only ever with the inflatable docking port and only with *specific* inflatable docking ports, and for now I'm thinking mea-culpa: one time I think I set "control from here" before opening the airlock, and the other times the problem went away when I used a different port on the same vessel, so I think opening the airlock throws off the rcs thrusters.

 

[Oman395]

On 7/1/2021 at 3:49 PM, FrancoisH said:

I hope before people starts to read previous posts answering this very same question (like just a page before). Who am I fooling, it can only be before that as it will never happens.

its easier to just ask again then search for a while for something that might not exist

[rmaine]

1 hour ago, Oman395 said:

its easier to just ask again then search for a while for something that might not exist

The tradeoff, of course, is that multiple people asking means more work for the person responding. As you are asking the favor of someone else taking the time to respond, it is generally considered polite (as well as more effective) to make at least a token effort before asking. This principle of also considering other people's time applies to life in general, I might add - not just to forum posts. As a software author (before I retired), I occasionally ran into people asking me to essentially read the documentation to them - documentation I had spent a lot of time writing so as to keep from having to explain the same thing to many people.  I'd point them to the exact page, but they still wanted my time to essentially read that page to them. Those people tended to make it on my list of ones not worth responding to in the future. I don't think anyone expects you to paw through 150 pages of thread, but it doesn't take much effort to check at least the last few posts for something so likely to have come up recently. Look up the somewhat snarky acronym lmgtfy on similar matters.

[Brigadier]

1 hour ago, Oman395 said:

its easier to just ask again then search for a while for something that might not exist

Ninja'd by @rmaine

It might be easier for you but if a mod author has to answer every person who asks this same question that's been answered a page or two (sometimes literally in the post above the question) back on the thread, it can detract from developing/updating the mod. 

Edited July 3, 2021 by Brigadier

[ColdJ]

1 minute ago, rmaine said:

The tradeoff, of course, is that multiple people asking means more work for the person responding. As you are asking the favor of someone else taking the time to respond, it is generally considered polite (as well as more effective) to make at least a token effort before asking. This principle of also considering other people's time applies to life in general, I might add - not just to forum posts. As a software author (before I retired), I occasionally ran into people asking me to essentially read the documentation to them - documentation I had spent a lot of time writing so as to keep from having to explain the same thing to many people.  I'd point them to the exact page, but they still wanted my time to essentially read that page to them. Those people tended to make it on my list of ones not worth responding to in the future. I don't think anyone expects you to paw through 150 pages of thread, but it doesn't take much effort to check at least the last few posts for something so likely to have come up recently. Look up the somewhat snarky acronym lmgtfy on similar matters.

Though I agree in principal with you, I have had to deal with the frustration of the forums search engine. You can put in the exact thing you are looking for and get everything else. What is needed is a more refined search engine, or at least clearer instructions on how to narrow the search parameter to find what we are looking for.

[Kampfsanni]

15 hours ago, Nightmare said:

One thing i noticed that seems to have quit working right is auto dock.

When i set a dockingport for control from here it seems to mess up the axis and the ship never tries to dock with the port forward mostly 90 degrees to the side.

If you use the Mk2 Clamp-O-Tron, it is broken. It has it's controlpoint facing in the wrong direction, The bug is confirmed, so all we can do is to wait  for the next patch.

Edited July 3, 2021 by Kampfsanni

[Dominiquini]

When I try to rename some vessel in flight, the Mechjeb throw this exception:

KSP.log:

[EXC 16:00:58.534] Exception: Can't access internal member 'GUIUtility.systemCopyBuffer' it may have been removed / renamed
	MuMech.MuUtils.GetSystemCopyBufferProperty () (at <07394c03495949be9205a3c7a0b33845>:0)
	MuMech.MuUtils.get_SystemClipboard () (at <07394c03495949be9205a3c7a0b33845>:0)
	MuMech.MechJebCore.Update () (at <07394c03495949be9205a3c7a0b33845>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

Player.log:

Exception: Can't access internal member 'GUIUtility.systemCopyBuffer' it may have been removed / renamed
  at MuMech.MuUtils.GetSystemCopyBufferProperty () [0x00035] in <07394c03495949be9205a3c7a0b33845>:0 
  at MuMech.MuUtils.get_SystemClipboard () [0x00000] in <07394c03495949be9205a3c7a0b33845>:0 
  at MuMech.MechJebCore.Update () [0x00055] in <07394c03495949be9205a3c7a0b33845>:0 
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception, Object)
UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

* I was able to rename my vessel/probe successfully! I'm only reporting the exception...

Thanks.

[sarbian]

Uh, I guess I will have to find new ways to copy to the clipboard

[Dominiquini]

43 minutes ago, sarbian said:

Uh, I guess I will have to find new ways to copy to the clipboard

I forget to say, but the exception was when I try to paste a new name in the input text from the vessel (probe). But apart from the exception, everything seemed to work fine, so I think it's a very low priority bug!

Thanks.

[LittleBitMore]

Quick feature suggestion, if time permits: the ability to control the distance at which rovers stop near targets with the Rover Autopilot.

The reaosn why I'm using the Rover Autopilot is to make a simple AI for my battling robot. My main issue is, is that it always stops at 50m away from the decoy car target instead of ramming into it with its budget buzzsaw. This could be fixed with providing a box where you can type in how far away you want it to stop (in my case I'd want 0).

This would also fix an issue that may occur if a rover encounters a base with a radius larger than 50 meters.

Edited July 5, 2021 by LittleBitMore

[Dominiquini]

I find out some missing localizations:

#MechJeb_Future_AscentLandingSpaceplane_Title

#MechJeb_Future_AscentLandingSpaceplane_Description

Thanks

[maculator]

Is there a way to use somethin like this:

Spoiler

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[KerbalEVA],!MODULE[MechJebCore]]:Final
{    
    MODULE
	{
		name = MechJebCore
		MechJebLocalSettings 
		{
			MechJebModuleCustomWindowEditor			{unlockTechs = start}
			MechJebModuleSmartASS					{unlockTechs = start}
			MechJebModuleManeuverPlanner			{unlockTechs = start}
			MechJebModuleNodeEditor					{unlockTechs = start}
			MechJebModuleTranslatron				{unlockTechs = start}
			MechJebModuleWarpHelper					{unlockTechs = start}
			MechJebModuleAttitudeAdjustment			{unlockTechs = start}
			MechJebModuleThrustWindow				{unlockTechs = start}
			MechJebModuleRCSBalancerWindow			{unlockTechs = start}
			MechJebModuleRoverWindow				{unlockTechs = start}
			MechJebModuleAscentGuidance				{unlockTechs = start}
			MechJebModuleLandingGuidance			{unlockTechs = start}
			MechJebModuleSpaceplaneGuidance			{unlockTechs = start}
			MechJebModuleDockingGuidance			{unlockTechs = start}
			MechJebModuleRendezvousAutopilotWindow	{unlockTechs = start}
			MechJebModuleRendezvousGuidance			{unlockTechs = start}
		}
	}
}

 

 

to disallow modules from showing up in the mechjeb window? I really don't use all of its features an I'd like to declutter my UI. I googled how to prune or disable modules but that only lead me to dead and deleted threads. Any hint would be appreciated. =)

 

Edit:

I managed to do it:

Spoiler

@PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[KerbalEVA],!MODULE[MechJebCore]]:NEEDS[MechJeb2]
{
	%MODULE[MechJebCore]
	{
		%MechJebLocalSettings
		{
			%MechJebModuleSmartASS					{%showInFlight = False}
			%MechJebModuleNodeEditor				{%showInFlight = False}
			%MechJebModuleTranslatron				{%showInFlight = False}
			%MechJebModuleWarpHelper				{%showInFlight = False}
			%MechJebModuleAttitudeAdjustment		{%showInFlight = False}
			%MechJebModuleThrustWindow				{%showInFlight = False}
			%MechJebModuleRCSBalancerWindow			{%showInFlight = False}
			%MechJebModuleRoverWindow				{%showInFlight = False}
			%MechJebModuleSpaceplaneGuidance		{%showInFlight = False}
			%MechJebModuleRendezvousAutopilotWindow	{%showInFlight = False}
			%MechJebModuleAirplaneGuidance			{%showInFlight = False}
			%MechJebModuleFlightRecorder			{%showInFlight = False}
			%MechJebModuleSmartRcs					{%showInFlight = False}
			%MechJebModuleScript					{%showInFlight = False}
			
			%MechJebModuleCustomWindowEditor		{%unlockTechs = start}
			%MechJebModuleManeuverPlanner			{%unlockTechs = start}
			%MechJebModuleNodeEditor				{%unlockTechs = start}
			%MechJebModuleAscentGuidance			{%unlockTechs = start}
			%MechJebModuleLandingGuidance			{%unlockTechs = start}
			%MechJebModuleDockingGuidance			{%unlockTechs = start}
			%MechJebModuleRendezvousGuidance		{%unlockTechs = start}
		}
	}
}

 

Just in case anybody else has the same problem

Edited July 10, 2021 by maculator