Request Mechjeb like addon?

[AlfalfaQc]

KSP...yeah. Ok.

You want to do things in Orbiter? get IMFD.

Well, I think the OP wants a press a button and go there in Orbiter, pretty much what MecJeb is (if I'm correct).

 

[Cras]

there is not one single master add on that does every single thing for you for all phases of flight, but there is plenty of tools out there that will help you accomplish specific tasks.

If what you want to do is go somewhere beyond Earth orbit, then use IMFD. Enter destination, set up a couple parameters, press AB, and you are on your way.

It is a little more complicated, but not much.

 

[Codz]

Is there an easy way in vanilla KSP to set up interplanetary flights with the maneuver node system? My issue is that you can't move maneuver nodes past one orbit into the future, which makes planning difficult.

Not really, at the moment. It's not exactly down to a science, but I usually just try to estimate the injection window plus or minus a couple days.

 

[N_Molson]

What can really be improved is indeed the "Time to burn" timer that is currently a bit buggy. First, it works only if you already engaged you main thruster to 100%. Else it seems it can't get the max thrust value. Usually I do a very short burn right before the maneoeuver to initialize the tool. A few m/s are lost but that isn't a drama, mid course corrections exist for something. Then it is a bit imprecise about the duration of the burn. Not by a lot, but you have to get some experience to learn how to "compensate" for that. But still, it is perfectly usable once you got the feeling. Same in Orbiter : you need some experience to begin to do things the right way.

 

[Face]

Are you folks talking about improving the KSP thing now, or is it still about getting the Mechjeb-mod functionality in Orbiter?

If it is the former, I'd suggest bringing it to the KSP forums, as we can't really change that here. If it is the later, is there some functionality in Mechjeb that is completely missing in Orbiter's add-on ecosystem, or is it the lack of a consistent and comprehensive package that triggered the request?

 

[AlfalfaQc]

The thing with MecJeb is that it is pretty much a "press one button and go there" (I think, never used it myself). I don't think there is such a thing in Orbiter. Let say you want to dock in orbiter, you can use the orbit sync MFD to sync, then you have the docking MFD for the docking manoeuvre, but you still need to do the burn yourself, in MecJeb, you press a couple button and the add-on do all the thing for you.

But I might be wrong, I never used MecJeb myself, and maybe some add-on can do the same in orbiter.

 

[C3PO]

The thing with MecJeb is that it is pretty much a "press one button and go there" (I think, never used it myself).

We have the scenario editor. Slightly faster and slightly less fun.

I have no problem with people MechJeb. It all depends on how you use it. I used it almost entirely for the numerical readouts. (I use engineer now) I just think that those who use the 'one button solution' are missing out on most of the fun.

I can do arithmetic by hand, but I have no problem using calculators to save time.

 

[Cras]

You want to press one button and go there, just go watch a playback then or something. There are plenty of MFDs that have automatic functions that you can pretty much use an MFD to get you into orbit, another to alter it, another to rendezvous, and then another to dock, without ever having to actually do a single burn manually.

Who cares if it is not all in one single MFD. There is Universal Autopilot that tries to do that but good look with that, using that and you will understand why having a single MFD doing everything is a bad idea as your launch goes wildly off course, your phasing orbit re-enters your ship into the atmosphere, and you actually never get to your target.

This is Orbiter, not KSP.

 

[Loru]

This is Orbiter, not KSP.

Yes....

That's right. Orbiter is not KSP however investigating possibility of having mechjeb like add-on could for example stimulate someone to design and write framework for interactive helper for new players. It could for example take care of some parts of vehicle control while focusing the player's attention on certain task to show him importance of particular variable/parameter. For example in winged reentry you need to have proper entry angle, AOA and you have to perform S-turns. If you perform reentry manually you also need to control your vertical speed and VACC.

Don't you think add-on like that could potentially help some people learn orbital mechanics without throwing at their heads 50 tons of information at once?

Or something like basic launch when AP/mechjeb takes care of heading and player takes care of pitch profile??

Don't you think it would be rewarding as hell if new player could launch rocket taking care only of pitch / throttle and staging while rocket is guided straight into randez vouz with ISS?

Orbiter have really steep learning curve and making it a bit user friendly for begginers without spoiling fun for hardcore orbinauts can be done. It's only matter of design, coding talent and comunity support (exposed control APIs for vessels etc).

just my :2cents:

 

[BruceJohnJennerLawso]

Yes....

Loru... you are my hero.

 

[Cras]

You can use Launch MFD to hold launch heading while you mess with throttle and pitch, you can use Glideslope to assist with a de-orbit and re-entry.

My point has been there are quality MFDs out there already made and proven to work in a number of situations that will allow anyone to be able to fly anywhere in the solar system without having to manually touch the throttle or rcs thrusters. Making a one for all MFD so someone new could learn would be a waste of time. Its better off they just watch the DGIV use its autopilots and then learn how to duplicate the results then on their own.

I dont think Orbiter has a steep learning curve. I think this community often gives bad advice to new users and like to make it seem more difficult than it needs to be.

 

[Loru]

Yes - launch MFD can be used that way but please do small experiment. For a minute imagine you have only rudimentary understanding of orbital mechanics and don't know all those fancy acronyms. And look at launch MFD screen.

I rest my case here.

 

[Urwumpe]

Yes - launch MFD can be used that way but please do small experiment. For a minute imagine you have only rudimentary understanding of orbital mechanics and don't know all those fance acronyms. And look at launch MFD screen.

I rest my case here.

I think thats why for some people, KSP is the better choice and for others Orbiter, and some infidels among us like both but also play KSP then in a way that does not intersect much with Orbiter - and thus don't understand the MechJeb and other stuff.

 

[Donamy]

Don't you think add-on like that could potentially help some people learn orbital mechanics without throwing at their heads 50 tons of information at once?

No wonder I get headaches.:facepalm:

 

[BruceJohnJennerLawso]

Yes - launch MFD can be used that way but please do small experiment. For a minute imagine you have only rudimentary understanding of orbital mechanics and don't know all those fancy acronyms. And look at launch MFD screen.

I rest my case here.

I would be happy to have an MFD that simply listed node times of useful parking orbits for my current ground position, and the launch azimuth (available while landed of course). Even after learning TransX inside out and a fair bit of IMFD too, a basic thing like that is still a wee bit tricky.

I think the biggest issue with MFDs is the tendency to try to do too much in one package. I would rather have a lot of MFDs that only handled a few simpler tasks at once than something uber-complex like IMFD that handles a ton of complex tasks all at once. After all, even launch MFD is no substitute for learning about ascent to orbit by sitting down with the Orbit & Surface MFDs & experimenting with how it works.

Just my 2/5 of a Nickel

 

[Pablo49]

I dont think Orbiter has a steep learning curve. I think this community often gives bad advice to new users and like to make it seem more difficult than it needs to be.

This comment is so laughably wrong I almost reported it as trolling.

 

[kamaz]

I dont think Orbiter has a steep learning curve. I think this community often gives bad advice to new users and like to make it seem more difficult than it needs to be.

This comment is so laughably wrong I almost reported it as trolling.

Actually there is something to what Cras is saying.

If you think about it, most tutorials start with Earth ascent. But in your typical KSC-to-ISS ride, Earth ascent is the most difficult part -- hence, learning curve.

It has occured to me today that maybe someone should do a tutorial series which is done backwards, and starts already in orbit with the following plan: (1) orbital maneuvers (2) ISS intercept & docking (3) deorbit and landing and (4) ascent planning and ascent. The reason is that ascent planning and ascent execution is complete voodoo unless you gain understanding of what is covered in points (1), (2) and (3). E.g. understanding the concept of launch window requires understanding of LAN and ground track. But LAN is easier to explain if you're already in orbit, and ground track is easier to explain in the context of landing.

Recall that in KSP the launch pad sits on the equator and people are just told to launch due east. So they put everything in equatorial orbit, which goes over launch pad every revolution. Launch window? What is that?

 

[BruceJohnJennerLawso]

Actually there is something to what Cras is saying.

If you think about it, most tutorials start with Earth ascent. But in your typical KSC-to-ISS ride, Earth ascent is the most difficult part -- hence, learning curve.

It has occured to me today that maybe someone should do a tutorial series which is done backwards, and starts already in orbit with the following plan: (1) orbital maneuvers (2) ISS intercept & docking (3) deorbit and landing and (4) ascent planning and ascent. The reason is that ascent planning and ascent execution is complete voodoo unless you gain understanding of what is covered in points (1), (2) and (3). E.g. understanding the concept of launch window requires understanding of LAN and ground track. But LAN is easier to explain if you're already in orbit, and ground track is easier to explain in the context of landing.

Recall that in KSP the launch pad sits on the equator and people are just told to launch due east. So they put everything in equatorial orbit, which goes over launch pad every revolution. Launch window? What is that?

See the old classic "Go Play in Space"

(cant recall the link right now though, gimme a second)

Here ya go

http://www.aovi93.dsl.pipex.com/play_in_space.htm

 

[martins]

Here are a few thoughts regarding autopilots:

I agree that using an autopilot that does everything for you at the press of a few buttons will get rather boring quickly and somewhat misses the point of Orbiter teaching a bit about the physics of space flight. However, writing such an autopilot could be quite interesting, so I would encourage everyone to try it (or better, build a team to write one together). And even if you don't want to use it afterwards, it could still be useful for AI-controlled vessels to populate the Orbiter universe.

I don't have experience with the UAP referenced in orb's post, but it sounds like this fits the bill if you really want to use one already made.

I don't know if a new general autopilot project is desirable, but if so, I would suggest a modular approach, where complex tasks ("launch from KSC, then dock at the ISS") can be constructed from elementary subroutines which can be individually tested and optimised (and maybe even specialised for specific spacecraft). This way, modules could be reused, and not each new AP project would have to reinvent the wheel.

The idea would be to have a set of robust low-level routines (e.g. "set spacecraft to orientation x in frame y at time t", "add dV x in direction y at time t", etc.) with a defined interface, and then string these elementary functions together to define more complex manoevers. The low-level stuff could for example be written as a C++ module, exporting its interface to Lua, so that the higher level AP tasks could be written as Lua scripts. We could have a library of scripts for all manner of flight tasks.

Not sure how practical this concept is - just an idea ...

 

[Donamy]

UAP is awesome. I use it in my Jason Project launches. It may manuever a little wildly at time, and not dock the way a real spacecraft would, but it works.