DerekL1963

Thank you. At least on ascent, it's awfully damn close. Just gotta figure out what's causing the nasty pitch excursion (and I have a couple of ideas on that, but need to install the latest version of KSO first). It's overpowered without FAR, but Helldiver mentioned late in development that it would be. (Folks who are flying with MJ and not ending up jettisoning the LRB's late should try the stock MJ automatic launch profile with "limit terminal velocity" enabled.)

Is this an official change in policy? Because it has been touted as being MJ compatible as a release goal until now. If it burned too much fuel in the atmosphere, there's a variety of settings that can cause that. (Mine certainly is not doing so.) MJ misbehavior can be as much if not more due to poor understanding of the settings as to any error on the part of MJ itself. (MJ is not entirely the 'easy button' it's often believed to be, but also a tool that you have to learn how to use.) If you need help in working out how MJ works (as you said it's your first experience with it), I can help or you can ask in the MJ thread for testers. There's still pitch excursions when flying manually w/ SAS enabled, just not as bad.

At the start of (MJ's) circularization burn there is a large pitch excursion and insufficient SAS force to overcome it. Yes, the tank is still on. The pitch excursion also happens with the tank off and burning only on the OMS engines.

1) I'm just a (very) satisfied user, you'd have to ask sarbian or one of the code heavies over in the MJ thread for help. 2) Hah, OK. 3) OK, there shouldn't be a loss of control, but there is. Disabling trim makes it worse. Toggling off the main engines and using only the OMS makes it worse. Adding SAS modules in the cargo bay only delays the onset of instability. When you were testing it with MJ, where was your AR202 case mounted?

Testing with the latest dev build of MJ (#168), using the provided example spacecraft; 1 - MJ does not recognize LRB burnout, LRB's must be manually separated. 2 - There are two Seperatrons missing from the LH LRB, and there are too many/badly placed Seperatrons in general (the LRB's go into a rapid spin very close to and very nearly recontact the Orbiter rather than separating cleanly). 3 - After the coast, at the start of the circularization burn, there is a rapid pitch excursion (trim angle is unchanged from launch) and there does not appear to be sufficient SAS torque to overcome this, resulting in an improper (50 odd x 120 odd km) orbit. Nice vehicle, and one I'm looking forward to using, but a few bugs to be worked out...

You've encountered what is known as the "chicken and egg" problem. You can't plan big missions without a big booster... and planning a big booster brings all the "sky is falling" chickens out of their roosts to complain that the booster has no missions. No.

Those of you who don't want to use them are free to not use them if you wish - however, stop imposing your playstyle on the rest of us. Stop saying that not having OCD and not wishing to play 'hardcore mode' is cheating. As to the removal of "Active Vessel" ending mistakes, I fear that you're badly mistaken Cliph. RT is a complex mod no matter how you slice it, and making it more complex and difficult will not reduce the number of user problems... rather, quite the opposite.

This. NASA runs simulations and so do I... along side my career mode save is a sandbox save where I test vehicles, missions, etc...

Making things much more complicated does not strike me as a very effective way to reduce costs. Nor does adding more things to go wrong do much in the way of minimizing risks, I'm always amused by how people quote ad copy as if it were Wikipedia. No, the math doesn't check out, except for in JP Aerospace's ad copy. There's a lot of "and here magic happens" steps in their plan. The devil is in those details.

Not really, not once the Shuttle's design was frozen it wasn't - that's J.Random's point, and one most often missed when discussing the Challenger accident. The design flaw that destroyed the Challenger was baked into the design and could have happened on any flight regardless of the air temperature, the cold made the failure more likely but it didn't cause the failure. There's only two ways to avoid a Challenger type accident, the first is to redesign the joint back in the early/mid 70's when the joint rotation problem was discovered, or to ground the shuttle once it was understood that the jury rigged fix (the backup o-ring) wasn't working and the joint was still blowing by.

Usually I send orbital probes first, configured to act as relays as well. These usually end up in polar orbit (typically 1000k). The landers are delivered with a transport stage that drops off the lander in low orbit (to save fuel) and then boosts itself into a higher orbit. That way the lander can relay via the polar birds or the (usually equatorial) transport/relay bird(s). Jool is the exception... I send two relay stations *first*, equipped with long range dishes and placed in polar orbit between Tylo and Bop. That way the actual explorer birds only have to carry the lighter and lower power consumption 'Duna dishes'. (A Duna dish will actually get you almost to Jool.... then you swap and relay via the stations.)

That presupposes there is an unarguable, black-and-white, unequivocal definition of 'right'. Sadly, there is no such thing. Sure, but it was also assigned to missions that only it could do. (Spacelab/hab for example.) And it's overcomplexity often relieved it's payloads of complexity. (ISS components didn't need to carry the excess weight and cost needed to support themselves on orbit in transit or to maneuver independently for example.) Shuttle opponents like to portray the situation as black-and-white, with the Shuttle decidedly on the 'wrong' side of the line... but the real world is not so simple. The real world is an endless succession of trade-offs and compromises.

You know, I'm getting very sick and tired of hearing BS replies like this. Whether you believe it or not there *are* people who lack the fine motor skills and/or eye hand coordination to master docking (I'm one of those too). For some it's a simple lack of ability (not all people are create physically equal), for others it's a result of some trauma or disease, for others it's consequence of a full-on disability, for others... well, there are a wide variety of causes. But either way I'm getting very tired of me and people like me getting insulted and belittled by people like you who cannot grasp that. It's not an excuse, it's a daily reality we live with.

That's the eternal dilemma of the mod maker... just how hardcore to make the mod. Playstyles differ greatly.

It certainly seems to... But a question about Mode 2, it reads as if when it can't connect to it's targeted bird(s) it defaults to Mode 1 (but pointed at the targeted bird rather than the planet) and tries to find a bird pointed back at it that is within the cone. Is this correct? Going forward, it's really important that the connection modes and logic be clear and straightforward... that will make it easier to understand, to teach new users, and to troubleshoot networks.

Then you're using an outdated build, try downloading the latest stable dev build. I've never had a problem with it flying around to reach the right side of a port.

I'm wondering when's the last time some of you have used MechJeb's docking autopilot - if it has been more than three or four months, your opinion is badly outdated and disconnected from reality. If it's been less than that, there's a good chance you've either encountered a bug, a corner case, or screwed something up (MJ is not a miracle worker). If you're in the first instance, you really should drop by the MJ thread and download the latest stable dev build and give it a try. If you're in the second instance, you should drop by the MJ thread and let us help you figure out what's going on. Either way, you should watch this video - this what the MJ docking autopilot can do. (Ignore the crash at the end, this is from an as-yet unreleased build and the new "slow down and don't hit something if the user is stupid and specifies too high a docking speed" routine isn't quite working yet.)

MechJeb works just fine... Please post a picture of your ship so we can step through and find the problem. You were given one possible solution in the MJ thread (being sure you've selected the proper "control from here" part) but have given no indication as to whether or not you've tried that.

Cool! Looking forward to the updated version.

Pictures would help... KJR allows you to build less-than-optimal designs (from the POV of the base game) and expands the envelope (again, from the POV of the base game), but it can't work miracles and it does have limits. Nor does it always allow you to get away with no struts even with an optimal design or far from the edges of the envelope.

OCD and over complication ride again... Seriously, KSP is a game first and a simulator a distant second.

Indeed. My basic tanker has a Clamp-O-Tron at one end, and a Sr at the other. (I don't generally use the Jr.)

Now do it with a useful science payload.

Sometimes MJ loses it's little simulated digital mind... maybe it's a bug, maybe it's just the game getting lost and confused. The answer to determining which is which is to quicksave before maneuvering, and to restore and try again if it goes all pear shaped.

Having routinely spent well over an hour setting up complex tests scenarios... (only to have them break and to have to try it again) well, you're going to have look elsewhere for sympathy because you aren't going to get any here. We've all done it because that's the price of admission. If you can't stand waiting longer than five minutes, this might be the wrong game for you.