Blackstar

He does graciously make the source code available for his plugin, however. So you could rip out all the parts of it that you don't want, like the exploding clamps and increased physics distance. I'll probably end up doing that for myself at some point, since I only use the docking camera and don't want the "Lazor Powered" config panel on my space center screen. I wouldn't distribute it, though, since his license forbids distributing derivative works, and it would be a gross hack at best in any event -- not the kind of thing I'd feel right about posting.

I've noticed that having the camera in Chase mode (say, from a recent docking maneuver) causes the camera to spin wildly when trying to move in EVA. Switching to Auto or Orbital fixes it.

Hmm,I thought I had the latest (post-April 26 at least), but I'll double check. Thanks!

Aha, that's it in one! I did just recently install MJ2.07. And here it is: MechJeb2/GuiUtils.cs public static void CheckSkin() { GUI.skin = null; if (GUI.skin.name == "LazorSkin") { Texture2D tex = new Texture2D(64, 31, TextureFormat.ARGB32, false); tex.LoadImage(Properties.Resources.default_gui_window); And guess what is in the PNG file called default_gui_window. At least now I know where to fix it, thanks!

Um, this may be a dumb question, but is there any particular reason that my docking camera windows now have a nyan cat and rainbow as the title bar? I didn't update or change the mod at all...

Everything having magical gravity plating is more of a practical concession though. As much as some movies/shows would like to be accurate, it's not really feasible within budgets for every single scene to be an effects shot in order to simulate zero/micro gravity. Plus if they did it cheaply with wires, then people would just complain that the actors' hair was clearly still being affected by gravity.

I've never gotten that to work, no matter what I try on the map screen. However the Haystack mod has a 'fly' button when selecting targets from its list that works, and is the only way so far I've been able to 'fly' debris to see what it is.

3) Run out of monopropellent halfway to the docking port.

Right-clicking on your own ship's docking port and selecting "Control from here" will make both the navball and the readouts on the docking camera relative to the orientation of that port. Though be aware that it will also change your RCS translation controls to be relative to that axis as well, which might be surprising if you're not expecting it. Quite handy for docking using ports that aren't on the nose of your ship, like ones mounted radially on the side. Unless you're talking about the case where you want 'up' on the ship to match 'up' on the target port, but your own ships port is rotated differently. Of course in that situation, the camera view will be rotated and most likely confusing. I learned very quickly after installing that mod how to tell which direction 'up' is on docking ports when placing them.

When the show Andromeda started (yeah yeah, I know), it had a lot of potential, and actually made some effort. Aside from magic artificial gravity fields, which also doubled as structural integrity, and quantum slipstream ("It's not the best way to travel faster than light -- it's the only way."), a lot of the physics and tech were based on scientific principles. Things like no FTL communication; courier ships for long range. Communications delay based on the speed of light while at range, and anything needing high bandwidth or security uses a point-to-point laser but requires line of sight. Kinetic-kill projectile weapons and guided missiles. Remote operated sensor and attack drones for medium-range (more than a light-second away) combat, which was much preferred to being up close and personal. Non-FTL travel way more powerful than current tech, but based on PSL (percent of the speed of light), and bad things happen if you get too close to light speed. Inertia being a factor in sublight maneuvering, as well as gravity and relativistic effects playing a big role in the first few stories. Then after the first season they forgot all of that and it really did become Hercules in Space. Blech.

Then you want Kerbal Engineer Redux. It works in the assembly building and will calculate before you launch how much delta-V each stage has. There's also an in-flight module that updates the info as you go similar to MechJeb, but without any autopilot or planning capability.

Since neither gravitation nor acceleration seem to register on the instruments, most likely it's some sort of localized warping of space itself. Legend has it that the Kraken makes its lair in a pocket of space folded in on itself, almost impossible to enter without being ripped to shreds by conflicting forces.

I resisted it for a while, not wanting to 'cheat', but after performing yet another mind-numbing space station rendezvous I finally caved and gave it a try. My justification is that autopilots are very much a real-world thing. As are navigation computers that can optimize things better than a human can. So far, I'm loving it. Worth it alone just for the info displays, and the course plotting -- especially things like timing a launch so that you end up close to an orbiting target. While it can do some things completely automatically, it's best to treat it like a co-pilot. It handles small craft fine, but doesn't seem to be very good at piloting slow-turning behemoths. Often it plots a course that's so tight that it can't turn the ship toward the next maneuver node in time, then has to adjust the burn. Then it doesn't quite make it, and wastes a ton of time turning and chasing the node to try to get that last 0.4m/s of the maneuver, putting it even further behind for the next one. Auto-dock is nice to be lazy, but it wastes a ton of monopropellant making all the tiny adjustments. If there's any wobble in the ship at all, it tends to overcorrect and make the oscillations worse. So I mostly use it to help get lined up and do the final approach by hand. The RCS balancer in 2.x is a really good idea, though not perfect yet. Honestly I'm amazed at the ascent autopilot. Most real world autopilots have the benefit of knowing what vehicle they'll be used in and can be tuned to its particular performance characteristics. MechJeb manages to launch completely arbitrary rockets into precise orbits, and can even automatically separate the stages at the right time. I'll still manually control ones I'm testing designs for, but for repeated launches of stuff like resupply ships it's a real time-saver. It's totally a personal preference thing, though. There are things I'll always do by hand, and there are mods I won't use because they're unrealistic (Kethane; Quantum Struts) regardless of how useful they might be. So if you want an early 1960s experimental space program feel instead of a somewhat refined 1980s space program, then I'd avoid it.

(to vindianajones) To do this with maneuver nodes, just add one at the ascending/descending node, whichever is closer. Rotate the view and drag the pink handles up or down to align the orbits until the ascending and descending nodes rotate 90 degrees from where they are. You'll know you're doing it right when the AN/DN markers start to move very fast and you have to use a light touch on the maneuver node handles to keep them under control. Hovering over one should show an inclination of either 0 or NaN degrees. The blue marker on the navball will then show you exactly which way to burn and when. Somewhat of a tangent, but I find it delightfully counter-intuitive that if you're on the same orbit as your target but "behind" them, turning retrograde and burning away from the target will cause you to eventually catch up.

It's not even what I'd call astronomical. Space is vast, yes, but once gravity is in the picture you're limited to orbital tracks which significantly reduces the possible places an object can 'park' in orbit. Any object at a given altitude has a chance of eventually colliding with another object that crosses the same altitude unless their inclination and eccentricity is identical. Once you have hundreds of thousands or even millions of objects, then the time required for such a collision to be likely drops dramatically. That's true. One way I like to think about it is to remember how much rocket fuel had to be burned in order to get something to orbital velocities. Now that's nowhere near 100% efficient, but a chunk of that fuel got turned into kinetic energy, just waiting to be released when it hits something that's not going as fast (or in the same direction).

I tend to use the tri-coupler method as IMO it's a little easier to get lined up during docking than the quad, plus you can build one on the fly and all the ports will be in the right spot. Both have the advantage of limiting the possible docking orientations, which is nice for building things like space stations so you don't have to worry as much about having your modules turned slightly and not aligned. A workaround for this is to build one part normally -- starting with the coupler, then adding the docking ports second. I save that to subassembly loader as my 'A' port. Then build another, placing a docking port first (flip it backwards and stick it to the side of any random object). Place the tri-coupler on top of it, then add 2 more docking ports. The second one will have the first docking port as its "anchor" and only node that shows up when placing it. I save that one as my 'B' port. When building a ship, use 'A' ports to place on the central structure -- the back of the tri-coupler will be your attachment node. Then grab the 'B' port and you'll be able to place its 'primary' docking port snugly attached to one of the ports of your 'A' group in the VAB. If you did it right, upon launching the ship all 3 ports will be magically connected even though you only had one node connected.