Jump to content

Ph34rb0t

Members
 View Profile  See their activity

  • Posts

    226

  • Joined

  • Last visited

 Content Type 

Posts posted by Ph34rb0t

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

    in KSP1 Mod Releases

    Posted

    Hmm, that's weird. I haven't checked, but maybe the Stock BugFix Module has something to fix it?

    I already have SBFM installed.

    Maybe it's the source for some problems...?

    In any case, I got that config file from hazens1, once I asked a similar question here. So, kudos go for him. :)

    In that case, thanks to you both. :D

    Ph34rb0t : do you have the "use stock SAS" enabled in the attitude control window ? If yes then try without it.

    I'd sure like to know why this turn on by default for some...

    I've tried it with or without "Use stock SAS". It doesn't make a difference. But Mechjeb doesn't seem to be the culprit as I also get this behaviour whitout MJ being installed at all.

    What about implementing a single SAS toggle cycle into the Ascent AP whenever the "Engage Autopilot" button is pressed?

    It wouldn't harm people who do not have this problem, but it would provide an easy fix for those who have.

    - - - Updated - - -

    - Edit:

    It seems to be caused by AFBW 1.4.4!

    http://forum.kerbalspaceprogram.com/threads/95022-0-90-AFBW-v1-4-6-%28Joystick-controller-mod-SAS-bug-fixed!%29?p=1639637&viewfull=1#post1639637

    Well, case closed, I guess. Sorry for the stir-up here!

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

    in KSP1 Mod Releases

    Posted

    I've disabled every mod that could influence on flight behaviour or auto-flight (including MJ) and still get SAS-like behaviour after starting a flight, but without an illuminated SAS indicator. Pressing "T" once does nothing visually, pressing "T" a second time puts me into default SAS mode.

    Must be a stock bug after all...

    Can I assume you have the latest version of MM?

    Yup. 2.5.6.

    Your config is much nicer than mine, so it's time for an upgrade, I guess. Thanks for posting it! :)

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

    in KSP1 Mod Releases

    Posted · Edited by Ph34rb0t

    Ah, I think I have the source for the weird SAS behaviour pinpointed: Pilot Assistant.

    It does enforce its own stablization algorithm by default and subsequently clashes with Mechjeb.

    Nope, it wasn't Pilot Assistant. This is still happening.

    Does MechJeb clash with 0.90's pilot experience stuff?

    I'm also not using the cumbersome AR202, but a MM config file that adds MJ to any "command" type part.

    My test vessel from the sceenshots also "only" uses a probe core.

    The MM config file looks like this and has been working perfectly until...well, I don't know...the 0.90 upgrade?

    @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final

    {

    MODULE

    {

    name = MechJebCore

    }

    }

    [0.25] RasterPropMonitor - putting the A in your IVA (v0.18.3) [8 Oct]

    in KSP1 Mod Releases

    Posted

    CKAN has version 18.3 sans the ModuleManager patches for the stock command pods, so it needs to be manually updated with MoarDV's .dlls and the patches from Mihara's regular pack.

    Hmm.. now I think of it, this is probably because https://raw.githubusercontent.com/Mihara/RasterPropMonitor/master/GameData/JSI/RasterPropMonitor/RasterPropMonitor.version (i.e. the remote url than AVC checks against for updates) still reads 0.25 and only Mihara can change that. Changing the .version file only changes what version it supports which is different to saying there's an update available. My mistake, I didn't realise RPMs .version file was that robust.

    Ah, that actually makes sense.

    [0.25] RasterPropMonitor - putting the A in your IVA (v0.18.3) [8 Oct]

    in KSP1 Mod Releases

    Posted

    Oh, I forgot to mention I'm using CKAN... and that's not giving me an update. I'm confused, is there an updated .dll? Should I be installing a dev version manually?

    The version from CKAN does not include the patches for the default pods. You'll have to install them manually (just the "RPMPodPatches" folder). I found that out the hard way.

    You can change the .version file yourself to include 0.90, but I like to keep it there to remind me that I need to update it or I'd forget otherwise.

    That doesn't work for me. RasterPropMonitor.version reads

    "KSP_VERSION": {

    "MAJOR":0,

    "MINOR":90,

    "PATCH":0

    }

    and KSP still complains.

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

    in KSP1 Mod Releases

    Posted · Edited by Ph34rb0t

    See my edit, I didn't even realize that it did that til now, somehow, lol XD

    Well you ninja'd me. :)

    - Edit:

    I've tried to take a peek into the debug menu and output_log.txt to see if I can find something related to MechJeb there, but without any success.

    If this bug isn't caused by another installed mod, can't Mechjeb simply be made to automatically toggle SAS on and off in future versions as a safety measure?

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

    in KSP1 Mod Releases

    Posted · Edited by Ph34rb0t

    Without tapping "T":

    http://i.imgur.com/eaosclK.png

    With tapping "T":

    http://i.imgur.com/taR1V51.png

    Modlist (only those including .dlls or relevant to MJ):

    Toolbar

    AJE

    BDAnimation

    Chatterer

    CIT - BAM

    CIT - Govfunding

    DDSLoader

    DeadlyReentry

    DistantObject

    DMagic Orbital Science

    EditorExtensions

    EnvironmentalVisualEnhancements

    FerramAerospaceResearch

    FinalFrontier

    Firespitter - DLL

    FirstPersonEVA

    FreeEVA

    HullCameraVDS

    JSI - RPM

    KAS

    KerbalConstructionTime

    KerbalIspDifficultyScaler

    KerbalJointReinforcement

    NavInstruments

    KerbQuake

    Klockheed_Martian_Gimbal

    ksp-advanced-flybywire

    KSP-AVC

    KSPAPIExt

    MechJeb2

    Mechjeb - KMGimbal3

    Mechjeb - FAR

    Mechjeb - RPM

    Mechjeb_Command_Pods.cfg

    ModuleManager.2.5.6.dll

    NavBallDockingAlignmentIndicator

    Pilot Assistant

    PlanetShine

    ProbeControlRoom

    ProceduralFairings

    ProceduralParts

    RealChute

    S.A.V.E.

    SCANsat

    ScienceAlert

    ShipManifest

    SmokeScreen

    Snacks

    StageRecovery

    StockBugFixModules

    TextureReplacer

    Trajectories

    KerbalAlarmClock

    Landertron

    - Edit:

    Regarding the solar panels: The autodeployment stopped after I disabled the option in the Ascent Autopilot. The panels would deploy whether I had the AG AP enabled or not.

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

    in KSP1 Mod Releases

    Posted · Edited by Ph34rb0t

    Does anyone else have problems with the Ascent Guidance mode and gravity turns?

    I'm using dev build 385 with FAR 14.6 and the latest MJ FAR plugin build.

    The rocket will only start its gravity turn after I hit the "T" (SAS) key while the AG autopilot is engaged. This makes the "SAS" icon flash for a split second and after that, everything works as it should.

    Without hitting the "T" key, the rocket will do a vertical ascent and then simply pick up its entire orbital velocity near the apoapsis.

    It's almost as if MJ is fighting against SAS for control unless I intervene...

    - Edit:

    Does MJ automatically check for stage deltaV and can it override user input into AG mode if it detects that a weak stage sould better be fired outside of the atmosphere?

    [1.1] AFBW v1.7-beta (Joystick & controller mod)

    in KSP1 Mod Releases

    Posted · Edited by Ph34rb0t

    Confirming extreme slowdowns with 1.4.5 when the configuration menu is open. KSP 0.90 x86, Win 7. Also, my controller's (Top Gun Fox 2 Pro Shock) coolie hat isn't recognized anymore.

    Reverting to version 1.4.4 breaks my config file. I can reinstate a backup from 1.4.5, but it will be wiped clean as soon as I enter a flight scene.

    Can you make the config file handling a bit more robust?

    Also, there are cases in 1.4.4 and 1.4.5 in which the movement (or dead zone) of my throttle slider is not correctly recognized. Throttling up works, but after throttling down into the dead zone makes the ship throttle up again after a few seconds. I have to fight the input with repeated "throttle down" movements.

    Scratch that, it was hardware related.

    I'm not sure if this has always been broken or if this is a new bug, but I'm only noticing now that the available dead zone settings actually don't make any sense for a throttle slider. You'd need a user-adjustable zone extending from 1.0 toward 0.0 and a zone from -1.0 to 0.0 and not a zone from 0 to 1.0 and 0 to -1.0. After all, what use is a dead zone smack dab in the middle of the slider?

    I mean, it could be useful for, say, enabling translation forward or backward in docking or EVA mode (by moving the slider forward or backward from a safe middle position) or for use with gamepad sticks, but it surely isn't useful for throttling a ship's engine with a throttle slider on a flightstick.

    As a workaround, I can set my positive deadzone to 0.99999 for now and only use the upper 50% of the slider, but this isn't very useful for precise throttle settings.

    I'd appreciate if there could be a possibility to mark an axis with "Is slider" or "no center position" in future versions and have an appropriate dead zone handling.

×
×
  • Create New...