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

[Starwaster]

Just now, Voodoo8648 said:

I dunno man. That patch is counter-intuitive to his problem. If anything he needs MORE TORQUE, not less and certainly not 90% less. 

I'm not suggesting he USE it... I'm just saying that I do and I get all the torque I need from my engines. Sometimes I'll add fins for stability but usually I can get away without it. Not to mention vernier type engines like either small gimbaled or the 'vernor' RCS 

[Bornholio]

16 hours ago, Quarkz said:

See, I'm recreating the Ares V, so I can't really add fins or any other design change, because then it wouldn't look like the original design.

If you don't feel its cheating put the fins on and move tool them inside the lower part of the rocket, unless you are using FAR they will still work correctly. 

One possibility if you are using an older mod part pack for the fairing is it may not have the proper contents protection module to eliminate the drag of its interior. If so the drag may be insurmountable without using an extreme launch profile. (issue doesn't apply to FAR)

The rocket honestly looks like something I would not add fins sas or rcs to and if it had some gimbal to the main engine it would launch fine stock or far. (assuming not too extreme MJ or flight control input)

Edited June 11, 2017 by Bornholio

[Voodoo8648]

Are there ANY plans by @sarbian to fix MechJeb not being affected by CommNet and disable MJ when signal is lost???

I would REALLY like for there to be no control with MJ when there is no signal.  

[Bornholio]

Why do flight computers stop working because they are not receiving communication. Landing would be impossible on Mars if so. at best 8 minutes delay.  Mechjeb represents using automatic flight controls. Rockets are not flown from a station in the control room, they a programmed ahead of time. Mid course corrections are uploaded days or weeks ahead. Landing parameters loaded before launch.  If this thought is because of using remote tech with its flight computer, is that different. Or kOS? Even "piloted" craft don't actually have pilots giving Input controls in most cases. And even then for burns they are input into a flight computer and set to execute at the proper time.

Want no control when signal is lost, then simple. don't use it. It isn't broken or a bug that needs to be fixed.  /gripe_OFF

[Starwaster]

2 hours ago, Bornholio said:

Why do flight computers stop working because they are not receiving communication. Landing would be impossible on Mars if so. at best 8 minutes delay.  Mechjeb represents using automatic flight controls. Rockets are not flown from a station in the control room, they a programmed ahead of time. Mid course corrections are uploaded days or weeks ahead. Landing parameters loaded before launch.  If this thought is because of using remote tech with its flight computer, is that different. Or kOS? Even "piloted" craft don't actually have pilots giving Input controls in most cases. And even then for burns they are input into a flight computer and set to execute at the proper time.

Want no control when signal is lost, then simple. don't use it. It isn't broken or a bug that needs to be fixed.  /gripe_OFF

I agree that MJ should still have control when comms are unavailable but it shouldn't be possible to issue commands to it when comms are down.

[Voodoo8648]

18 minutes ago, Starwaster said:

I agree that MJ should still have control when comms are unavailable but it shouldn't be possible to issue commands to it when comms are down.

Yes, let me correct my previous comment, you should be able to upload a maneuver node or upload a flight plan using the Scripting module ONLY WHEN there is a good signal with the probe. When signal is lost, the probe SHOULD still be able to execute those nodes by itself with no signal, but we should not be able to control the probe or even send an executable maneuver command when there is no signal. 

@Bornholio, it may not be a "bug" but it sure isn't analogous with real life. Mission controllers do not simply exercise restraint from controlling probes. Why would this request be worthy of a /gripe lol.

[Bornholio]

It is a tradeoff, you have no planning staff simulating the whole plan before hand and submitting a flight plan. So you are allowed to control it in flight otherwise the game would honestly suck for most people.  for those it would not, there is KOS and KRPC.  Its like the flight control stick in a pod. It doesn't do anything.

Realisticly i would have no control the vast majority of flight. A change would require three days in an ofice with a planning team.

Edited June 12, 2017 by Bornholio

[Voodoo8648]

7 minutes ago, Bornholio said:

It is a tradeoff, you have no planning staff simulating the whole plan before hand and submitting a flight plan. So you are allowed to control it in flight otherwise the game would honestly suck for most people.  for those it would not, there is KOS and KRPC.  Its like the flight control stick in a pod. It doesn't do anything.

That doesn't make any sense. That's why relay satellites exist. As it currently is, MJ kills the in game communications network mechanic. It takes away the need for relay satellites altogether. You can fly all the way to Jool, perform orbital insertion, fly to a couple Joolian moons, then fly back to Kerbin with no antennas! 

IMHO that kills immersion and could be considered game breaking. 

Edited June 12, 2017 by Voodoo8648

[Starwaster]

I agree with  @Voodoo8648, we can't pretend that MJ's interaction with CommNet (or lack thereof) isn't a problem.

Sooner or later it's going to have to be addressed in some fashion

 

 

 

[sarbian]

Knock yourself out :

https://github.com/MuMech/MechJeb2

https://git-scm.com/book/en/v1/Getting-Started

http://csharp.net-tutorials.com/

 

[Bornholio]

All early probes went to planets without Comsats. Control for Curiosity's landing was done before it left and slightly updated days before. The figurative Mechjeb picked when to land and needed no communications to execute. Given that the delay is minutes to hours for most space craft outside earth SOI everything is effectively done without communications.

Just because NASA can plan pre-sending these commands ahead of time doesn't mean that its fun or practical for the game. But if you want its all there in other mods. Mechjeb is automation that simulates, very well, all the planning and effort that goes in behind the scenes at a space program.

Take away its functions because of lack of communication is like saying to the soviets in 1959 you can't take pictures on the far side of the moon.  You aren't allowed to push that button.

Edited June 12, 2017 by Bornholio

[Starwaster]

9 minutes ago, Bornholio said:

All early probes went to planets without Comsats. Control for Curiosities landing was done before it left and slightly updated days before. The figurative Mechjeb picked when to land and needed no communications to execute. Given that the delay is minutes to hours for most space craft outside earth SOI everything is effectively done without communications.

Except that in this figurative Curiosity argument, now you can control it even when it's in blackout. Even if you forgot an antenna. Comms are a part of the game now and it's an area that needs addressing

Also, why trying to introduce comm delay into the argument? Nobody is talking about having delays. Only having MechJeb interact with CommNet in a meaningful way. This isn't about that.

"Nothing will ever be attempted if all possible objections must first be overcome."

Edited June 12, 2017 by Starwaster

[Jimbodiah]

I love Mechjeb. Thanks Sarbian!!!!

Edited June 12, 2017 by Jimbodiah

[Voodoo8648]

1 hour ago, Bornholio said:

All early probes went to planets without Comsats. Control for Curiosity's landing was done before it left and slightly updated days before. The figurative Mechjeb picked when to land and needed no communications to execute. Given that the delay is minutes to hours for most space craft outside earth SOI everything is effectively done without communications.

Just because NASA can plan pre-sending these commands ahead of time doesn't mean that its fun or practical for the game. But if you want its all there in other mods. Mechjeb is automation that simulates, very well, all the planning and effort that goes in behind the scenes at a space program.

Take away its functions because of lack of communication is like saying to the soviets in 1959 you can't take pictures on the far side of the moon.  You aren't allowed to push that button.

In my opinion, if you want automation when there is no comm signal, either use KOS or MJ's Scripting Module. If you don't want to learn to code with KOS and you need to do something more complex than MJ Scripting module allows, then send up a relay satellite to get the job done. As it currently is, MJ eliminates an entire aspect of the simulator.

On another note, I just installed Remote Tech and that does eliminate MJ control when signal is lost, however it also disables MJ entirely and prevents MJ from executing pre-planned maneuvers during signal blackout  

[Bornholio]

5 minutes ago, Voodoo8648 said:

In my opinion, if you want automation when there is no comm signal, either use KOS or MJ's Scripting Module. If you don't want to learn to code with KOS and you need to do something more complex than MJ Scripting module allows, then send up a relay satellite to get the job done. As it currently is, MJ eliminates an entire aspect of the simulator.

On another note, I just installed Remote Tech and that does eliminate MJ control when signal is lost, however it also disables MJ entirely and prevents MJ from executing pre-planned maneuvers during signal blackout  

Then there is an extremely simple answer to the whole argument.  Don't use it if the connection is unavailable.  people who think that is unreasonable like me will continue to use it.  Or like Sarbian suggested, fork it and put in functions like RT adds.

Edited June 12, 2017 by Bornholio

[dlrk]

Would it be possible to get a 1.2.2 version of the latest mechjeb?

Edited June 12, 2017 by dlrk

[billkerbinsky]

27 minutes ago, Loren Pechtel said:

I have long suspected that return from a moon is doing it's math from the moon's current position, not where it will be when the booster lights and I was trying to confirm it and if so see if I could figure out a fix.  Also, I was looking at the land here function--I'm pretty sure it's trying to fly the rocket to a 0,0 intercept with the current ground height but I haven't figured out how to get it work like the land at target and aim for a point above the ground first.

The periapsis error from "return from a moon" has bugged me as well.   It's easy enough to work around once you get out of the moon's SoI, but when I get a chance I'm going to try characterizing the error a bit better - try creating the node at different times and then dink around with the maneuver node editor on the maneuver node created by MJ and look at what changes to either the node's timing or delta-v do to the predicted periapsis value.   If you're right and it's just a mistake in reference frame it might be a simple fix.

[Loren Pechtel]

3 hours ago, billkerbinsky said:

The periapsis error from "return from a moon" has bugged me as well.   It's easy enough to work around once you get out of the moon's SoI, but when I get a chance I'm going to try characterizing the error a bit better - try creating the node at different times and then dink around with the maneuver node editor on the maneuver node created by MJ and look at what changes to either the node's timing or delta-v do to the predicted periapsis value.   If you're right and it's just a mistake in reference frame it might be a simple fix.

It's not just a periapsis error--I have seen an ejection from Kerbin's SOI from this.  The longer from setting it up to the actual burn the worse the error is and it seems to me that the ejection angle makes sense given the position of the moon when I ordered it.  A high orbit about the Mun can allow the Mun to move quite far around Kerbin before the rocket is in position.  I just thought of a fairly simple way to test my hypothesis but I have to go now.

Back now, confirmed.

I started a test game, hypered a simple rocket into a 1000km Mun orbit and ordered a return.  The ejection angle is 169.28 from retrograde.  Now I warped to just before the maneuver node, remove the old node and create it again.  This time I get an ejection angle of 124.11 from retrograde.

By eyeball the new node is approximately as far ahead of me in orbit as Mun has moved around Kerbin.

There is no question that the rotation of the moon about the planet is not being considered in the return from a moon calculation.

Edited June 13, 2017 by Loren Pechtel

[Vanamonde]

A number of posts have been removed from this thread. You are free to suggest a change to the mod, but no one has a right to insist on it, nor does anyone need to attack a fellow forum member over making the suggestion. 

[Loren Pechtel]

Got a clue on the problem I've had with advanced transfer double-burning:

The burn was almost over on a Mun to Minmus transfer.  I was watching the projected track, when the line touched MInmus' SOI it suddenly went to "No Target"--and at that instant the burn timer filled back up.

I find nothing in the log at the relevant time that says it's from MechJeb but I do find:

[LOG 20:40:48.279] Transfer calculator: termination type=1
[LOG 20:40:48.279] Transfer calculator: iteration count=11

However, I aborted the burn when I saw this happen, you very well might be seeing my abort rather than any sign of the burn going wrong.

[SupremeSoviet]

General Question.  How does the Auto Docking work in the current version?  I haven't played the game in a while and was interested.  The last time I played the MechJeb Auto Docking was rather wonky and didn't work right.  Thanks for the time.

-SupremeSoviet

[rmaine]

11 hours ago, Loren Pechtel said:

Got a clue on the problem I've had with advanced transfer double-burning:

The burn was almost over on a Mun to Minmus transfer.  I was watching the projected track, when the line touched MInmus' SOI it suddenly went to "No Target"--and at that instant the burn timer filled back up.

I find nothing in the log at the relevant time that says it's from MechJeb but I do find:

[LOG 20:40:48.279] Transfer calculator: termination type=1
[LOG 20:40:48.279] Transfer calculator: iteration count=11

However, I aborted the burn when I saw this happen, you very well might be seeing my abort rather than any sign of the burn going wrong.

While not quite identical, that shares at least some elements of an annoyance that I concluded was not a McJeb issue (and thus I didn't post it here). I've learned not to change my focus when a maneuver is burning - or heck, even when I have a future maneuver scheduled. I'd be looking around at other things while waiting for a burn to start or finish and fail to notice that the burn suddenly started or continued way past its initial cutoff or otherwise screwed up. Strongly correlated with my changing focus. At first, I thought it was a McJeb issue, but I get it without McJeb also, so I think it is more fundamental. It has kept me from trying to schedule multiple burns in a sequence; I have to wait for one to finish before working on the next.

[Loren Pechtel]

30 minutes ago, rmaine said:

While not quite identical, that shares at least some elements of an annoyance that I concluded was not a McJeb issue (and thus I didn't post it here). I've learned not to change my focus when a maneuver is burning - or heck, even when I have a future maneuver scheduled. I'd be looking around at other things while waiting for a burn to start or finish and fail to notice that the burn suddenly started or continued way past its initial cutoff or otherwise screwed up. Strongly correlated with my changing focus. At first, I thought it was a McJeb issue, but I get it without McJeb also, so I think it is more fundamental. It has kept me from trying to schedule multiple burns in a sequence; I have to wait for one to finish before working on the next.

I have only seen this problem with the advanced transfer to another planet.  Sometimes a burn goes badly if you're using a low TWR engine close to a planet (I've learned with the nuke engine to move to say a 1000km orbit before burning for another world and with a big rocket on a single nuke I'll add another lower orbit also but that's because maneuver nodes are calculated as if the whole burn occurs at the node.  That's always an error of bearing, though, not of burn time.

[winged]

@Starwaster @Virtualgenius I am the author of the rocket from previous page. Ascent works perfectly on my RO/RSS insallation without any reaction wheels, fins or limiting the acceleration but what I've noticed is that he is trying to launch from Kerbin, not Earth, maybe this is something that makes crucial difference.

 

[rmaine]

3 hours ago, Loren Pechtel said:

I have only seen this problem with the advanced transfer to another planet.  Sometimes a burn goes badly if you're using a low TWR engine close to a planet (I've learned with the nuke engine to move to say a 1000km orbit before burning for another world and with a big rocket on a single nuke I'll add another lower orbit also but that's because maneuver nodes are calculated as if the whole burn occurs at the node.  That's always an error of bearing, though, not of burn time.

Oh. I get it all the time. Let's see, I'll try to duplicate it right now. Oh. I do see that I misrecalled in that setting/changing a target is what triggered it - not just changing focus. I launched a craft capable of munar orbit and return. Boost til I get a decent apogee (150 km). Use MJ (though as noted, I've seen the same thing with manuever nodes created without MJ)  to create and start a circularization burn. Wait til I have only about 100 m/s left in the burn. Go to map mode and set mun as the target (in preparation for planning a munar transfer burn). Suddenly my maneuver node shows 1400 m/s left in the burn instead of under 100. And if I fail to notice this because I'm studying something else, figuring that the circularization burn should leave me in a nice stable orbit, it will indeed work on burning up most of my fuel, putting me on an escape trajectory to nowhere. poor Jeb. :-(

I'm thinking it i something like changing the frame of reference for the burn and trying to get me the same speed as initially planned, but now relative to a different frame of reference.