impyre

Yep, but since the graph demonstrates the linear relationship that ISP has with dV, you can take a pretty good guess at what it would look like. At an ISP of 300, and a fuel mass percentage of about 70% of gross vehicle weight, you're looking at somewhere around 3600-3800 m/s dV. Since it's linear, just solve for slope. 3600/300 = 12, so an ISP of 800 would be around 12*800, or approx. 9600. Again, just an estimate. The actual calculation gives 9439.15 for the given ratio. Also, if you drop weight on the return trip this will change the ratio further. The fact that the nuclear engine's ISP is soo much higher than the others is what makes it's weight relatively inconsequential by comparison. Also, I mistakenly posted this in the wrong forum. If someone takes a mind to move it, please do. Thanks, and sorry. - - - Updated - - - I'm actually putting together another graph that labels some points for common KSP engines for a few vehicle weights. So if you have a 20t vehicle, you can see how each engine compares in terms of how much mass it contributes to the vessel mass and how much difference its ISP makes. This should give a better feel for the tradeoff, and how it is affected by the ratio between the engine's mass and the mass of the rest of the vessel.

The graph below shows the trade-off associated with ISP, weight, and dV. Since the weight is listed as the percentage of the vessel's mass composed of fuel, the slope along that axis may change dramatically for different weight profiles. For a very heavy vehicle, an extra ton's worth of engine won't change the fuel ratio much; however, for a very light vehicle the same tradeoff would decrease the percentage mass of fuel by much more. By itself, this graph just helps illustrate the relationships involved... to be of any real use you have to take your own situation into consideration. EDIT: Here is another that I've attempted to animate to show the effect of overall vehicle weight on this tradeoff. It loops through each frame, and it starts with the highest vehicle/fuel weight. Each frame reduces the vehicle and fuel weight linearly, and fuel/vehicle mass is a constant proportion (more true for heavier vehicles). As you should be able to see, as the mass of the rest of the vehicle goes down, the effect of the engine's weight becomes much more important (as it becomes a bigger contributor to the total mass ratio). The effect of the engine's weight drags down dV quickly once total vehicle weight gets below 5-8 tons, (changing the fuel/ship mass ratio can alleviate or exacerbate this effect depending on the direction of the change). You'll also notice that the ISP/dV curve doesn't move as much when the engine weight is very low (the corner that doesn't move much). Basically, making the other parts of the craft (including fuel) heavier stretches this graph out along the engine-weight axis, which has the consequence of all but eliminating the penalty paid for engine weight. At higher vehicle/fuel weights, the dV loss between an engine of 500kg and 2000kg has become pretty negligible (the highest vessel/fuel mass is about 70t in this series of frames) while ISP gains remain relatively in-tact. http://postimg.org/image/onpa7tzud/

Eh, I misspoke. I edited in the correction, thanks for catching it. I meant to say "the base of the exponent"... as the exponent is a fraction.

Actually, you *always* get more dV out of a lighter engine (assuming ISP is the same), whether you get more dV out of a lighter engine that has a lower ISP actually depends on the ISP difference, and the weight ratios involved... not really on the total craft weight. (much less the "payload" weight). dV=g*ISP*ln(mass_wet/mass_dry)=g*ISP*ln([fuel+vessel]/[vessel]) Divided both sides by g*ISP (aka exhaust velocity) gives dV/(g*ISP)=ln([fuel+vessel]/vessel). Rewrite as an exponent of e to yield a more intuitive function: e^(dV/[g*ISP])=(fuel+vessel)/vessel. On the left is a standard exponential function, as the exponent's base goes to infinity the left side goes to zero and as the exponent's base goes to zero the left side goes to infinity. dV basically sets the limit here. On the right side is a plain old ratio. 1-(1/"the ratio") gives the percentage of the vessel's mass that must be comprised of fuel to attain a given dV at a given ISP. For the following sections, I'll use a dV of 1000 for illustrative purposes, but changing dV requirements only affects the exponential function in a linear fashion. If you look at the function on the left side more closely and take its derivative to solve for the slope, you'll find that the slope equals -1 at an ISP around 38... higher than this and the benefit of higher ISP engines trails off very quickly. In fact, at an ISP of 100 (well below most engines) the slope is merely -.03... which will almost always favor saving weight over ISP. For reference, if the dV required is upped to 2000, the point where slope is -1 moves up to an ISP of around 66.5 and at an ISP of 100, the slope is -.16 (considerably larger than before, but still pretty marginal). Looking at the function on the right side, you can see that decreasing the mass of the vessel will have a similar effect on dV. I've actually created a 3-d plot with ISP on one axis, the weight ratio on another axis, and dV on a third axis. It's a pretty complex function, but generally speaking... saving weight is almost always more important than anything else. If you select by weight mainly, you may short yourself a couple m/s of dV here and there... but you'll generally come out far to the better than if you select by ISP alone. If anyone wants to see what this graph looks like, I'll try to post it here. For me, I generally simply select the lightest engine that will provide the thrust I need for the mission at hand. - - - Updated - - - As an additional note, you really only need to be concerned with the ISP of engines for stages that are designed to have 8000+ dV, at these dV levels (and the associated weights that go with them, the types of ISP's typically found in KSP may have a significant impact).

"Can anyone explain why this is happening?" If you're using the optimal transfer orbit (which I assume you generally are), then you stop the burn the instant you have intercept. Since Kerbin orbits at a lower altitude than Jool, this means you'll approach Jool from the lower (sun-facing) side. If you stop your transfer burn as soon as intercept is achieved, you'll most likely have a Jool periapse on the sun-facing (radial-in) side. If you then perform your capture at that periapse without changing it, your normal will be opposite that of the moons. There are three ways you can fix this: 1) burn a little extra during the initial transfer burn, 2) perform a mid-course correction (likely burn prograde a bit, or some combination of prograde and radial out) or 3) establish capture first (but only enough to just barely bring the apoapse into Jool's SOI) then burn to flip your normal at apoapse. The first option is arguably the most efficient, and the most difficult (as even the slightest variation can cause a significantly more difficult capture). I believe the second and third options are both equally viable; however, option three will be more difficult to plan if you're performing an aerocapture (which seems likely). So my recommendation is a mid-course correction, a handful of m/s (at the right time) is enough to make drastic alterations to your encounter profile, and you'll have more than enough time to tweak it precisely. Midcourse corrections are also the best way to establish a good aero capture, so this makes the most sense. The only downside is that mid-course corrections are... less than intuitive with the large distances and orbital forces at work... but I assume you are familiar with this type of maneuver if you're trying to get to Jool.

lol... small steps right? Any success, no matter how small, is progress.

I generally try to come up with something creative, but telling of the purpose. My communications satellites are called Mercury A-B MkC, where A is the orbital group (where those with similar normals and orbital periods belong to the same group), and B is the designator for that specific satellite in its group (if more than one is present), and C is the revision number. For example, Mercury 2-1 Mk4 and 2-6 Mk4 are the two (of six) in keysynchronous orbit that have direct line of sight to the KSC. My missions put together solely for science are named something like Galileo 1. Missions primarly done for contracts are named very plainly for the mission at hand (though this doesn't happen often because I usually attempt to fit contracts in with other career mode goals).

There's a lot of awesome answers here, it makes me smile. Mastery is a great feeling, (which is why I said "feel pro", which is quite subjective) and that's one thing KSP has provided a lot of for me... those triumphant moments. And failure makes them much sweeter for me. @loch.ness: I agree, early career mode on hard settings can be quite a challenge. @Kerikbalm: Yeah, that doesn't happen often for me. I still struggle with timing launches to rv with ships/stations in LKO. I usually have to put stations in a slightly higher orbit and launch into a lower orbit to make it easier to get a good intercept without having to waste fuel. The added benefit of higher time warps being available usually means I usually use higher orbits for stations and such anyhow. @Johno: That's what it's all about! Keep challenging yourself. Even mechjeb can't fly a brick (though I'm certain it would try). I don't use it, but the object is to have fun first and foremost... I certainly won't look down on players who find it more fun with mechjeb than without. They just prefer to focus on other aspects of the game.

I doubt it's a planet you're looking at (it's possible I suppose, but the evidence suggests otherwise). Based on your description as having "just left kerbin's soi", I'd say it's most likely an asteroid. The crazy inclination also suggests this (if it were a planet far enough away to appear like a dot, it would have to have quite a large inclination), as asteroids purposely come at kerbin from many different angles.

Being able to get Mun and Minmus intercepts without nodes. Knowing how to calculate dV on your own. Being able to pick a spot, and land within a few meters of it easily. Going to Minmus without a plane change. Designing a plane that actually gets to space, flies well, and does something useful. (This one was hard for me because of FAR, so I felt pretty pro when I was able to do it... it's a good feeling) How about you? It's not really a contest or anything, just share those moments where you feel especially triumphant.

1) When you finally get to the mun, but can't make it back because you hadn't noticed that the lv-909 has no alternator. 2) When you spend almost as much time on the forums and wikipedia learning as you do playing. 3) When you think this game couldn't possibly get any more awesome. (IE: pre-mod phase) 4) When you still pack on three times the fuel you actually needed. 5) When you think the Mun will be a much easier mission than Minmus. 6) When you use the fewest stages possible to reduce the chances for things to go wrong. 7) When your rescue ship has to be rescued. 8) When you try to get to Duna and end up on Dres. (I did that lol) In all fairness though, I'm always learning and getting better. I've played with Remotetech for quite a long time, and only figured out how to use the flight computer a few days ago.

Hey guys. I love all the USI mods... it's a whole new level of awesome. I'm having a bit of mod-related trouble though. Problem: Kerbal Engineer doesn't seem to recognize the HERP Pod (the one that looks like a lightbulb). I know this *could* be a problem in kerbal engineer, but it does pick up other mod parts (even MKS/OKS). It's not game-breaking, b/c I can always use the rocket equation. (Go me!) But I was wondering if there was something in these exploration parts that might not be playing well with KER. Basically the KER window doesn't show up in the VAB at all (despite the presence of the part). It does show up in flight, but the dV listings just report whatever it said last (from the most recently controlled vessel). I don't believe it works correctly with the jump seat or HERP maintenance pod either. Those are the only parts I've tried so far. - - - Updated - - - Ok, so apparently it doesn't work in the VAB at *all* any more. - - - Updated - - - After restarting, I could not duplicate the issue. Maybe KSP or KER just had a brainfart...

The OP says that KIS is a rework/improvement on the inventory system first implemented in KAS. Obviously it does a little more than that (as described elsewhere), but the key point is that KAS's inventory system will be phased out in favor of KIS. I'm guessing one could continue to use KAS without KIS in the future, but you'd likely be without an inventory system. I usually just go ahead and attach whatever parts I'll need rather than adding the excess weight of containers anyway... and I'm sure a lot of people do the same.

Aww crap. Well now I guess I get to figure out what the problem is. Thanks for your patience (and efforts with this mod). - - - Updated - - - I think I know what happened. I didn't install it correctly. I unzipped it and 7zip extracted it into a folder structure like ~\gamedata\deadly reentry 6.40\deadly reentry\. The problem with that is that the 2.5m heatshield cfg file contains a reference to its model that needs the path to be correct... so it just wasn't loading at all. But it seems to be the only part affected by this. - - - Updated - - - Yep, that fixed it. I also discovered that the .625m heat shield is also affected by the incorrect install. I just didn't miss it because it wasn't part of DRE last time I played.

..... What did I say that confused you? Take a look in the mod's part folders. It's there... it just doesn't work. - - - Updated - - - DRE has always had the 2.5m heat shield, it's the part that goes on the mark 1-2 command pod. (For some reason, they didn't add the heatshield to the mark 1-2 in stock like they did the mark 1 pod) - - - Updated - - - Here's the cfg file for the part in question, it can be found in the 6.40 version, and the .53 dev version (as I said earlier)

I'm having problems with the 2.5m heatshield not showing up in-game. I'm running DRE 6.40. On inspection, I noticed some significant differences between the part cfgs for the 2.5 and for the other sizes. I made a new copy of the 2.5m heatshield and modified its cfg to look more like the others... the new test copy does indeed appear in the tech tree, can be purchased and used in the VAB. The connection points aren't quite right, and the textures are all mangled for some reason, but at least it shows up. Is there a solution for this? Is anyone else having this problem? - - - Updated - - - I looked into the dev version's 2.5m heat shield part cfg file, and it doesn't seem to be any better than the current one.

I can take a stab at numbers 1 and 2. These mods are most likely attempting to produce results that are more realistic. (More in line with what we expect based on generic physics ideas) There is a pretty significant deviation that KSP takes from the real world. In the real world, thrust decreases as the atmosphere decreases in density. Also, the ISP increases proportionally (mostly) to the decrease in thrust. This is because in thick atmosphere the exhaust gasses have something to "push against". The atmosphere soaks up the momentum and creates a high-pressure area beneath the rocket. The atmosphere pushes back, creating additional thrust. Of course, since ISP is related to exhaust velocity, it makes since that it would be lower where there's atmosphere in the way. In KSP, the thrust (in stock anyhow) doesn't change with the presence or absence of atmosphere... so, to "simulate" this change they modify the fuel flow rate instead. They have talked about rectifying this soon: http://kerbaldevteam.tumblr.com/post/110666185425/devnote-tuesday-point-sharp-end-towards-space. My guess is that the mod makers decided to use their own solution long before Squad announced any plans to "fix" it... which would be why your engines are taking a hit to thrust once they get out of the atmosphere. Don't worry though, I doubt they'd short-change you... you're likely getting a nice steady, predictable fuel flow rate regardless of circumstance. As to the second question, this is just a guess again, but I imagine the thermal engine is probably made to be as "realistic" as possible. In this case, it's a reflection of how thermal engines work. They essentially heat something up really quickly without actually exposing it to flame. The expansion results in the exhaust gasses used to propel the craft. Whether combustion occurs or not depends on the temperatures and propellants involved, but the idea of thermal nozzles is generally to avoid combustion (but I guess it isn't unimaginable). The short answer here is that the thrust provided by a thermal nozzle depends on several factors: the propellant's specific heat, density, heat of vaporization, molecular weight, etc. My guess is that they believe that hydrogen would be a far weaker propellant because of its extremely low density. You can think of the rocket equation as being similar to standing on a boat and throwing a rock... the resulting reactive motion of the boat is directly proportional to the momentum of the thrown rock. Throwing a bigger, heavier rock helps... depending on the maximum power you can put behind it. IE: bullets carry quite a bit of energy when fired from a gun... but if you're talking about the energy of a thrown object, a baseball is a far better option than a bullet because your arm simply doesn't move that fast. Likewise, there's a limit to how quickly thermal energy can spread (and it varies from one substance to another).

It's funny you say that, because I actually use them the other way around. I use the 30 as the main engine and the 45's as the boosters. You need gimbal most when you're at your heaviest and in the thickest part of the atmosphere, so I use the 45's to add that lil bit of extra thrust and control. Once I get lighter and higher I ditch the 45's, by this point i'm high enough and light enough that the 30 is enough by itself. (at least this works well on smaller launch vehicles)

Just my two cents here: I use NEAR. I used FAR, and while I can understand the graphs and physics behind it (at least as well as any other non-aero-engineer), I simply found that it made planes far too difficult and time-consuming to develop (not to mention costly in terms of poor test kerbals and funds). Sure it can be done (and with some care and knowledge it works extraordinarily well, especially compared to stock); however, (and this is just my opinion) I play KSP primarily for space travel... all other concerns are secondary for me. I like NEAR because it handles the bare minimums needed for rockets (and its shortcomings aren't as noticeable over the short and relatively vertical paths you usually follow through the atmosphere) without making planes too difficult. My main concern is ascent profiles and reentry trajectories. I find that NEAR + Deadly Reentry + RealChutes work well together for what I want. Basically, I have to go through air to get to space. I prefer my time in the atmosphere to be fun AND non-soupy, but I'll take soup over ragequit.

This is my original point. The problem isn't contract payouts or building prices... it's having building costs linked to failure costs. For those of us that want a more risky game (hence turning off quicksave/quickload) by decreasing payouts a bit and increasing penalties for failure, it turns into a grindfest because building prices scale way too fast. Since those percentages can't be changed once the game starts, you have pretty much two choices: 1) turn up payouts, in which case the beginning is more reasonable... but then when better contracts come in money quickly becomes an issue of the past... essentially making all the upgrades just one more thing to spend endless funds on, or 2) turn up penalties... in which case the later game makes more sense, but the beginning is unbearable. Simply unlinking costs and penalties would do the trick... and it's an easy enough fix. One variable and one extra slider. This way you could increase penalties for failure and reclaim the feeling of risk that made hard mode so great in the last version, without introducing grind-fest. As a side note, I personally think it would be nice if there were also a contract difficulty setting that could decrease deadlines (based on the location of the task) to actually create some risk of failing contracts... as right now it's pretty much more than enough time to get any contract done... even if it takes you 20 tries or more (at which point it really becomes more about cost vs payout and less about failure vs success). EDIT: Sorry if that sounded argumentative, it wasn't meant that way.

I think the default difficulty options need a lot of tweaking with the new elements of game-play. They were almost perfect before .90, not too grindy but failure was costly. Now setting it on hard makes it equally risky as it used to be, now with 10x the grind. You can play with the values to get a somewhat decent result, but nothing like it was before. I think another part of the problem is that building costs are tied with failure penalties. I think building/part/research costs should be a separate setting altogether (if you even want them to be changeable). This way, you can increase penalties for failure (introducing that risk factor) without making the costs skyrocket (introducing super grindage). Thoughts?

In my opinion, the problem isn't the building prices. It's the default difficulty settings, and the fact that building prices are tied to "Fund penalties" section. Penalties and costs should be two different things entirely... and imo all costs should scale together. IE: if "cost percentage" is increased, then building costs, research costs (if enabled), and part costs should all increase by the same amount. Also, the default percentage settings need to be tweaked to reflect the changes in game play due to the new mechanics. Personally, I like to set fund income to a higher percentage and then increase failure penalties to twice the percentage of income (so I'll set income up to 150% and penalties up to 300%) because what's the point if there's no risk? Alas, this makes the R&D building cost 1.5 mil for the first upgrade, which is just ludicrous (sense right now building cost scales with penalties setting). This has the effect of making it very hard to find a nice balance where it isn't overly difficult or grindy... but not so easy that money is pointless. I dunno, I like all the new features... but it just seems like they completely forgot about difficulty settings. I've played KSP long enough to feel very comfortable in the game, so I like to have a lot of risk (and hard setting on the previous version did this, you could make money... but not if you mess up)... unfortunately that means that you only bring in smaller amounts of money at a time, and combine this with increasing building costs (due to difficulty) makes it a serious grindfest that isn't really worth the effort.

This should probably be edited into the first post at the bottom of the page or something. I was only able to find it because I looked at the last few pages assuming someone had probably recently asked the question I was about to ask because the information was hinted at existing but not made immediately available... lol. Thanks for sharing.

I bet that's what was causing mine not to open!!! I placed in quad symmetry, and inflated one (to gauge it's size for placement purposes). Afterward, I deflated while still in VAB, and later (after launching) one of the four would never open. I bet it was the one I tested in the VAB. Is "recharge" context sensitive?

Really it's whatever's easiest for you. Some people find it easier to work with nice even numbers, which are then later rescaled to match the KSP sizes (1.25, etc)... as in the method you were just asking about. I prefer to work with actual ksp sizes in meters in blender. So when I'm extruding or offsetting or whatever, I know that .5 is indeed .5 meters in KSP. I just make sure that the scaling isn't messed with in unity or cfg files. It's a personal preference more than anything. (Although some modelling programs make snapping to nice round numbers much easier than snapping to odd KSP size numbers... which might be worth considering if that's your thing)