phoenix_ca

*shrug* Piracy is just a fact of life. It's in human nature to share things. And yes, it really goddamn sucks to see your hard work pirated, but really, those sales were already lost. (Not so much "lost" as "never existed in the first place".) Adjust your projections accordingly. The more compelling reason to avoid torrents is the requirement of specialized software (no one-click from the browser and BAM! spacy-awesomeness), and as mentioned, that some ISPs (idiotically) block P2P traffic. (I say idiotically because the user's behavior is their own business. A phone company isn't liable for when someone uses a phone to order a murder, robbery, riot, or otherwise, so why should an ISP be liable for a client using their cables to nab software? That and BitTorrent is one of the most progressive and efficient means of disseminating large amounts of data to many people at very low cost. Our networks would probably collapse if all those TBs of data were sent from server-client.) In short, the "easier to pirate" argument is invalid, as the increased difficulty of getting the software via more conventional means is trivial, at best. DRM is similarly trivial in it's application, unless you go balls-to-the-wall with it like Ubisoft does, and at that point, you're degrading the experience of your customers, so it shows a rather strong lack of regard for the people paying one's salary. My favorite part of KSP: When I got my hands on it (and I won't say how), I wanted to pay for it. I saw the potential and just said "hell, take my damn money already". And ta-da, here I am, happily playing, serving as a guinea pig for the devs to work out any bugs and make improvements, wishing I wasn't a broke student so I could afford to pay more.

Struts will help with stability, but they won't cancel any angular momentum that's imparted to the rocket. Could you perhaps post a picture of the rocket? I've had some serious roll issues myself. My successful designs had...fewer parts? Maybe that's it? Ish? I'm not sure about that at all.

All the time. Most importantly, I can set something to launch, then go make bacon.

I also got a Logitech Attack 3. Got it a few years ago (I wanted to revisit Freespace 2...yeah, I totally still play that game). It's a good balance between capabilities and price (and Logitech makes devices that last...my wireless mouse is still going now, after...uh...I forget how many years). That said...I don't actually use it. I'm so busy doing the more meta stuff like planning the mission, where and how to burn, that I just don't bother with much manual piloting, and when I do, I hit caps-lock and RCS serves me well.

Wow. That's...that's awesomely insane. Took me a bit to realize what they were standing on... Speaking of which, that's an incredibly small radius for a sun. O.o My fifth geostationary satellite, part of my COMSTAR project that will provide long-range telecommunications from Kerbin to the outer planets. (Using the RC mod.) This gave me an idea for a similar photo.

Don't worry about it. It seems the concept of fair use has gone the way of the dodo in these times. This isn't a mod that steals from another mod at all. It's a derivative work that adds value to the previous one, by updating it so that it may be used in the original capacity it was intended for. The internal cabin tweak is a further enhancement. Honestly, you'd have to be somewhat insane as a creator to have ruffled feathers over improvements to something you made like this.

Bah, that's not an excuse! I did a report on ion-propulsion drives when I was in grade four. (Uh, actually a speech, and my poor classmates were terminally bored, but I didn't really care. Ion propulsion is just plain nifty.) Your alternate choice is to wait until people with more knowledge of programming and orbital mechanics come-up with a solution that allows very easy interplanetary transfers. However, I'd encourage you to at least try to learn the basics of this stuff. It's a good challenge, and it will give you a greater appreciation of the things scientists on the ISS, and at the world's various space agencies, do every day. All to advance science...or get you your satellite TV.

Particularly large rockets that depend on certain pieces, like say, struts, for support, will probably fall-apart on the pad. The number of parts required for this to happen is proportional to the speed (how many physics calculations per second) the computer's fastest processor core may achieve (KSP is single-threaded; it only uses one core at a time). In other words, slower processing cores will be able to handle fewer parts, before the engine starts dropping certain calculations in order to maintain frame-rate such that the game engine continues at 1x speed. The first (or one of the first) things to go are strut calculations. I'd imagine that time-dilation, similar to how EVE Online handles extreme loads server-side, would help alleviate the problem so that users (at least patient ones) with slower computers could still get large rockets off the ground (if they were patient enough). Though it's anyone's guess if Squad has such a thing planned, or if they even have ability to do it (limitations of the engine, excessive development time for such a feature, sheer difficulty of adding a throttle to your program, can all be limiting factors).

I've never even tried this before, but here's a suggestion: Pay very close attention to the position of the encounter with the orbital body's SoI relative to it's orbit (either "up" or "down", that is, normal or antinormal). The goal is to get your injection in a position where it intersects a polar orbit, or is as close as possible to doing so. You can make small (very, very small) adjustments to it's location relative to where the body will be about midway there (most efficient). Once there, it's a matter of adjusting the inclination to make it 90 or -90. Note that burning normal or antinormal to the body's orbit probably won't suffice in itself. You'll also need to burn a bit "left" or "right" (That is, RAD + or RAD - ) to keep your encounter within the target body's SoI

There are a lot of different components in the Kethane mod. What, specifically, are you trying to do?

Time to learn?

The title says it all. I would put this wee guide on the wiki, but the wiki is rather...restrictive. I also couldn't find any simple guides like this for KSP anywhere after a lot of searching, so here it goes. First off: No complex math. You don't even need to know how to multiply or divide. The only skill you need is basic addition and subtraction, and an ability to read the data MechJeb gives you (yes, you can fly the thing yourself the entire way, though I can't imagine why anyone would want to do this eight-or-so times without using at least Smart A.S.S., which is what I use for all my orbital maneuvers for this after the ascent. It will get repetitive the more satellites you put up). Second: I say geostationary because I'm comfortable with it, I'm not interested in arguing semantics, and geo is from the Greek for "earth" though typically in the sense of "land" or "ground", not specifically this planet we meatbags call home. Third: I assume here that the reader has a firm grasp of orbital maneuvers, including phase changes (adjusting the altitude of an orbit), plane/inclination changes, basic ship piloting, and perhaps even a cursory knowledge of what all the lovely buttons do in MechJeb. There are tutorials already for all of this, so I'm not going to cover any of it. Finally: The goal of this tutorial is not just to describe how to get a payload into geostationary orbit, but how to get it at more-or-less a precise longitude with a minimum of fuss. That is, one burn from a parking orbit to GEO, or close to GEO, with minimal adjustments if the user wishes. Step 1: Understand What a Geostationary Orbit Is ...and the difference between "geostationary" and "geosynchronous". Really, I can't do a better job here than Wikipedia, and for the sake of brevity, I won't go into detail. Short version: a geostationary orbit will keep some orbital body above the same longitude at all times. Put more simply, to an observer on Kerbin, a satellite in geostationary orbit will remain stationary in the sky (well, hopefully, or at least with so little deviation it's unnoticeable). A practical example: Geostationary satellites are used to provide streaming data to large numbers of clients, such as in the case of satellite TV providers. The simplicity of using a simple receiver that doesn't need to track the satellite far out-weighs the cost of putting a satellite in GEO. Now, Kerbin's GEO altitude is 2.870Mm. Get a piece of space junk up at that height, such that its apoapsis and periapsis are both at 2.870Mm, and you have yourself a GEO. Step 2: Build a Rocket Anything that can get your desired payload to an altitude of 2.870Mm above Kerbin will do (that's Mega-meters, or 2.870 million meters). Test it out with your payload, see if it can get you there in one shot, with fuel and an engine to spare, preferably, for fine-tuning; I have a soft spot for the NERVA for this task. An easy way to do this is to just set MechJeb's ascent autopilot to 2,870km and let it go. If you get your payload there with fuel to spare, you're in good shape and have enough delta-v to get your payload there. Note that any rocket that has enough delta-v to escape Kerbin (e.g. Mun or Minmus launch vehicles) will likely have enough delta-v to get to a stable GEO (the circulisation burn could mess with this; I haven't done any specific math on this point, nor do I plan to). Step 3: Launching I've seen more than a few mentions of GEO constellations requiring precise launch timing, as one would use for a rendezvous with a spacecraft in low-orbit. This simply isn't the case. If we consider the case of a direct ascent to GEO, and a similar ascent profile for each launch, each satellite will end-up in roughly the same position because, relative to the rotating surface of, the final point of the ascent hasn't moved. So, the bottom line? Launch whenever you darn well please, as we need to fix this later anyway. This first launch is a dry run. We're out to collect data, and little more, you may even wish to do this in a test save if you're as OCD as I am about not littering space more than necessary. Launch your vehicle to a low-altitude of your choosing, just write it down. This is where all subsequent launches will be going. I usually go with 200km (eventhough this has the mild downside of being a little slower because of time compression limits...I don't really mind). Once you are at your parking orbit (you did remember to write that altitude down, right?) and inclination is at 0 (or within a few degrees), open MechJeb's surface information window. At the very bottom you will see Longitude. This the the key piece of data we'll be using. Step 4: Transfer Wait until your craft is approaching 0 degrees longitude. Then commence a burn to enter a Hohmann transfer orbit with apoapsis at 2.870Mm. Warp to the AP, then bring your periapsis up to 2.870Mm as well. If you are using a relatively low-thrust engine (or even a high thrust one; you'll need to expend quite a bit of delta-v to circularise this orbit), you may end-up burning for so long that your apoapsis begins to rise again. That's okay, get it close, we've got our data. Note the current longitude. We'll call this x. And for the sake of actually giving an example, let's say we arrived at a new longitude of 138 degrees. Ta-da! That 138 degrees is very, very important. I hope there are lightbulbs going off now... Step 5: Interpreting What the Heck I Just Told You To Do Here's where the math comes in. The beautifully easy, peasy math. Let's say that we now want to deploy a payload such that when it's in GEO, it's (approximately; done right this method should get one within a few degrees longitude) at 0 degrees longitude. We simply do: 0 - x = longitude of burn. In this case, we get -138 degrees. So, following the same pattern as our test flight, exiting our parking orbit of 200km at -138 degrees longitude (or at least, starting our burn there) will have the satellite arrive in GEO on or close to a longitude of 0 degrees. To further illustrate, here's a table showing the (exceedingly simple in comparison to most math stuff with orbital mechanics in KSP) math that gives us the longitudes to burn at for all eight orthagonal points, giving a nice, evenly spaced set of 8 satellites (negative values used so they correspond correctly to longitude as displayed by MechJeb): 0 - 138 = -138 45 - 138 = -93 90 - 138 = -48 135 - 138 = -3 180 - 138 = 42 -135 + 138 = 3 -90 + 138 = 48 -45 + 138 = 93 And unless I completely messed-up (I'm a little sleep-deprived of this writing) that should make sense. See? I keep my promises. Not so much as a multiplication sign. But wait! There's more! Step 6: So You Don't Know How to Add No problem! All you need to know is how many degrees you want to separate your satellites by. Then just initiate your burn from points that are equally spaced by longitude. So if you don't really care where exactly your satellites end-up above Kerbin, you could simply do transfer burns at 0, 45, 90, 135, 180, -135, -90, and -45 degrees longitude. Just make sure you do the same thing with the same rocket every time. Changing the throttle, thrust (i.e. engines), mass, anything, will throw everything off, requiring you to go back to Step 3 for that rocket. When you're finished, you're free to correct the orbit as you normally would, by reducing periapsis, increasing apoapsis, and returning, burning normal or antinormal to adjust inclination, etc. I've managed to get within a few degrees longitude of my intended destination (about a degree or two off; close enough for me), with eccentricity of 0.0003 and inclination of <0.1 (which is the standard margin of error for inclination of real-world GEO satellites). I hope that made some modicum of sense, and that it's somewhat helpful. I've found this to be an exceedingly easy way to have a nicely-spaced constellation of comsats around Kerbin. You know, for Kerbin TV...or whatever they do to rot their brains.

The devs are planning to add docking as a feature at some-point. That would hint at the ability to, well, dock stuff. And with docking two little things comes one bigger thing, and so on. In fact, it's already on the planned features list.

Amethystium.

The best rendezvous system is in between your ears (it's that mushy grey thing that zombies find delicious with a side of toast, possibly with necrosis jam). ORDA will help you a lot, once you get within visual range. Warp clamps are awesome. But as for the actual getting there part? Short of some really fancy math, I suggest you do it as the real astronauts do: Slowly, methodically, with a great deal of patience.

...378 parts? O.o As soon as I get past 240 things tend to start exploding on the pad (meaning KSP is dropping strut calculations immediately in a desperate, failed attempt to save itself from laggy doom)...and I'm using an i7. O.o

The other problem is perspective. Viewed from the right perspective, any ellipse can look like a circle, if the viewer is deprived of depth-perception (which we are; our screens are flat...and KSP doesn't output stereo images). That, combined with the small eccentricity, makes it quite easy to see how one might mistake it's orbit as circular. The distortion caused by the field-of-view of the game's camera probably doesn't help either.

I'd recommend Kosmos and MMI.S. MMI.S has some really nice small accordion-style panels that provide enough power to keep the pretty satellites that come with it humming along smoothly. Kosmos' solar panels are freaking huge; great for large ships/structures. I'm thinking of slapping some on to a DSM explorer vessel and using them as a power source. However, if you install the Kosmos parts pack (any of them), be sure to remove the PowerTech and MuTech plugins from the archives before installing, or you're liable to overwrite your more recent versions. That will result in a "part not available in this version of KSP" error for any part using PowerTech, and will revert MechJeb back to a previous version (I think the Kosmos SSPP is packed with v1.9.0 of MuMech; it's on 1.9.2 with a 1.9.3 beta).

If you haven't already, edit your game settings.cfg file so that CONIC_PATCH_LIMIT is at least 3 (4+ preferred, I'd say, but each step requires your computer to do more work), and possibly CONIC_PATCH_DRAW_MODE to 3 (at least that's my preferred mode as it is less taxing on my brain-meats). As for telling you the ejection angle required to reach a planet, try this. You still have to mash your brain a little when it comes to figuring-out what your current ejection angle is though; just think of it as an angle relative to Kerbin's (or whatever celestial body you're orbiting) orbit around Kerbol, not your own orbit around Kerbin. Ish. I think. Don't quote me on that.

This is a semantic argument. It's an ellipse, not a circle. A circle would have the sun at both foci. Anywho, that's a big "nucking futz" in my planning. Blasted ellipses.

Curious. Okay, didn't know that; thanks. I've been using KSP Mod Manager to manage all the bloody mods I have installed (it's quite the handful...or fifty), so not surprising an installation error like that slipped by me. >.< I wonder why it doesn't copy the resources folder though. That's...odd.

Yay for draw mode 3! \o/ I wonder at why it isn't the default draw mode. It certainly is the easiest on my grey-matter ("tasty brain meats").

Indeed. Great for testing, it is. As for your issue though, depending on what your doing, you might be able to mitigate that by changing the ascent profile. I try to adjust MechJeb so that it only starts a gravity turn after the boosters have been released and sent crashing on some poor Kerbals' heads (I'm fairly certain the reason parachutes can be triggered after the stage is separated is foresight on Squad's part; I bet recovering boosters later will save money in career mode). You can also help mitigate the issue by taking manual control. Radially-mounted boom-sticks can usually separate just fine if the rocket is traveling at an angle; the issue comes from MechJeb continuing the turn. Disengaging, then re-engaging the ascent autopilot at these stage separations can save your rocket from scraping metal. (Come to think of it, it'd be really handy if MechJeb stopped a gravity turn for a second, maybe two, at each stage separation.) Pretty much how I use it too. Though I prefer to let it perform burns for me for fine-tuning. I can't circularize an orbit nearly as well as it can. That and I don't see why I shouldn't avail myself of so much lovely data. I love math; that doesn't mean I want to play a game that requires me to have a spreadsheet next to me to calculate what to do next.

Erm, do you mean that Duna has some measure of eccentricity? A circular orbit has an eccentricity of zero; anything between 0 and 1 is elliptical. See this page. If planetary orbits are also elliptical, not to mention having different inclinations...well, Squad sure isn't making interplanetary flight a walk in the park. O.o

As awesome as this megathread is...it'd be a lot more useful if we had an index for these on the mechjeb wiki. Good stuff inevitably gets buried in a thread. Edit: After further reading, I realize that I hadn't realized how young Autom8 is. Well...kudos on the hard math work peoples. I look forward to being able to run a script that sets-up a rendezvous in a single burn at some point. ...of course at least we can all be thankful that we're dealing with simplified two-body math, not n-body math.