Amaroq

Most of what I'd say has already made an appearance in this thread, but: 1. I'm just back after almost a year away, and the game is seriously as entertaining as it was the first time. Don't be afraid to "let go" and "come back". 2. Sandbox is all about self-direction, so pick a challenge orthogonal to anything you've already done, and go that direction. (Spaceplane? Kethane mining? Manned Jool-and-return? Eve or Laythe aerodynamic plane?) 3. Performance can be solved, I'm on a pathetic machine as well but my launch-to-orbits are about 7-10m. Suggestions include: lowering graphics performance, exploring your machine's hardware settings, texture compression mods, that welding mod, uninstalling your least favorite mods, reducing partcount. 4. Launch a couple dozen missions at once. That turns the game on its head, putting you in a "react" position as things arrive at their destinations at different times, with different emergencies and needs.

Ninja'd, by a day and then some, but that's exactly what I was going to say.

Kurja, I'm not sure I see the bug yet. Screenshots from your O.P. clearly show that the vessel, not the station, was the active vessel when you had the issue. Screenshots from post #17 clearly show the station as the active vessel, but a long ways away (orbitally) from Laythe. The spec is "shows the encounter only when your vessel is within one orbit of the encounter", which I don't believe is the case for that screenshot. Frustrating, for sure. Definitely something I'd expect out of any kind of "Mission Control" mod or Squad-implementation. But I'm not sure its a bug for map mode ..

Control surfaces go very well at the bottom of "tail fins", if you're using those parts -- for a F.A.R.-compatible large rocket, you may get some success out of tail-fin + control surface near the tail of the first stage, plus winglets near the top of the second stage; use the F.A.R. setup screen to limit the total deflections so you don't get oversteer.

One of my favorite uses of SRB's has been to calculate the burn time I can expect from a given liquid fuel tank/engine setup, and then couple the SRB's with the matching burn time to them. This is useful if my build has reached a good dV but insufficient TWR .. In practice, I tend to be close on TWR already, so I select an SRB with a longer burn time, as then I can throttle-down the liquid ... net result is, the same upper stage decouples at a higher altitude, done. For example, I've a 6X asparagus-build which uses the radial-mounted KW "Globe" SRB's, staggered such that the shortest-burn SRB's are on the first asparagus-pair to drop, with the middle-duration on the second pair to drop, and the long-duration SRB's on the final pair. Its a bit of a hell-beast to control on the way up, but it worked out pretty well.

O.P., why is this not a Poll? My personal answer is: I'd be perfectly happy with a "Life Support" variable -- for my personal older career save, I'd basically overloaded "Electricity" for it by vastly increasing the electricity requirements for all manned pods. My story-explanation was that the electricity is being used for scrubbing CO2 back to O2 and for reclaiming & sanitizing waste byproducts.

Excellent. I've been thinking of exactly this -- I've got a fabulously enjoyable 0.18.4 save going on, with hand-edited mods of publicly available mods (I was trying to pre-invent "career mode"); as some of the mods are no longer supported, there's really no way I could upgrade it. So, thank you, Vanamonde! OP, you may wish to update the thread status to "Answered".

Heh. Yeah, my answer would be "Install F.A.R. Anything that stays airborne is not-cheaty." Note that I have yet to master "staying airborne" with F.A.R. ...

Not exactly. (Apologies, Kasuha, that was in response to Philo, not to you) You will accelerate if the force from thrust exceeds the force of drag plus the force of gravity. So, if your TWR is 1.1 but your force-from-drag is 0.2, you'll wind up decelerating due to drag. (Net upward force = 1.1, net downward force = 1.2) The specific TWR you'll need to accelerate, obviously, will change depending on whether you are using the stock physics or the F.A.R. aerodynamics, the thickness of the atmosphere, your distance from the planet, and your current velocity. (Note that the wiki-listed "terminal velocity" is not applicable/correct if you are using F.A.R. instead of stock.) For a F.A.R. launch, I tend to launch at maximum thrust to about 105m/s @ 1000ft, and then throttle back to about a 1.2 TWR, which is sufficient to continue accelerating right around enough to stay fairly below the F.A.R. terminal velocities without exceeding it ... but that formula would be way off for a stock launch.

DMagic - you rock! From "I'll run with that" to "I'll release that" in ... 2.5 hours?? Your username is well deserved! Regarding N auto-saves, maybe N is configurable by mod .cfg?

To the O.P.: I can dock now, fairly easily. But it was a heckuva skill to master. My very first attempt at docking, I didn't consider orbital inclination, so I wound up trying to "dock" two vessels which were inclined about 135 degrees off from each other. (Hint: it doesn't work. ) After I got orbital inclination down, I started using Maneuver Nodes to get myself in position for things ... but then I found that I could make close fly-bys but not quite get to docking. One particularly frustrating time, I got within 7m, but ran out of RCS and found myself drifting away. Eventually, I got to the point of bumping and thumping, but eventually getting it done ... and man, that first success is one of the best feelings the game has to offer! And now, I can plot a maneuver node to within 0.2km, zero out my relative motion, and bring it in like a pro. It just takes time: its a skill one has to master. The best piece of advice I can give is, "quit trying to do anything in Low Kerbin Orbit". Docking is much much easier with a larger orbit (because the vessels are curving more slowly). Seriously, practice docking by setting up a circular orbit at 1000km instead of 100km, and you'll get the hang of it much more quickly.

Nice, thanks for the tip. I'll check it out next time I update to a recent build.

If all the issues could be sorted, I'd give a resounding "yes" for this - Majir, not for "attention" but for "sorting". I just came back to the game after a couple months' absence, and sorting through the mammoth threads for FAR, RemoteTech and Kethane was quite the task, especially with several of my favorite mods switching authors whilst I was gone The biggest problem I'd see is that this seems it would make a "cool kids" distinction between mods. Who is to say which belongs in which category? I know I'd be upset if some of my favorites weren't "included", and I don't have anywhere near the emotional investment in them that the authors do! .. Edit: .. Giving this a little more thought, I note that there are 25 mods in the first five pages with 90 or more pages worth of replies, so that might provide a decent marker for "mods which are generating enough traffic that they may warrant their own forums" Also, we can generalize the question, from "create more forums" to "As a community, we're clearly using each mod's thread for a purpose to which a single forum thread is not the best solution. What would a better solution be?"

I'm in much the same as Talisar, only I've been using KER exclusively for both building and in-flight data. (In part because it does let me customize what is displayed, T) I tend to use a combination of Maneuver Nodes, the RemoteTech Flight Computer, and Kerbal Alarm Clock to take care of my "auto-pilot" needs.

Hell, I'd like that in general, DMagic. Periodic rolling save, maybe "on load"? Not to remove the risk of failure, but to remove the risk of "Oh, my toddler just hit space bar, busting up the staging of my Jool mission and leaving it on a fly-by with no chance of making a stable orbit ..." Just last night I lost a perfectly-lined up intercept by touching the "Shift" key when I thought I'd established my mouse and cursor in a different window.

Agreed. I've gotten in the habit of jumping out to the Launch Pad and using an action group to "deploy all" to ensure I've got tolerances; that can be quite repetitive!

Personally, I use KW Rocketry as well, but the Fairing Factory is an external utility that lets you custom-build your own fairing pieces to your satisfaction.

There is no in-game UI which would let you change the root part of the ship. In my opinion, the subassembly mod is really your best bet for what you're trying to do. If you are adept, you could probably learn to do what you want by manually editing .craft files -- they're basically XML files, which are easy enough to read, and even to modify. If you decide to go that route, I highly recommend doing it on a very simple structure, maybe four or five pieces total, rather than starting on your detailed and polished base.

If you care about your Kerbals enough to be mounting rescue missions, you'll love the Kerbal Crew Manifest mod.

You want it to work with the tiberdyne part, right? So you'll need to edit the part.cfg of that part. Find the lines: INTERNAL { name = GenericSpace3 } and change them to INTERNAL { name = GenericSpace3TTUPGRADE }

Uhh .. keeping it a bit simpler: Make sure your intersection with Moho's orbit is a perfect tangent. If, for example, you still have a difference in inclination, or if your periapsis is inside Moho's orbit but you have an intersect on the way "in" or the way "out", you're going to need too much delta-V. If, instead, you've got an inclination difference of no more than 0.1 degrees, and the projected intercept is at your projected solar periapsis, and you make a little adjustment or two as you get close to ensure that your Moho periapsis is low to the surface (< 20km?), you should do just fine .. as Eric S. pointed out you could brake before entering Moho SOI if you have a really low TWR. Those changes have literally made the difference between a braking burn requiring 5000 d-V and requiring about 2500 d-V for me -- they feel really "slight" in terms of what your solar orbit looks like, but they make a big difference.

I think that's about right. If you want to go for the "seat of the pants" style you got to the Mun with, you can set yourself up for intersecting orbits by burning prograde to get to the outer planets, or retrograde to get to the inner planets. Prograde - center the map on Kerbin, zoom out a little, orient the map so that you know precisely which direction the Sun is. Assuming a prograde equatorial orbit, start a burn in the prograde direction (90) some time between late afternoon and midnight. Your "escape trajectory" from Kerbin should be prograde and outward. On the map, zoom way out until you can see the orbit of your target, and watch until the orbits intersect. Retrograde - same procedure, but start the burn in the prograde-to-Kerbin direction (90) some time between pre-dawn and noon, so that your ejection is retrograde and inward. Similarly, zoom way out until you can see your orbits intersecting, then cut the burn. Once you've got crossing orbits, you need a second burn at the ascending or descending node to match the orbital plane of your target. Once you reach the orbital intersection, check out your position and orbital resonance with your target .. you can usually make a single burn that will set you up for a rendezvous "next lap", but sometimes patience and letting several laps pass will serve you better. .... For a middle ground, you can use Kerbal Engineer Redux, which will calculate the correct ejection angle for you -- rather than just burning "sometime between dusk and midnight", you'll get a "start your burn at 119.823487 degrees from prograde" .. and a marker telling you your current angle to prograde. Easy enough -- this should help with #3, as your orbital intercept distance will be fairly small. If your burn was perfect, you'll actually intercept, but generally, I find that I can make a slight adjustment at the ascending-node/descending-node burn to achieve an SOI intercept by either adjusting radial-in/radial-out or adjusting my prograde/retrograde node in addition to the normal-plus or normal-minus adjustment. .... Alternately, ORDA or MechJeb can just about handle it for you. .... If you'd rather get super into the planning and firing off the mission, then I suggest olex's website, http://ksp.olex.biz/, a.k.a. Interactive Illustrated Interplanetary Guide and Calculator for KSP. It'll give you the data you need to plot a minimum-delta-V transfer -- the Phase angle, the Ejection angle, and the delta-V you will need for your ejection burn -- but its up to you to apply that in-game. You could calculate angles by eye on the Map view, or you might use Protractor, Kerbal Engineer Redux, MechJeb, or ORDA to assist you. You will need to timewarp forward to that correct Phase Angle (planetary alignment). ---- Personally, I tend to have multiple flights going, so I use "Kerbal Alarm Clock" to let me know when they're getting to their destinations -- or when the next burn is needed.

In my experience, which docking port you click on matters - I'm not sure if that's a general true-ism or not. To detach a vessel from a space station, if I click on the station's docking port, nothing will happen. If I click on the docked vessel's docking port, the vessel will undock successfully. This is, I think, only a problem when you have two or more vessels docked to a single central station.

The specific folders you want to keep track of are: Parts PluginData Plugins The "Vanilla" folders for Plugins and PluginData will be empty, no problem. Note, also, that your save game is going to depend on the mods you have installed -- basically, if you delete a part, any flight in progress which utilized that part may become unusable.* (See footnote 1) This can also be true if you are adding a mod which changes the vanilla parts -- for example, if the part.cfg now includes a reference to a module, but that module's state isn't specified in the save-game, the ship isn't going to load. So, honestly, I've found it much more valuable to back up the "persistent.sfs" file from my save game folder on a regular basis than it was to back up the vanilla parts folder. That said, if you're going to get into modding, you'll want to make sure you develop your mod against a pure-vanilla install. Footnote 1 - in my experience, what you get when you load a flight that included a deleted piece is a partial craft consisting of a chunk of contiguous vanilla parts that were added after the deleted part .. as that means its probably missing any command Pod, its pretty useless and "End Flight" or restoring the piece is the 'right' choice. If the missing piece was non-structural, it is possible to massage it back into shape. If, instead, you delete the .DLL from the Plugins folder, but leave the Part in place in the Parts folder, you'll typically get the flight to load, but )

@Atanvaryar, thanks for the response - please take my suggestions as just that, observations which you may accept or reject at your preference! Your responses on #1 and #3 are pretty much what I expected; you'll find a lot more user-adoption, I think, once you have #1 sorted. Re: #2, yeah, I couldn't see a quick way of figuring out diameter from .cfg, myself, which is why you've gotten an earlier break on this than I would have. What I was imagining was a two-step process, e.g., the application makes a "best guess" and generates some simple format (tab delimited? comma delimited?) which maps "from" and "to", probably sorted by the resulting "to" name, and then allowing the user to edit as they see fit before applying. More "hands on", I guess, aimed at letting the user really get their hands dirty to create the sort order they would prefer. So, if I wanted to sort by diameter, that'd be up to me to accomplish in my edit of the resulting names. Re: #4, I think ISA MapSat should be Science but wound up with 2 or 3, there's a couple others like that. I know they get into a tab correctly, just not necessarily the right tab. Since your goal is supporting people with a lot of mods, "correcting" a few of the "better known" mods might or might not fit in scope.