Jump to content

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


sarbian

Recommended Posts

7 hours ago, sarbian said:

Someone opened a ticket about ion reporting 0dv so I guess this is related. I'll try to fix it this week.

That makes sense actually. I've noticed both of these things- that ion drive lead time is 0, and that it reports 0dv in the VAB.

Link to comment
Share on other sites

On 2/24/2019 at 11:49 PM, Jim DiGriz said:

If you're stuck on 1.3.1 due to RSS/RO/RP-1 you should also be using the MJ-dev backports:

https://github.com/lamont-granquist/PrimerVectorMechJeb/releases

Otherwise I doubt anyone is going to be able to help you debug the 2.7.0.0 version -- I can't even recall what that code looked like any more.

Yeah I went to 1.4.5 and had the same problem so I stripped all mods away so I could test each one and now I have most of the kids with no problem, but most of the time I try to launch mechjeb doesn't activate peg guidance and it goes locked on terminal guidance and screws up the launch... I don't know what I'm doing wrong...

Edit: reset the settings... Seems to work now.

 

Nice

Edited by Anders Kerman
Fixed
Link to comment
Share on other sites

 

On 2/25/2019 at 7:35 PM, GoatRider said:

That makes sense actually. I've noticed both of these things- that ion drive lead time is 0, and that it reports 0dv in the VAB.

https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/868/

that should fix ion drives.

and if the delta-V display is not working then the burntime estimation of the node executor will not function -- so fixing the delta v display should fix node execution.

also note though that modelling an ion burn as an impulsive burn is pretty inaccurate no matter what.  one day i hope to have a PVG-driven node executor that can do those kinds of burns accurately (although i can't help with how boring they are).  for now though it won't be accurate and it'll waste a lot of ∆v (particularly compared to the infinite-thrust maneuver node calculation which will be hilariously off).

Link to comment
Share on other sites

10 hours ago, Jim DiGriz said:

 

https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/868/

that should fix ion drives.

and if the delta-V display is not working then the burntime estimation of the node executor will not function -- so fixing the delta v display should fix node execution.

also note though that modelling an ion burn as an impulsive burn is pretty inaccurate no matter what.  one day i hope to have a PVG-driven node executor that can do those kinds of burns accurately (although i can't help with how boring they are).  for now though it won't be accurate and it'll waste a lot of ∆v (particularly compared to the infinite-thrust maneuver node calculation which will be hilariously off).

Confirmed that dV of ion drives is now fixed in the VAB. Confirming the node execution would take actual work.

One thing that would be nice is if the burntime estimate also calculated the max thrust for the amount of electrical input available. And also set the throttle at that point while it was executing, without having to fiddle with thrust limiters.

Link to comment
Share on other sites

10 minutes ago, GoatRider said:

One thing that would be nice is if the burntime estimate also calculated the max thrust for the amount of electrical input available. And also set the throttle at that point while it was executing, without having to fiddle with thrust limiters.

I can see that being very complex - I typically use Ion drives in combination with NFE, for instance, which has 'capacitors' - high-density storage for EC, which limits on charge and discharge speed.  Charging them while idle and then discharging them when the batteries get low during an Ion burn works very well, as long as you don't have burns to close together and size things correctly.  Or I'll ramp-up the a nuclear reactor during the burn, and then bring it down to trickle afterwards.

In short: It might be nice, but it'd require an easy override.

Link to comment
Share on other sites

4 minutes ago, DStaal said:

I can see that being very complex - I typically use Ion drives in combination with NFE, for instance, which has 'capacitors' - high-density storage for EC, which limits on charge and discharge speed.  Charging them while idle and then discharging them when the batteries get low during an Ion burn works very well, as long as you don't have burns to close together and size things correctly.  Or I'll ramp-up the a nuclear reactor during the burn, and then bring it down to trickle afterwards.

In short: It might be nice, but it'd require an easy override.

Yeah I figured it might be quite complex, and should be optional.

Link to comment
Share on other sites

14 hours ago, Anders Kerman said:

Ok so after installing procedural parts, procedural fairings, procedural fairings for everything and decoupler shroud mechjeb won't throttle up for peg...

You keep saying "peg" which may be a large chunk of your problem.

The current builds for 1.4/1.5/1.6 and my 1.3 backports are all PVG or "Primer Vector Guidance"

And if you're using "Atlas-Centaur PEG" (which isn't even really PEG) and not "Shuttle PEG" that is hopelessly old and I've forgotten all the bugs in it.  I rewrote it all twice since then.

Link to comment
Share on other sites

On 2/27/2019 at 10:43 AM, sarbian said:

We can not help without any logs 

Well I'll supply logs once I have pinned down the exact mods that are causing the incompatibility. Or I might try to fix it myself if possible...

15 hours ago, Jim DiGriz said:

You keep saying "peg" which may be a large chunk of your problem.

The current builds for 1.4/1.5/1.6 and my 1.3 backports are all PVG or "Primer Vector Guidance"

And if you're using "Atlas-Centaur PEG" (which isn't even really PEG) and not "Shuttle PEG" that is hopelessly old and I've forgotten all the bugs in it.  I rewrote it all twice since then.

Ahhhh that's what was meant with backports! Is there also hotstaging?

Link to comment
Share on other sites

On 2/24/2019 at 11:49 PM, Jim DiGriz said:

If you're stuck on 1.3.1 due to RSS/RO/RP-1 you should also be using the MJ-dev backports:

https://github.com/lamont-granquist/PrimerVectorMechJeb/releases

Otherwise I doubt anyone is going to be able to help you debug the 2.7.0.0 version -- I can't even recall what that code looked like any more.

is it also compatible with 1.4.X?

Link to comment
Share on other sites

47 minutes ago, Anders Kerman said:

is it also compatible with 1.4.X?

The mainline MJ and MJ-dev builds are all 1.4/1.5/1.6 there were no codechanges and no symbols changed.  Same dll works across all of them.

And autohotstaging has been added to PVG.

Link to comment
Share on other sites

23 hours ago, Jim DiGriz said:

The mainline MJ and MJ-dev builds are all 1.4/1.5/1.6 there were no codechanges and no symbols changed.  Same dll works across all of them.

And autohotstaging has been added to PVG.

so what do I have to download to get pvg on 1.4.x? I'm really confused 

Link to comment
Share on other sites

@sarbian

Have a bit of a mod compatibility problem with Mechjeb.

I released a mod, the AECS Motion Suppressor, which, among other things, disables engine gimbaling when the engine(s) aren't running.

A problem has cropped up in which if the engines are disabled using:

gimbalModule.gimbalLock = true;

then Mechjeb won't be able to use the gimbaling, even though as soon as the engines are started, gimbaling is enabled.  I'm guessing that this is probably caused by Mechjeb setting it's internal variables at the start of a maneuver, and not seeing the change.

Is this true, and if so, is there something I can to to tell Mechjeb that gimbaling is active again?

 

I've traced this to the fact that FlightInputHandler.state.mainThrottle == 0 even when the engines are firing with Mechjeb.  I am looking at that to reduce the overhead of checking each engine every time.  Is there a way I can tell if MechJeb is executing a maneuver?  If so, then I can at least only check all the engines if Mechjeb is active

Edited by linuxgurugamer
Link to comment
Share on other sites

4 hours ago, linuxgurugamer said:

I've traced this to the fact that FlightInputHandler.state.mainThrottle == 0 even when the engines are firing with Mechjeb.  I am looking at that to reduce the overhead of checking each engine every time.  Is there a way I can tell if MechJeb is executing a maneuver?  If so, then I can at least only check all the engines if Mechjeb is active

That is rather timely and interesting:

https://github.com/MuMech/MechJeb2/pull/1143/files#diff-28fc7ff970f6cb096f1480f425495c5bR562

So if you take build #871:

https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/871/

Then go into the Settings menu and tick "Module disabling does not kill throttle (RSS/RO)" to being set, does that fix the issue?

I was tempted to not gate that behind the rssMode check at all, but didn't know what affect it would have on "stock" behavior.

Link to comment
Share on other sites

7 hours ago, Jim DiGriz said:

That is rather timely and interesting:

https://github.com/MuMech/MechJeb2/pull/1143/files#diff-28fc7ff970f6cb096f1480f425495c5bR562

So if you take build #871:

https://ksp.sarbian.com/jenkins/job/MechJeb2-Dev/871/

Then go into the Settings menu and tick "Module disabling does not kill throttle (RSS/RO)" to being set, does that fix the issue?

I was tempted to not gate that behind the rssMode check at all, but didn't know what affect it would have on "stock" behavior.

Yes, it does fix the issue.  However, there are other things which cropped up, so for now I'll have to leave it the way I updated it last night.

Are you now working on this instead of @sarbian?

Link to comment
Share on other sites

48 minutes ago, linuxgurugamer said:

Yes, it does fix the issue.  However, there are other things which cropped up, so for now I'll have to leave it the way I updated it last night.

I did not understand a little from the written, but the problem can be solved by the checkbox "Module disabling does not kill throttle (RSS/RO)"?

7 hours ago, Jim DiGriz said:

Then go into the Settings menu and tick "Module disabling does not kill throttle (RSS/RO)" to being set, does that fix the issue?

How this option will affect on stock(no RSS/RO)?

 

Link to comment
Share on other sites

4 minutes ago, rebel-1 said:

I did not understand a little from the written, but the problem can be solved by the checkbox "Module disabling does not kill throttle (RSS/RO)"?

How this option will affect on stock(no RSS/RO)?

 

Apparently that could solve it, but I came across a couple of other situations, unrelated to MechJeb, which could have had the same issue.  So now the code is checking all engines 4x a  minute to see if there is fuel flow, if there is and the engine gimbaling wasn't manually disabled, it enables the gimbaling

Link to comment
Share on other sites

8 minutes ago, linuxgurugamer said:

Apparently that could solve it, but I came across a couple of other situations, unrelated to MechJeb, which could have had the same issue.  So now the code is checking all engines 4x a  minute to see if there is fuel flow, if there is and the engine gimbaling wasn't manually disabled, it enables the gimbaling

OK, thanks

Link to comment
Share on other sites

6 hours ago, linuxgurugamer said:

Yes, it does fix the issue.  However, there are other things which cropped up, so for now I'll have to leave it the way I updated it last night.

Are you now working on this instead of @sarbian?

In addition to sarbian, he still owns it.  I just have commit bits.

I'm now leaning towards this being correct behavior to set the flightinputhandler, so I think I'll probably patch it in MJ as well.

Link to comment
Share on other sites

On 8/14/2018 at 6:07 PM, Fitz0uille said:

Hello there :)
I find a trouble into the 801 version.
When you use auto-landing the horizontal speed stay to hight so you tip over.
RCS and SAS activated after landing are good but in case you don't have RCS, this seems to add more trouble than fixe them :)

I have been back in the current version and landing working fine on minmuns with 1.4.5 :)

I love what you have done in this mod, this is sooo awesome

nice

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...