[PART, 1.0.2] Anatid Robotics / MuMech - MechJeb - Autopilot - Historical thread

[sarbian]

skips : good catch. Can you make a ticket on github ? I m going away for ~10 days and I don't want to forget it.

[Starwaster]

I only added onality.

Edited August 17, 2014 by Starwaster

[sarbian]

I forgot to mention it but I fixed that toolbar problem in the last dev build.

[The_Duck]

[suggestion][Request]

Can you please add a per-stage 'Empty Mass' field somewhere?

Currently the only 'Empty Mass" field I see is on the vessel-info, and it's for the whole vessel. I think a per-stage version would be very useful for various calculations, including but not limited to setting up parachutes for the safe recovery of spent stages; Be it by pure fantasy or with actual importance by using mods such as the aptly named "Stage Recovery" mod.

I guess this would be most appropriate in the "Delta-V Stats" window, since it already has the framework for "per-stage stuff" set up...But if you think that window is already cluttered, anywhere is fine, as long as it's there...

If you press the "All stats" button in the "Delta-V Stats" window a couple of times a "final mass" column should appear, which is at least related to what you want. You can then remove any columns you don't want by clicking on the column header.

Edited August 18, 2014 by The_Duck

[Wanderfound]

I dug a fair way back in the thread, but I couldn't see anything new on this: has there been any progress on the gimballing roll issue?

I miss my reentry cruise control...

[sarbian]

I spent most of sunday working on it. Adding a quick hack for the roll is easy but I wanted to cleanup and improve the whole torque from engine code.

I hit a problem with my math (most likely a World/Local conversion error) and did not find what I did wrong after 2 hours. I don't want to push worse code to the dev version so it will stay on my PC for now, and will have to wait next week since I'll visit my family starting tomorrow.

Most likely next week I'll find my mistake in a couple of minutes and curse myself for not seeing the obvious

[Wanderfound]

I spent most of sunday working on it. Adding a quick hack for the roll is easy but I wanted to cleanup and improve the whole torque from engine code.

I hit a problem with my math (most likely a World/Local conversion error) and did not find what I did wrong after 2 hours. I don't want to push worse code to the dev version so it will stay on my PC for now, and will have to wait next week since I'll visit my family starting tomorrow.

Most likely next week I'll find my mistake in a couple of minutes and curse myself for not seeing the obvious

Thank you thank you thank you; muchas gracias.

Enjoy your family visit, if that's a thing that's possible.

[dtoxic]

Mechjeb dev 287 ksp x86 24.2

MechJeb moduleRegistry creation threw an exception in LoadComputerModules loading InfernalRobotics, Version=0.18.4.0, Culture=neutral, PublicKeyToken=null: System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.

at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)

at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0

at MuMech.MechJebCore.LoadComputerModules () [0x00000] in <filename unknown>:0

[seanth]

I've been having an odd problem with mechjeb, and I'm not sure whether it is something I am doing wrong, or an odd bug.

I have a craft I want to put into polar orbit, so I set the orbital inclination to 90. During launch and gravity turn, the rocket arcs to the north as expected. The engines shut down as the craft coasts up to apoapsis. But when mechjeb makes the maneuver node, the resulting orbit is nearly equatorial. Defining a orbital inclination of 120 results in a orbit that looks about 45 degrees off the equator.

Worse, mechjeb worked flawlessly once in putting something into a polar orbit, but has screwed up every time since.

Anyone else experience this? What should I provide to help chase this problem down?

[sarbian]

Mechjeb dev 287 ksp x86 24.2

MechJeb moduleRegistry creation threw an exception in LoadComputerModules loading InfernalRobotics, Version=0.18.4.0, Culture=neutral, PublicKeyToken=null: System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.

at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)

at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0

at MuMech.MechJebCore.LoadComputerModules () [0x00000] in <filename unknown>:0

Ask InfernalRobotics dev if the dll was build with .NET 3.5 and not 4. It's not a MJ problem.

[dtoxic]

Ask InfernalRobotics dev if the dll was build with .NET 3.5 and not 4. It's not a MJ problem.

i found the problem i was missing one scale_redist.dll that was causing the problem

[The_Duck]

OK, I think this will do the job. [...]

Essentially has the same glitch as the bigger ship. The dV readout works fine until the first staging (side boosters), then stops registering any dV changes.

Thanks for the nice test case. Should be fixed in dev build #288.

[BARCLONE]

Duck,

Glad the craft file worked. I was watching a couple of other ships with strap-on solids, and did not get the problem to show up, but as soon as I used liquids with cross-feed lines, that's when the problem developed. I think the problem was confined to the fuel line.

Installed 288 this morning, and the problem has gone away. Thanks to both of you.

[Starwaster]

I've been having an odd problem with mechjeb, and I'm not sure whether it is something I am doing wrong, or an odd bug.

I have a craft I want to put into polar orbit, so I set the orbital inclination to 90. During launch and gravity turn, the rocket arcs to the north as expected. The engines shut down as the craft coasts up to apoapsis. But when mechjeb makes the maneuver node, the resulting orbit is nearly equatorial. Defining a orbital inclination of 120 results in a orbit that looks about 45 degrees off the equator.

Worse, mechjeb worked flawlessly once in putting something into a polar orbit, but has screwed up every time since.

Anyone else experience this? What should I provide to help chase this problem down?

Nope. If I tell MJ2 to do a polar orbit a polar orbit is what I get.

Maybe provide full details of your ascent profile (all numbers) though honestly, if it's heading north then it shouldn't even be possible to get anything remotely resembling an equatorial orbit. Even if you did a +Normal burn at your circularization point at best you'd get maybe 45 degrees. And it would be incredibly wasteful actually getting an orbit out of it.

[Ruedii]

Nope. If I tell MJ2 to do a polar orbit a polar orbit is what I get.

Maybe provide full details of your ascent profile (all numbers) though honestly, if it's heading north then it shouldn't even be possible to get anything remotely resembling an equatorial orbit. Even if you did a +Normal burn at your circularization point at best you'd get maybe 45 degrees. And it would be incredibly wasteful actually getting an orbit out of it.

I recommend doing polar orbits a few degrees off of 90 degrees anyway. Running them straight over the pole creates an inefficiency in scanning. If you are using something like ScanSat, you want the orbit inclination to be a little over 90-(FOV/2)

[Starwaster]

I recommend doing polar orbits a few degrees off of 90 degrees anyway. Running them straight over the pole creates an inefficiency in scanning. If you are using something like ScanSat, you want the orbit inclination to be a little over 90-(FOV/2)

Thank you for your opinion.

[Doctor Lag]

Does anybody know how to modify MJ to have all the modules enabled as soon as you unlock the first part? I tried editing the AR202 part.cfg to change the "TechRequired" lines and all the "unlockTechs" in the MechJebLocalSettings to be "flightControl", which is where the first part is unlocked by default. It seemed to bug out a bit though - it showed 6 different MJ parts that needed to be purchased in the research center, but buying them doesn't seem to do anything and when I go back to the research center it shows 5-6 more parts to buy... This is clearly not the Right Thing. This was with a fresh savegame started after making the MJ edits btw.

So, does anybody know the secret trick to getting this to work? I like the idea of career mode and I love building ships, but I find flying them to be just tedious.

[Starwaster]

Does anybody know how to modify MJ to have all the modules enabled as soon as you unlock the first part? I tried editing the AR202 part.cfg to change the "TechRequired" lines and all the "unlockTechs" in the MechJebLocalSettings to be "flightControl", which is where the first part is unlocked by default. It seemed to bug out a bit though - it showed 6 different MJ parts that needed to be purchased in the research center, but buying them doesn't seem to do anything and when I go back to the research center it shows 5-6 more parts to buy... This is clearly not the Right Thing. This was with a fresh savegame started after making the MJ edits btw.

So, does anybody know the secret trick to getting this to work? I like the idea of career mode and I love building ships, but I find flying them to be just tedious.

Try it again with a fresh save.

If it works then you probably have corrupted your save file by editing tech requirements for parts that it already had awareness of.

The fix would involve editing that save file and deleting any MJ items from the ResearchAndDevelopment SCENARIO node. Look for that and then inside each of the tech nodes, look for part = mumech.MJ2.AR202 and delete them. Just nuke them all and then restart the game.

(or if you're editing quicksave.sfs then you can just F9 to reload it after editing it and saving it)

[Doctor Lag]

From my post: "This was with a fresh savegame started after making the MJ edits btw". I deleted everything in the saves folder and started new. I think I tried 3 ways of editing it (changing only the modules, changing only the parts, and changing both) and started fresh each time with no savegame editing at all.

I'm not aware of anything else that would need to be cleaned out, but please advise me if there is because it certainly did look like a glitched save.

Edit: Tried it again to make sure I wasn't hallucinating. Backed up part.cfg, edited all the tech to be flightControl, deleted my save folder and started fresh. Same result.

Edited August 22, 2014 by Doctor Lag

[Starwaster]

From my post: "This was with a fresh savegame started after making the MJ edits btw". I deleted everything in the saves folder and started new. I think I tried 3 ways of editing it (changing only the modules, changing only the parts, and changing both) and started fresh each time with no savegame editing at all.

I'm not aware of anything else that would need to be cleaned out, but please advise me if there is because it certainly did look like a glitched save.

Let me play with it for a bit and see if I can work it out.

[Kobymaru]

This might not be a MechJeb related question, but maybe someone can help me understand:

The orbital parameter "Argument of Periapsis" is a constant parameter to describe an orbit. When I timewarp, it does remain constant. But when I don't (so physics are calculated), it seems to drift! When Orbiting Kerbin, it goes up (or down) by about 0.1 °/s. I thought it was the usual floating point/phisycs vibration stuff, but it appears to not be oscillating but steadily rising/falling. Is that normal? Did I misunderstand something?

Also, another question:

I tried to understand what the "Longitude of Ascending Node" is. Google tells me, that this is the angle of the Ascending Node to a "reference direction". On earth, this reference direction is the "vernal equinox". Whatever the hell that is I did not understand, but what I did understand was that it is somehow related to earths inclination. But Kerbin does not have an inclination! So how does MechJeb calculate the LAN and what is this reference direction?

Please send help, I am confuse.

[The_Duck]

The orbital parameter "Argument of Periapsis" is a constant parameter to describe an orbit. When I timewarp, it does remain constant. But when I don't (so physics are calculated), it seems to drift! When Orbiting Kerbin, it goes up (or down) by about 0.1 °/s. I thought it was the usual floating point/phisycs vibration stuff, but it appears to not be oscillating but steadily rising/falling. Is that normal? Did I misunderstand something?

I'm guessing that when you see this your orbit is very close to circular. For circular orbits the position of periapsis is not well defined, and for near-circular orbits the position of periapsis will be very sensitive to small perturbations to the orbit. So probably what you're seeing is physics integration errors + near-circularity.

I tried to understand what the "Longitude of Ascending Node" is. Google tells me, that this is the angle of the Ascending Node to a "reference direction". On earth, this reference direction is the "vernal equinox". Whatever the hell that is I did not understand, but what I did understand was that it is somehow related to earths inclination. But Kerbin does not have an inclination! So how does MechJeb calculate the LAN and what is this reference direction?

KSP uses a fixed but arbitrary direction as the reference direction. I don't think there's anything special about it. It seems to point roughly opposite the center of the galaxy in the stock skybox. You can determine the reference direction for yourself by setting up an orbit with LAN=0. Then the ray from the center of the planet to the ascending node will point along the reference direction.

Edited August 22, 2014 by The_Duck

[undercoveryankee]

This might not be a MechJeb related question, but maybe someone can help me understand:

The orbital parameter "Argument of Periapsis" is a constant parameter to describe an orbit. When I timewarp, it does remain constant. But when I don't (so physics are calculated), it seems to drift! When Orbiting Kerbin, it goes up (or down) by about 0.1 °/s. I thought it was the usual floating point/phisycs vibration stuff, but it appears to not be oscillating but steadily rising/falling. Is that normal? Did I misunderstand something?

Also, another question:

I tried to understand what the "Longitude of Ascending Node" is. Google tells me, that this is the angle of the Ascending Node to a "reference direction". On earth, this reference direction is the "vernal equinox". Whatever the hell that is I did not understand, but what I did understand was that it is somehow related to earths inclination. But Kerbin does not have an inclination! So how does MechJeb calculate the LAN and what is this reference direction?

Please send help, I am confuse.

Argument of periapsis drift is due to game inaccuracies. In an exact 2-body orbit it would be constant. Some systematic bias is possible depending on how forces and errors interact with each other in your ship, but the only way MechJeb would be contributing is if RCS was firing for attitude control and you didn't know it.

Regarding LAN, the equinox reference direction is where Earth's equator crosses Earth's orbital plane. In KSP, where the equator and the orbital plane coincide, there's no clear "physical" reference for the zero direction, but there are coordinates that the game uses internally. Zero celestial longitude is probably "the direction Kerbin's prime meridian points at the epoch". MechJeb gets position information from the game in the coordinates the game uses and reports your LAN relative to the game's zero direction.

[undercoveryankee]

I'm guessing that when you see this your orbit is very close to circular. For circular orbits the position of periapsis is not well defined, and for near-circular orbits the position of periapsis will be very sensitive to small perturbations to the orbit. So probably what you're seeing is physics integration errors + near-circularity.

AgP is also counted from the ascending node, so if your inclination is close enough to zero that the position of the ascending node is not well defined, any drift in that calculation will also show up in the number that gets reported for AgP.

[skips]

Does anybody know how to modify MJ to have all the modules enabled as soon as you unlock the first part?

I use ModuleManager.2.2.0 and a custom made configuration file.

/////////////////////
//   change the technology requirements for MechJeb 
/////////////////////
@PART[*]:HAS[@MODULE[MechJebCore]]
{
	// delete any existing MechJebCore modules //
	!MODULE[MechJebCore] { }

	// insert MechJeb module with revised tech tree assignments//
	MODULE
	{
		name = MechJebCore
        MechJebLocalSettings {
		    MechJebModuleCustomWindowEditor { unlockTechs = basicRocketry }
            MechJebModuleSmartASS { unlockTechs = flightControl }
            MechJebModuleManeuverPlanner { unlockTechs = advRocketry }
            MechJebModuleNodeEditor { unlockTechs = advRocketry }
            MechJebModuleTranslatron { unlockTechs = fuelSystems }
            MechJebModuleWarpHelper { unlockTechs = generalRocketry }
            MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
            MechJebModuleThrustWindow { unlockTechs = basicRocketry }
            MechJebModuleRCSBalancerWindow { unlockTechs = fuelSystems }
            MechJebModuleRoverWindow { unlockTechs = fieldScience }
            MechJebModuleAscentGuidance { unlockTechs = generalRocketry }
            MechJebModuleLandingGuidance { unlockTechs = generalRocketry }
            MechJebModuleSpaceplaneGuidance { unlockTechs = aerodynamicSystems }
            MechJebModuleDockingGuidance { unlockTechs = specializedConstruction }
            MechJebModuleRendezvousAutopilotWindow { unlockTechs = specializedConstruction }
            MechJebModuleRendezvousGuidance { unlockTechs = specializedConstruction }
		}
	}

}

@PART[mumech_MJ2_AR202]
{
	@TechRequired = basicRocketry
}

/////////////////////
//   Add MechJeb to the probe cores
/////////////////////
@PART[*]:HAS[#vesselType[Probe],#category[Pods],!MODULE[MechJebCore]]
{
	// insert MechJeb module with revised tech tree assignments//
	MODULE
	{
		name = MechJebCore
        MechJebLocalSettings {
		    MechJebModuleCustomWindowEditor { unlockTechs = basicRocketry }
            MechJebModuleSmartASS { unlockTechs = flightControl }
            MechJebModuleManeuverPlanner { unlockTechs = advRocketry }
            MechJebModuleNodeEditor { unlockTechs = advRocketry }
            MechJebModuleTranslatron { unlockTechs = fuelSystems }
            MechJebModuleWarpHelper { unlockTechs = generalRocketry }
            MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
            MechJebModuleThrustWindow { unlockTechs = basicRocketry }
            MechJebModuleRCSBalancerWindow { unlockTechs = fuelSystems }
            MechJebModuleRoverWindow { unlockTechs = fieldScience }
            MechJebModuleAscentGuidance { unlockTechs = generalRocketry }
            MechJebModuleLandingGuidance { unlockTechs = generalRocketry }
            MechJebModuleSpaceplaneGuidance { unlockTechs = aerodynamicSystems }
            MechJebModuleDockingGuidance { unlockTechs = specializedConstruction }
            MechJebModuleRendezvousAutopilotWindow { unlockTechs = specializedConstruction }
            MechJebModuleRendezvousGuidance { unlockTechs = specializedConstruction }
		}
	}
}

If you remove the section that is referred to as "Add MechJeb to the probe cores", it will move the features to more accessible nodes and the MJ2_AR202 part to the first researchable node. You can achieve your goal of making all of the MechJeb modules available by editing the unlockTechs to all equal basicRocketry.

skips