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

[Brigadier]

@ColdJ I believe he wants TWR controlled dynamically by MJ, in the same way that acceleration or dynamic pressure can be set as a limit.  Making a static change in the VAB is not what he's asking for since TWR will continue to increase with fuel burn after launch.

[rmaine]

46 minutes ago, Brigadier said:

@ColdJ I believe he wants TWR controlled dynamically by MJ, in the same way that acceleration or dynamic pressure can be set as a limit.  Making a static change in the VAB is not what he's asking for since TWR will continue to increase with fuel burn after launch.

That's what I previously mentioned as the difference of substance between limiting TWR and thrust. I just don't think it worth cluttering things up with a separate option. I won't argue further, though. My opinion might (or might not) be useful; argument certainly isn't.

[Brigadier]

8 minutes ago, rmaine said:

That's what I previously mentioned as the difference of substance between limiting TWR and thrust. I just don't think it worth cluttering things up with a separate option. I won't argue further, though. My opinion might (or might not) be useful; argument certainly isn't.

Oh, absolutely!  I agree with you and believe what the OPer wants can be accomplished with existing functionality.   I was pointing out that the suggestion provided by ColdJ didn't address the original request's intent, at least in my opinion.

[vipAvoS]

6 hours ago, Brigadier said:

@ColdJ I believe he wants TWR controlled dynamically by MJ, in the same way that acceleration or dynamic pressure can be set as a limit. Making a static change in the VAB is not what he's asking for since TWR will continue to increase with fuel burn after launch.

You understood me absolutely correctly. This is exactly what I was talking about.
======
And another question not related to MJ.
Can you please tell me in which thread of the forum I can ask that, for example, stabilizers are attached to the case at a certain angle, and not perpendicularly? and how can this be fixed?
Thanks.

[ColdJ]

On 11/4/2021 at 9:08 PM, vipAvoS said:

Hello.
I would like to propose to add a TWR limitation clause to Ascent Guidance.
Is it possible to do this?
Thanks.

 

On 11/5/2021 at 10:35 AM, Brigadier said:

Not sure why you'd want this since isn't it basically an acceleration limit, which already exists?

 

On 11/5/2021 at 11:33 AM, vipAvoS said:

Example:
My first stage has TWR == 2.3
MechJeb immediately uses full thrust, but I need TWR to be no more than 1.8

 

On 11/5/2021 at 3:00 PM, Starwaster said:

It's already in there. Enable the box next to 'Limit acceleration to' and in the text entry box next to that, enter a value of 17.676

 

17 hours ago, vipAvoS said:

Thank you very much!
Only, excuse me, I would prefer to set the TWR limitation, and not the acceleration limitation.
Moreover, these two parameters are completely non-intuitive in relation to each other.
Sorry if that. But I'm just learning))) And "thrust-to-weight ratio" and "acceleration" are completely different concepts for me ...
Sorry if that is.
Thanks.

 

17 hours ago, ColdJ said:

They have showed you how to stop MechJeb from using full thrust. Otherwise, yes they are different things.

Sorry, just add to that. Your TWR is based on the physical properties of your craft, mass vs the maximum thrust. MJ can't change your mass but it can limit how much thrust it uses. You could do this yourself by manually adjusting the thrust limiter on your engines.

 

16 hours ago, Starwaster said:

They really aren't (different in concept), unless you launch from a different planetary body with a different gravitational constant. So then you have to use a different value when setting up your launch profile.

^^^^^^ THIS ^^^^^^^^^^^^

The UI is already too crowded and there's been way too much feature creep over the past few years.

There's already a way to limit by TWR that just requires some simple math and does the same thing

If having a TWR limiter is your only reason for using MJ then you should do without MJ.

And I apologize for being overly blunt but the statement stands.

 

14 hours ago, ColdJ said:

Who said you had to stop using MechJeb if you manually adjust the thrust limiters when building your craft? It is "Thrust To Weight Ratio" If you limit your thrust then you lower your TWR and then you don't need to adjust MechJeb. When you build there is a button along the bottom that allows you to choose what info to show. It is the Delta V button. If you have TWR ticked then right click on the orange part of the staging list and it will slide open to show your current figures. Adjust your limiters and the TWR will change accordingly, so you can work out how much to change it.

@vipAvoS @rmaine@Brigadier

Hi all. vipAvoS, You have stated that you are new at this and so may be confusing some concepts. @Starwaster gave you the best option as by limiting the craft acceleration and velocity, you are by default affecting the TWR because throttling back is infact lowering the thrust. As you seemed not satisfied by that answer, I gave you an alternative where you could lower the thrust to weight ratio without having to then go and adjust MechJeb. MechJeb would as before use full thrust, but as you had limited the thrust it would not be using the full 2.3 potential of your design. If none of this works for the way you are framing it in your mind, it may be better to practice with your craft in a sandbox game, resetting to launch each time it goes wrong and learning till you get the feel of it. All truly satisfying games have a learning curve, and it feels good when you master it. MechJeb is best for automating drudge work, your mind will always end up being better at the intuitive stuff if you give yourself a chance. The simplest example I can think of is. You can't learn how to drive a car in a car that drives itself but if you practice in a proper car till you get it right and feel confident then it feels great.

As to angles when you attach pieces. Bottom left their are options to go from snap to angle to free rotate. Hexagon for snap, circle for free. There is also mirror, The square or radial the dot. Top left are your move and rotate controls, they are affected by the snap or free setting, so if you have a particular angle you want, set it to free, use the move to get it where you want and then the rotate to get the angle you want. Hope this helps.

[vipAvoS]

Thanks everyone for the answers. I will practice

48 minutes ago, ColdJ said:

......

As to angles when you attach pieces. Bottom left their are options to go from snap to angle to free rotate. Hexagon for snap, circle for free. There is also mirror, The square or radial the dot. Top left are your move and rotate controls, they are affected by the snap or free setting, so if you have a particular angle you want, set it to free, use the move to get it where you want and then the rotate to get the angle you want. Hope this helps.

I knew about it, but I turned out to be inattentive to this "trifle"! Alignment turned off ...
Many thanks!!!

Edited November 6, 2021 by vipAvoS

[ruiluth]

I'm having an issue with the maneuver planner. "Every time I try to use the advanced transfer to another planet" function, my game crashes. This time, my log ended with this:

Spoiler

[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [256.37204227749, 2270.81426896389, 3.99531974897448] vpos = [3909.64100908249, 15.3146648808119, -56.1505047130874] r = [673771.944179028, -76172.7109547385, 24.620816993687] dt = 722.377336096599
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [420.209766459879, -2233.99364411625, -3.7742085200415] vpos = [3745.97222487955, -1073.68387670496, -220.347813067519] r = [-669997.440083268, -125578.889008073, -373.41402200579] dt = 1748.70063493049
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [232.354307560002, -2261.16225466519, -3.86496991055876] vpos = [3757.56790198671, -981.721567149566, -387.433200074354] r = [-678153.446875628, -69396.2662694653, -277.935879520892] dt = 1723.71817158341
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [397.839993076804, -2238.07105030028, -3.78647599784424] vpos = [3747.75577331898, -1065.32639470239, -230.216111132083] r = [-671221.173240953, -118889.05838147, -362.103877270659] dt = 1745.70882893997
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [1296.08077724208, -1868.83574918339, -2.93769990912207] vpos = [3635.38990944477, -1417.65839210597, -113.604706616406] r = [-560508.039673819, -387353.971226789, -801.661336839737] dt = 0.0706165215858242
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [1156.45516840388, 1970.2460936713, 3.68363788236737] vpos = [3893.82875914009, -346.949438346306, -57.7533393901886] r = [584521.849746933, -344057.960986327, -460.420301189759] dt = 597.899252729705
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [704.850285687006, -2161.38220065293, -3.58218576355712] vpos = [3718.87968058702, -1174.97720603875, -155.249283065386] r = [-648212.312773448, -210690.051895506, -515.861814277727] dt = 1787.37435297368
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [2165.46857501255, -705.656945674153, -0.719589095323819] vpos = [3526.42085886747, -1676.79711602876, -79.0816472517961] r = [-212477.743092391, -646328.060022821, -1169.59702303931] dt = 194.08170649266
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [2108.04285990614, 873.29437431065, 2.00365840976906] vpos = [3792.38207401915, -941.625473288431, -63.3369484655993] r = [258387.58220386, -628019.0510316, -1028.39551079245] dt = 405.16477475475
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [1975.43413765195, -1131.16206351403, -1.50124372058336] vpos = [3426.25960985759, -1871.13978379024, -88.2672178390779] r = [-339673.289531979, -589902.714053572, -1101.37302546287] dt = 132.862398386812
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [1995.47786886689, -1095.62059515968, -1.43498430251063] vpos = [3416.26960006913, -1889.47718857536, -87.387980980201] r = [-329043.839082064, -595863.432055509, -1109.23280902355] dt = 138.215912806547
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [2005.8617531305, -1076.60342190295, -1.39961013344808] vpos = [3422.37865431368, -1878.47632030418, -86.8880508901686] r = [-323356.72374907, -598950.82060564, -1113.26162682214] dt = 141.058497119097
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [1997.19722103896, -1092.50127364227, -1.42917825173622] vpos = [3417.27777134991, -1887.6674697521, -87.3051289872105] r = [-328110.982747611, -596374.669085091, -1109.90199750844] dt = 138.683196582024
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn vneg = [1992.12680159554, -1101.66733229434, -1.44624342341127] vpos = [3416.84524441994, -1888.40874622977, -87.5408021978358] r = [-330852.181403101, -594866.982023084, -1107.92619852556] dt = 137.308931755054
[LOG 04:12:28.910] [MechJeb] singleImpulseHyperbolicBurn mu = 3531600000000 r0 = [-560599.548784293, -387221.989763838, -801.453864373913] v0 = [1295.63878065007, -1869.14112570438, -2.93833193718338] v_inf = [2205.42088999019, 80.2799431904898, -40.4930483177392]

 

Everything else is working fine as far as I can tell.

EDIT: also, "land at target" instantly disables itself, but keeps its lock on Smart A.S.S. It doesn't produce any logs.

Edited November 9, 2021 by ruiluth

[vipAvoS]

I wish you all good health!
Hi.
I was faced with such directness as ... I (read Kerbal) "blown away" from the ship!
More details.
I have a science collection mod installed. As soon as it becomes possible to collect a report related to the spacewalk, I go out, but I have no time to do anything, because MJ is again speeding up time and the canopy simply "blows" off the ship.
I do not understand how the "acceleration" of time can throw my kerbal off the ship !!!
Maybe it is worth revising the "automatic time acceleration" depending on whether someone from the crew is outside of his ship?

[rmaine]

1 hour ago, vipAvoS said:

I wish you all good health!
Hi.
I was faced with such directness as ... I (read Kerbal) "blown away" from the ship!
More details.
I have a science collection mod installed. As soon as it becomes possible to collect a report related to the spacewalk, I go out, but I have no time to do anything, because MJ is again speeding up time and the canopy simply "blows" off the ship.
I do not understand how the "acceleration" of time can throw my kerbal off the ship !!!
Maybe it is worth revising the "automatic time acceleration" depending on whether someone from the crew is outside of his ship?

I'd suggest the opposite approach. Rather than changing MJ to detect when a Kerbal is outside the ship, I suggest changing the practice of leaving the ship while automatic controls like MJ are active. All sorts of things can go poorly when you are on EVA. Heck, having the engines turn on is a much more obvious problem if you have automatic controls active. Changing that practice also has the advantage of requiring no coding. Yes, time warp has all sorts of issues. More than once I've had a Kerbal thrown away from the craft because I was a little too fast in going EVA after I stopped a time warp. (Entered space above a biome that I hadn't yet gotten EVA data for; wanted to quickly get the data before leaving that biome; oops.) In general, I find it better to learn how to best use things as they are and to avoid doing things that regularly cause problems instead of hoping for code tweaks to custom adapt to everything I try to do. There are quite a lot of things I've learned to just do a different way.

[vipAvoS]

Hello everybody.
I want to clarify my point.
I believe that for any event that caused the time acceleration to stop, either I pressed the slash key myself, or another mod stopped the time acceleration, MJ should turn off the "Automatic time acceleration" item on all its panels. It is not difficult to click on this item again, but it will save you from unnecessary "headaches".
Not only is I blown off the ship when I leave the capsule for the "situation report", but also when the "signal for an event" (Alarm Enhancements mod) is triggered and the time acceleration stops, MJ will still speed it up again! And this is already a problem.
It seems to me that the fixes in the code are minimal.
Thanks.

[sarbian]

3 hours ago, vipAvoS said:

It seems to me that the fixes in the code are minimal.

Ah. Code is always so easy.

The repo is here. I will be waiting for your minimalist PR.

[vipAvoS]

2 hours ago, sarbian said:

Ah. Code is always so easy.

The repo is here. I will be waiting for your minimalist PR.

I am familiar with programming. I imagine all the difficulties of fixing the code.
But I also perfectly understand how difficult it is to understand someone else's code! Moreover, if I have never been involved in this direction before.
Your proposal does not seem entirely friendly.
I just expressed my vision of the problems, and my desire to fix them. I am not forcing anyone to do this. If you think that the work of the MJ is much more prioritized over other tasks, then you should understand that the use of the MJ becomes problematic. To my great regret.
Just get my reasons out of your head, and consider this mod the coolest!
Thanks.

Excuse me for trying to help improve this wonderful mod somehow.
If this is not interesting to anyone, then, with your permission, I will no longer make any suggestions.
I'm sorry.

Edited November 10, 2021 by vipAvoS

[darthgently]

It would be kind of fun if a klaxon sounded (in the EVA kerb's headseat presumable) and rotating/flashing lights fired up prior to things like warp or craft reorientation of more than a few degrees.

As for EVAs and MJ warping as discussed above:  I presume the kerbal is on a ladder; is MJ able to warp while a kerb is on a ladder?

As for MJ warping, the only bad behavior I've had is when Aborting a landing in which 'autowarp' was on. Something kept restarting warp even after aborting the landing.  I assume it was MJ as it was the only thing running that altered warp and the situation that it occurs, when it occurs, is always the same: aborting MJ landing with autowarp on.  But other than that, very well behaved

[LTQ90]

1 hour ago, darthgently said:

It would be kind of fun if a klaxon sounded (in the EVA kerb's headseat presumable) and rotating/flashing lights fired up prior to things like warp or craft reorientation of more than a few degrees.

As for EVAs and MJ warping as discussed above:  I presume the kerbal is on a ladder; is MJ able to warp while a kerb is on a ladder?

As for MJ warping, the only bad behavior I've had is when Aborting a landing in which 'autowarp' was on. Something kept restarting warp even after aborting the landing.  I assume it was MJ as it was the only thing running that altered warp and the situation that it occurs, when it occurs, is always the same: aborting MJ landing with autowarp on.  But other than that, very well behaved

I haved some issues when landing and a staging must be done. As soon as the stage is empty, the autolanding module start warping. I have "funny" time with that in the past. So as soon as the breaking and alignement occurs, i ALWAYS disable the warp option. Just a little button to click. The fact is werehas MJ is a very good navigation computer i have to monitoring all his actions. Tx to Sarbian for this mod. Without it ksp, for me, wouldn't be so interessting.

[darthgently]

1 minute ago, LTQ90 said:

I haved some issues when landing and a staging must be done. As soon as the stage is empty, the autolanding module start warping. I have "funny" time with that in the past. So as soon as the breaking and alignement occurs, i ALWAYS disable the warp option. Just a little button to click. The fact is werehas MJ is a very good navigation computer i have to monitoring all his actions. Tx to Sarbian for this mod. Without it ksp, for me, wouldn't be so interessting.

The autowarp misbehavior on landing is the only persistent wrinkle I've encountered.  I had a one time occurance of either "launch into plane of target" or "match planes with target" (can't recall which now) where it put me in the same plane, but going in the retrograde direction of the target.  Only happened once, never repeated.  <shrug>.  Ditto on the thanks to Sarbian.  I use MJ as my ballpark design target for most of my kOS scripts.  The functionality of MJ is well thought out and fleshed out for sure

[Starwaster]

21 hours ago, vipAvoS said:

Hello everybody.
I want to clarify my point.
I believe that for any event that caused the time acceleration to stop, either I pressed the slash key myself, or another mod stopped the time acceleration, MJ should turn off the "Automatic time acceleration" item on all its panels. It is not difficult to click on this item again, but it will save you from unnecessary "headaches".
Not only is I blown off the ship when I leave the capsule for the "situation report", but also when the "signal for an event" (Alarm Enhancements mod) is triggered and the time acceleration stops, MJ will still speed it up again! And this is already a problem.
It seems to me that the fixes in the code are minimal.
Thanks.

It's better to experience painful things. Pain is an excellent teacher. Without pain, learning is impossible.

You have now learned that there are things in the game that will cause you pain necessitating a choice between reload or loss of Kerbal or ship.

[Gordon Dry]

The good old "roll jiggle back and forth on ascent" issue is still a thing, but only on a few specific parts.

The Bluedog Redstone rocket parts incl. control surface fins (without FAR patches) are such.

But other crafts with non-FAR-patched fins do not roll-jiggle on ascent.

It doesn't matter which attitude controller algorithm is chosen, as long as the craft is within about 75% of atmosphere height it roll-jiggles.

I also tried https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/lastSuccessfulBuild/artifact/MechJeb2-2.12.3.0-1101.zip

[vipAvoS]

10 hours ago, Starwaster said:

It's better to experience painful things. Pain is an excellent teacher. Without pain, learning is impossible.

You have now learned that there are things in the game that will cause you pain necessitating a choice between reload or loss of Kerbal or ship.

Well, I decided for myself this way: I instruct MJ to make a maneuver node, then I turn it off and I myself do the course correction and start the time acceleration.
But this is just a workaround. And I would like MJ to work correctly (only my personal opinion).

[SciMan]

@vipAvoS Generally this kind of issue that you are having (time warp not acting like how you'd like it to) is happening because somehow you have multiple plugins attempting to control time warp at the same time. Since MechJeb seems to be the most aggressive about making sure the game is at the time warp level it wants to be at, MechJeb wins no matter what the other mods tell the game to do.

The solution should be obvious. Get into a stable orbit before you take any experiment readings, and turn off MechJeb's ability to control time warp before you go on EVA (since your other science collection aid mods seem to be doing things with time warp already, having MechJeb's time warp control on seems like a case of "too many cooks in the kitchen").

I have a few little problems with the landing autopilot time warping too much when between the "deceleration" and the "vertical landing" burns, so what I do is I just turn the auto time warp off once the decelleration burn starts. It would be nice if it would be changed to just not time warp during that time, but I understand why it does. When using that landing autopilot to land on a body as small as Gilly, the time to get from roughly 500m altitude to where you actually have to use your engines to slow down for landing could take several minutes due to the low surface gravity, so the POSSIBILITY of having MechJeb time warp automatically for you is nice. However, when landing on the Mun, it can result in disaster if your lander doesn't have a TWR on the Mun of like 5.0 or more (and mine are usually around a Mun TWR of 1.5 to 2.5 when fully fueled, because that's low enough that it's comfortable for me to land with manually should the need arise (aka the first 10% of your throttle doesn't send you to a 5km apogee), but still not so low that you can't slow down before you hit the ground.

Like others have said, part of learning how to use MechJeb is learning to figure out how to work around the times where it only does "almost" what you want, instead of "exactly" what you want like it normally does.

Additionally, I too have noticed the issues with roll control on the ascent autopilot when you have aerodynamic control surfaces on the rocket, but I have a good workaround for it. Simply disable roll control on all the aerodynamic control surfaces, and rely on RCS or reaction wheels for roll control instead. This makes MechJeb act as it should, with not much (if any) roll oscillation during the ascent.
Actually, this reveals a problem with MechJeb and most aerodynamic control surfaces in general. It seems that the more control authority the aerodynamic control surfaces have in any axis, the more likely MechJeb is to be unable to damp out the oscillations caused by a sudden request to orient to a different attitude, like when you want to do the pull-up maneuver to get out of the atmosphere in a spaceplane after using the air-breathing engines (or engine modes) to get up to maybe around ~1200 to 1500 m/s surface velocity. Standard non-MechJeb SAS does not have any issues stabilizing the craft no matter what amount of control surfaces are present on the vessel (so long as the CoL is a little bit behind the CoM), so I'm not sure what's causing the issue.
I'm not sure how I'd go about fixing it in the code either, but if it's not already in there maybe a low-pass filter on the PID output would help things some? Or alternatively, maybe there's an issue with control surface position lagging behind input requested due to control surface actuation speed? I know in the past MechJeb had issues dealing with regular old engines that had a "gimbal speed" set to them (meaning the gimballing doesn't react instantly to control input), perhaps this could be another manifestation of that?
I'm unsure, but if it's not something you want to fix, it's something I'm already capable of compensating for.

[Gordon Dry]

6 hours ago, SciMan said:

Simply disable roll control on all the aerodynamic control surfaces, and rely on RCS or reaction wheels for roll control instead.

Now I'm digging for a convenience patch that defaults all control surfaces having roll disabled...

Edit: which is even harder to achieve for FARControllableSurface, but for ModuleControlSurface it's easy. Perhaps it's only needed for non-FAR-patched ControlSurface parts, when using FAR:

@PART[*]:HAS[@MODULE[ModuleControlSurface]]:NEEDS[MechJeb2]:FINAL
{
	@MODULE[ModuleControlSurface]
	{
		%ignoreRoll = true
	}
}

But, ModuleAeroSurface provides ignoreRoll, so perhaps FARControllableSurface also does? I just try it.

 

Edited November 12, 2021 by Gordon Dry

[vipAvoS]

16 hours ago, SciMan said:

@vipAvoS Generally this kind of issue that you are having (time warp not acting like how you'd like it to) is happening because somehow you have multiple plugins attempting to control time warp at the same time. Since MechJeb seems to be the most aggressive about making sure the game is at the time warp level it wants to be at, MechJeb wins no matter what the other mods tell the game to do.

.................

This is the problem. As I said, MJ restores the acceleration of time regardless of who or what stopped this acceleration.
The only mod I have that resets the acceleration of time is Alarm Enhancements.
It would be great if MJ in this case turned off its automatic acceleration. Or in the case when I myself press the slash.

[darthgently]

6 hours ago, vipAvoS said:

This is the problem. As I said, MJ restores the acceleration of time regardless of who or what stopped this acceleration.
The only mod I have that resets the acceleration of time is Alarm Enhancements.
It would be great if MJ in this case turned off its automatic acceleration. Or in the case when I myself press the slash.

This^^^,  MJ absolutely has sporadic issues with a "sticky" autowarp such that even if turned off in MJ, it will re-assert.  As previously noted the only time I've experienced this is when aborting a Landing (like I realize used West longitude instead of East in the target coords, click "Abort landing", manually cancel warp...then a few seconds later warp kicks in again.  I have to change to another craft or tracking center and back to make it stop.  I have no other warp modifying mods other that KAC that will cancel a warp for an alarm.  I'd guess it happens about 1 in 5 times.  Yes, I should probably be more careful about my target coordinates, lol

Edited November 13, 2021 by darthgently

[darkracer125]

auto warp is deffinatly causing issue's for me.   

though when i manually warp the same places i have no problems.  

 

in any case i had alot of issues yesterday where auto warp on the landing guidance was causing it to switch to a nearby sattalite (i can somehow switch to ships that are MILES away) wich causes my lander to crash because it's close to the ground and nothing is controlling it.    (luckely i always quicksave before landing)  

an other instance was when i was using a rover from konstruction (the first one you unlock) 

when i then used auto warp on the ascent guidance it would teleport me to 1000 meters in the air at the end of the time warp. and it would crash into the ground before the 10 seconds to launch were over.  

just now i uninstalled hyperedit.   i think it's part of the problem.  

 

(i use all of these to test my crafts btw.   i use mechjeb and also hyper edit as a "simulation mode")

[vipAvoS]

17 hours ago, darthgently said:

This^^^, MJ absolutely has sporadic issues with a "sticky" autowarp such that even if turned off in MJ, it will re-assert. As previously noted the only time I've experienced this is when aborting a Landing....

If I turn off time acceleration in the MJ while it is adjusting the inclination to reach the landing target, then the acceleration is no longer performed.
But the uncontrolled acceleration of time takes place. Today, while in low orbit of the Moon, I created an intercept maneuver through MJ to save the kerbal and enabled execution. Time began to speed up. And then I decided to slightly correct the maneuver. I pressed the slash (stopped acceleration) and turned off the automatic acceleration in MJ. So what? Right. Time all the same began to accelerate.
Sorry, but in my opinion this is already a clear bug.

[darthgently]

6 hours ago, vipAvoS said:

If I turn off time acceleration in the MJ while it is adjusting the inclination to reach the landing target, then the acceleration is no longer performed.
But the uncontrolled acceleration of time takes place. Today, while in low orbit of the Moon, I created an intercept maneuver through MJ to save the kerbal and enabled execution. Time began to speed up. And then I decided to slightly correct the maneuver. I pressed the slash (stopped acceleration) and turned off the automatic acceleration in MJ. So what? Right. Time all the same began to accelerate.
Sorry, but in my opinion this is already a clear bug.

I never said it wasn't a bug; totally agree.  I was attempting to narrow when the bug, that exists, occurs.  In addition to what you do, hitting slash, I even unclick the autowarp checkbox, and it still reasserts warp when landing.