Jump to content

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

r4m0n

By r4m0n
in KSP1 Mod Releases

 Share

Recommended Posts

Dazpoet

Dazpoet

Posted
Posted

I'll start this post out with saying I know absolutly nothing about programming and have only done minimal .cfg edits until now. Then I'll say how much I love this mod and how much it's helping me learn stuff by watching MJ do stuff and then trying it myself with that as guidance.

But now I have a problem which I think might be easy to solve, or it might be impossible for all that I know.

I'd like my probecores to have MJ built in from the get-go and to have the unlocks coming as usual. So flightcontrol is needed for the basic stuff up until advUnmanned for the tricky stuff. I have looked at .cfgs for probecores and the AR202 part and from I what I gather the files use some kind of module parameter to define the abilities of each part. Can I just add the MechJebCore module to a probecore config and it will work? That seems way to easy so I assume it's harder than that but that's why I'm here asking :) I'll show what I mean below.

Let's use the Stayputnik as an example since it seems to be the probecore with least text in the .cfg.

The standard config looks like this:

PART
{
name = probeCoreSphere
module = Part
author = NovaSilisko


mesh = model.mu
rescaleFactor = 1


CrewCapacity = 0


node_stack_bottom = 0.0, -0.3383468, 0.0, 0.0, 1.0, 0.0, 0


TechRequired = flightControl
entryCost = 1400
cost = 300
category = Pods
subcategory = 0
title = Stayputnik Mk. 1
manufacturer = Probodobodyne Inc
description = The Stayputnik offers the ultimate solution in crew safety. A lightweight sphere equipped with remote receivers and relay control input from the ground to the craft, it carries no crew at all, thus keeping them perfectly safe from all harm. This device does require electricity to operate however, and will cease to function if the power runs out. The built-in batteries should keep it going for about 10 minutes.


attachRules = 1,0,1,1,0


mass = 0.05
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.15
angularDrag = 1.5
crashTolerance = 12
maxTemp = 1200


explosionPotential = 0


vesselType = Probe




MODULE
{
    name = ModuleCommand
    minimumCrew = 0

    RESOURCE
    {
        name = ElectricCharge
        rate = 0.02777778
    }
}


RESOURCE
{
    name = ElectricCharge
    amount = 10
    maxAmount = 10
}


}

As per my assumption of how modules work I wonder if this variation would add MJ to the stayputnik.

PART
{
name = probeCoreSphere
module = Part
author = NovaSilisko


mesh = model.mu
rescaleFactor = 1


CrewCapacity = 0


node_stack_bottom = 0.0, -0.3383468, 0.0, 0.0, 1.0, 0.0, 0


TechRequired = flightControl
entryCost = 1400
cost = 300
category = Pods
subcategory = 0
title = Stayputnik Mk. 1
manufacturer = Probodobodyne Inc
description = The Stayputnik offers the ultimate solution in crew safety. A lightweight sphere equipped with remote receivers and relay control input from the ground to the craft, it carries no crew at all, thus keeping them perfectly safe from all harm. This device does require electricity to operate however, and will cease to function if the power runs out. The built-in batteries should keep it going for about 10 minutes.


attachRules = 1,0,1,1,0


mass = 0.05
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.15
angularDrag = 1.5
crashTolerance = 12
maxTemp = 1200


explosionPotential = 0


vesselType = Probe




MODULE
{
    name = ModuleCommand
    minimumCrew = 0

    RESOURCE
    {
        name = ElectricCharge
        rate = 0.02777778
    }
}

MODULE
    {
        name = MechJebCore
        MechJebLocalSettings {
            MechJebModuleCustomWindowEditor { unlockTechs = flightControl }
            MechJebModuleSmartASS { unlockTechs = flightControl }
            MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }
            MechJebModuleNodeEditor { unlockTechs = advFlightControl }
            MechJebModuleTranslatron { unlockTechs = advFlightControl }
            MechJebModuleWarpHelper { unlockTechs = advFlightControl }
            MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
            MechJebModuleThrustWindow { unlockTechs = advFlightControl }
            MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }
            MechJebModuleRoverWindow { unlockTechs = fieldScience }
            MechJebModuleAscentGuidance { unlockTechs = unmannedTech }
            MechJebModuleLandingGuidance { unlockTechs = unmannedTech }
            MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech }
            MechJebModuleDockingGuidance { unlockTechs = advFlightControl }
            MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned }
            MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned }
        }
    }



RESOURCE
{
    name = ElectricCharge
    amount = 10
    maxAmount = 10
}


}

Reading about this thing called modulemanager and looking at an example I saw somewhere it also seems I could make an MM file that would automagically add the MJ module to everything that is a probecore rather than hard-editing the changes into every probecore .cfg file. If so could I also use the same MM config to increase the power requirements and costs of probecores to what it would be with MJ mounted?

I expect I'm in way over my head here so please be gentle :)

Link to comment
Share on other sites
sarbian

sarbian

Posted
Posted (edited)

Do as I do when using humor : "(this is sarcasm for those whose detector is broken)"

:cool:

Edit since there was a reply while I was typing that one

Dazpoet : install the module manager DLL in gamedata, then create a text file named MJCommandPod.cfg and look into this post and paste one of the two config into that file. The first config will add Mechjeb on every pod and probe with all features unlocked even in career/science mode. The second one will do the same thing but with feature getting unlocked as you move thru the tech tree (keep in mind that some features need an upgraded tracking station building)

Edited by sarbian
Link to comment
Share on other sites
Dazpoet

Dazpoet

Posted
Posted

Dazpoet : install the module manager DLL in gamedata, then create a text file named MJCommandPod.cfg and look into this post and paste one of the two config into that file. The first config will add Mechjeb on every pod and probe with all features unlocked even in career/science mode. The second one will do the same thing but with feature getting unlocked as you move thru the tech tree (keep in mind that some features need an upgraded tracking station building)

Thank you for your answer! :)

I can just put the MJCommandPod.cfg directly into the gamedata folder I assume or is there some kind of folderlogic I should use to not make it crash with other mods? Say I want to perhaps make further future changes using MM configs can I then creata a folder in gamedata like /GameData/Dazpoetbreaksthegame/ and put the .cfg file there?

I tried reading up on the ModuleManager thread and it is... immense for someone not used to this stuff but it seems very powerful.

As I mentioned I kind of want this change to be only for probecores so I wonder if this would do that or if I'm just being silly.

[COLOR=#333333]@PART
[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]], [/COLOR]#vesselType[Probe]][COLOR=#333333]:Final[/COLOR]{    
    MODULE
    {
        name = MechJebCore
        MechJebLocalSettings 
        {
            MechJebModuleCustomWindowEditor { unlockTechs = flightControl }
            MechJebModuleSmartASS { unlockTechs = flightControl }
            MechJebModuleManeuverPlanner { unlockTechs = advFlightControl }
            MechJebModuleNodeEditor { unlockTechs = advFlightControl }
            MechJebModuleTranslatron { unlockTechs = advFlightControl }
            MechJebModuleWarpHelper { unlockTechs = advFlightControl }
            MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl }
            MechJebModuleThrustWindow { unlockTechs = advFlightControl }
            MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl }
            MechJebModuleRoverWindow { unlockTechs = fieldScience }
            MechJebModuleAscentGuidance { unlockTechs = unmannedTech }
            MechJebModuleLandingGuidance { unlockTechs = unmannedTech }
            MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech }
            MechJebModuleDockingGuidance { unlockTechs = advUnmanned }
            MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned }
            MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned }
        }
    } 
[COLOR=#333333]}[/COLOR]

I borrowed the vesseltype thing from the MM file in Starwasters probe-science mod, I hope that's not breaking a license or something? :S

Should I move over to the MM thread for future questions I will have for adding the extra electricity and cost to probecores?

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted

I borrowed the vesseltype thing from the MM file in Starwasters probe-science mod, I hope that's not breaking a license or something? :S

Should I move over to the MM thread for future questions I will have for adding the extra electricity and cost to probecores?

I am 69,105% positive that I creative commoned the crap out of that 'mod'.

Heck, I might as well have just public domained it, it's just some configs.

Do what you want with them and if they make you famous, mention me at your acceptance speech.

Or buy me some coffee and donuts or something.

Link to comment
Share on other sites
EdFred

EdFred

Posted
Posted (edited)

This thread is too big for me to search anymore, so I apologize if this has been covered.

I had d/l the newest MJ from Curse (2.4.1.0) and I am running .90 in KSP.

Whenever I turn on anything with MJ it now enables the stock SAS - and here's the issue, I have To manually select from maneuver/target/etc... in order to get MJ to work. Which makes my being lazy on launches quite annoying. It used to be click engage autopilot, hit space bar, and walk away, and I could come back to a nice orbit. Now I have to select target mode, or else it does some ridiculous flight path which usually ends up NOT making orbit even with a TWR>1.5 and 9000 dv. But I can't JUST select target mode. Then I have to watch my ascent until it establishes AP, and creates the circularize maneuver, and then I have to select maneuver from the stock SAS in order for it to fly right.

Anyone else having this issue?

Edit: Nevermind, during experimenting in a challenge I enabled Use Stock SAS under Attitude Adjustment.

I will leave my "duh" moment up in case anyone else has this issue.

Edited by EdFred
Link to comment
Share on other sites
teiichi

teiichi

Posted
Posted

I'm having two issues

when i have mechjep installed on something even if nothing is running all, autopilots... ect are off i cant use sas at all, it flash's on then turns right back off but on anything without mechjep it works just fine on the last version i used it only overrode the sas if mechjep was in use

the second problem i have which i believe is mechjep is i have an L shaped station (ala below in ascii) when i turn on rcs it spins faster and faster until it fly's apart. the rcs actively firing the wrong ones.

the station is made from three lifts, each with its own unmanned pod, i plan to expand quite a bit but cant as long as this is an issue

â•‘

â•‘

â• â•Ââ•Ââ•Ââ•Ââ•Â

â•‘

â•‘

â•‘

â•‘

â•‘

Any ideas?

Link to comment
Share on other sites
hakan

hakan

Posted
Posted

MechJeb build #395 from jenkins.mumech.com does not automatically open up the "Steam Solar Panels" from the Vertical Propulsion Emporium.

Craft is at http://kerbalx.com/hakan/Rescue%20Vessel%20III , the Streampunk addon is at [removed link to defunct website]

Do the panels have to be marked in a certain way to be recognized by MechJeb?

My pilot is a Level-0-Jebediah (has just been to the Mun as of yet) and I have unlocked the basic action groups.

Link to the save: https://dl.dropboxusercontent.com/u/3665320/MechJeb-SteamSolarPanels/persistent.sfs

Link to the craft: https://dl.dropboxusercontent.com/u/3665320/MechJeb-SteamSolarPanels/Rescue%20Vessel%20III.craft

Link to the log: https://dl.dropboxusercontent.com/u/3665320/MechJeb-SteamSolarPanels/KSP.log

Link to comment
Share on other sites
Meumeu

Meumeu

Posted
Posted
hakan said:
MechJeb build #395 from jenkins.mumech.com does not automatically open up the "Steam Solar Panels" from the Vertical Propulsion Emporium.

Craft is at http://kerbalx.com/hakan/Rescue%20Vessel%20III , the Streampunk addon is at [removed link to defunct website]

Do the panels have to be marked in a certain way to be recognized by MechJeb?

My pilot is a Level-0-Jebediah (has just been to the Mun as of yet) and I have unlocked the basic action groups.

Link to the save: https://dl.dropboxusercontent.com/u/3665320/MechJeb-SteamSolarPanels/persistent.sfs

Link to the craft: https://dl.dropboxusercontent.com/u/3665320/MechJeb-SteamSolarPanels/Rescue%20Vessel%20III.craft

Link to the log: https://dl.dropboxusercontent.com/u/3665320/MechJeb-SteamSolarPanels/KSP.log

They only have to be a ModuleDeployableSolarPanel, so they should work; but the autodeployment is not enabled by default anymore you have to enable it in the utilities window or in the ascent guidance.

Link to comment
Share on other sites
hakan

hakan

Posted
Posted

I am pretty sure that I activated that checkbox on the ascent autopilot :)

And from the part source:


...
MODULE
{
	name = ModuleDeployableSolarPanel
...

should be enough to make them a MDSP, right?

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted
They only have to be a ModuleDeployableSolarPanel, so they should work; but the autodeployment is not enabled by default anymore you have to enable it in the utilities window or in the ascent guidance.

ExtendAll() does a check against isBreakable and does not extend the panel if the result was false.

Link to comment
Share on other sites
Meumeu

Meumeu

Posted
Posted
ExtendAll() does a check against isBreakable and does not extend the panel if the result was false.

Yes, if you try to extend or retract a fixed solar panel, they will get stuck in the extending or retracting state and core.solarpanel.AllRetracted() will stay false and the ascent guidance won't switch to the vertical ascent phase. There's a retractable variable too but it is not set in any stock solar panel configuration file so I'm not sure what it does... I'll check with a debugger when I have the time to see which property should be checked (probably this evening)

Link to comment
Share on other sites
Twinkee

Twinkee

Posted
Posted

I'm having a weird problem... very unfortunately it's probably a mod confliction... but still worth asking about.

The steering part of mechjeb, eg SMARTass, doesn't like vessels with engines... I'm sure you can see my issue with that. Other symptoms show up with certain windows up... a NaN appears as the horizontal & vertical speeds as well as the altitude (True)... I haven't checked other variables.

The activate and control throttle part of mechjeb, eg execute node, does work... I have to aim at the node manually but the engine burns the correct amount of dV.

pressing t activates stock steering assist etc but clicking on a smartass function or execute node doesn't turn it off or take over.

NB same error with steering and altitude using curse release. the speeds thing is a symptom that appears when I use build 395.

edit: I just found that mechjeb 395 works just fine with the stock 909 engine and that physics-less off-angle monopropellant engine... Wierd... More might work, but I the 2.5m engines don't.

Link to comment
Share on other sites
Starwaster

Starwaster

Posted
Posted (edited)
Yes, if you try to extend or retract a fixed solar panel, they will get stuck in the extending or retracting state and core.solarpanel.AllRetracted() will stay false and the ascent guidance won't switch to the vertical ascent phase. There's a retractable variable too but it is not set in any stock solar panel configuration file so I'm not sure what it does... I'll check with a debugger when I have the time to see which property should be checked (probably this evening)

Just check its stateString field (or panelState). Fixed panels will always be EXTENDED. If it's not set to RETRACTED then it can't be extended anyway.

Or check its Extend / Retract events. If Extend is not active then the panel isn't extendable by the player. (and is either a fixed panel or in a broken or corrupted state and should be ignored anyway)

Edit:

Another possibility would be the animationName. If it doesn't have one set then it's not extendable anyway because it's not animated and should be ignored.

Edited by Starwaster
Link to comment
Share on other sites
smjjames

smjjames

Posted
Posted (edited)

Hey Sarbian, I've noticed what may just be a graphical bug with the arrows and the CoM. Sometimes (or maybe all the time?), when I have show arrows at CoM, it offsets it by a couple meters.

http://imgur.com/y3I7Sdo

Yes I'm buzzing the Mun at nearly 3km and yes I survived. The landing autopilot also has real trouble trying to land from a retrograde orbit (and angled at 165.5 degrees in my case), doesn't stop it from trying though.

Edit: Also, is it me or does sometimes clicking the edit post or even the go advanced make it go to the delete post screen?

Edit: Suggestion actually, maybe when it gets down to the 0.1 m/s or less course corrections, have it use RCS if available? When it gets to that point is about when it starts flailing around. Then again, I didn't put proper RCS nodes on and the only RCS is on the mk2 pod that I'm using.

Edit3: Actually, I think the problem might be that I'm trying to use those poodle engines to land on the Mun, which work well for Minmus, but not so much for the Mun.

Edited by smjjames
Link to comment
Share on other sites
smjjames

smjjames

Posted
Posted (edited)

This is a different craft though, but it shows the same problem.

Steps:

1. Launch to 200km orbit (because that's what I normally do). The CoM according to the arrows seems to slide downwards during gravity turn, but in Kerbin orbit, it's actually fine. Also, one of the SRBs probably will smash a winglet, but it'll be high enough and going fast enough that it's a non-issue.

2. Hohmann transfer to Mun.

3. Warp to SOI.

The arrows will be shifted off the CoM when you arrive, however, while warping, the arrows show where they should be, so it might shift earlier.

http://sta.sh/028gthbk9nal The ship is actually mostly stock.

Mods:

Mechjeb (obviously, plus the extensions, using devbuild 395)

KAS (not used in craft)

Procedural fairings (not used in craft)

B9 Aerospace (using the struts)

Dmagic science (latest version that supports stock biomes, also used in craft)

Universial storage (used in craft)

SCANsat (used in craft)

ATM

better buoyancy

FAR

Hangar mod (not used in craft)

KJR

CSS

Community Tech Tree

Techmanager

Stock Bug fix modules

Stock part revamp (textures only)

Nereids backup system

Smartstage

Also, as for the landing problems that I was having earlier, it was because of the weak poodle engines. After I put on the nuclear engine, it handled a retrograde landing just fine.

Edited by smjjames
Link to comment
Share on other sites
Galane

Galane

Posted
Posted

Anyone else having issues with Rendezvous Autopilot around Gilly or Moho?

I was attempting to see if an old failure of a Kethane lander for Duna (not efficient, could barely lift enough to make more fuel than it took for the trip down and back but was better than great for Ike, still have two of them there in my main save) would work with the lower gravity and no atmosphere of Moho.

Landing from 75km went perfectly. Liftoff to a 100km orbit also went perfectly.

What did not go anywhere close to anything remotely like perfectly was an attempt to rendezvous with the craft standing in for a transfer vehicle.

At EVERY part of the maneuver instead of correctly finishing the burn then warping to the next maneuver, Rendezvous Autopilot would instead drop the throttle to just off the bottom stop and point the engines at Moho while continuing to fire the engines at "idle".

This has been a problem in Rendezvous Autopilot and Maneuver Planner for a very long time and the smaller the orbit radius the worse it gets.

So far I've only done orbits around Kerbin, Mun, Minmus, Duna, Ike, Eve, Gilly and Moho - with "real" missions (not getting there with Hyperedit) to all of them except Moho. I do a lot of testing to develop the crafts then fly a full mission there and back to Kerbin. (I went to the moons of Kerbin before ever using Hyperedit.)

The Aim Engines at <body> and Idle Burn Instead of Properly Concluding Maneuver has for me been far as I remember next to nonexistent at Kerbin. It's happened some times at Mun and Duna. Don't recall it cropping up at Minmus. Never happened to me in Eve orbit.

Flight maneuvers around Gilly *required* quicksaving before every attempt at making any change because it was extremely likely it would go wrong in any way one could imagine. Even if I hyperedited two crafts into perfect equatorial orbits around Gilly, Rendezvous Autopilot would insist on doing at least two un-necessary plane changes. It would also often after doing a burn to change apopapsis as step 1 of changing to a higher orbit, decide that partway to the new apoapsis that it had to change it again. IIRC once it wanted to do that three times in a row instead of just raising apo, coasting to there then circularizing like it's bloody well supposed to do it before orbiting into phase for the Hohmann transfer.

Now in testing at Moho, with .25 this problem would crop up now and then but tonight in .90 with the latest dev build of Mechjeb it just wasn't possible to do a rendezvous. If I aborted the burn as soon as the lander began to twist its engines toward Moho then immediately re-enabled the autopilot it would begin the next maneuver - with added correction for its just prior screwup. But it would finish that maneuver by aiming the engines at Moho instead of cutting the throttle and orienting for the next burn.

So with fuel about to run out I gave up on the test. Might have been that saving before lifting off from Moho then F9-ing back to that *might* have knocked sense into its bits, but I was just wanting to get in *one* test run, not having to repeatedly save and reload to force it to limp along. I don't have a log, unless you really want 14 megabytes of accumulation because I didn't delete the old log because I did not expect such a spectacular failure to function, especially not after landing and ascent on and from Moho worked so well, in fact, the best of them I've ever had there.

What is the problem these parts of MechJeb have as the radius of the orbit gets smaller? Why is it flaking out by not correctly ending burns instead of doing what it is supposed to do? It's not due to a sluggishly turning craft, the lander I was using can flip 180 degrees in a couple of seconds.

Link to comment
Share on other sites
Meumeu

Meumeu

Posted
Posted
hakan said:
MechJeb build #395 from jenkins.mumech.com does not automatically open up the "Steam Solar Panels" from the Vertical Propulsion Emporium.

Craft is at http://kerbalx.com/hakan/Rescue%20Vessel%20III , the Streampunk addon is at [removed link to defunct website]

Do the panels have to be marked in a certain way to be recognized by MechJeb?

My pilot is a Level-0-Jebediah (has just been to the Mun as of yet) and I have unlocked the basic action groups.

That should be fixed in the latest dev build.

Thanks for the tip Starwaster.

Link to comment
Share on other sites
sarbian

sarbian

Posted
Posted (edited)

2. Hohmann transfer to Mun.

Oh. I think I see what's wrong. I'm either missing or adding too much velocity from a mun around its parent.

Edit : fixed. it was actually only a display problem. Other change by Bloodyrain2k went in too (ascent AP auto profile tuning, lot of improvements to the rover AP)

Edited by sarbian
Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...