impyre

I suspect those large wheels produce more torque when active than their brakes do... I'd try throwing it in reverse.

In response to the OP's remark about antennas... I find that kinda funny because it has been used to reduce drag, though I seriously doubt *reducing* drag will help you much during reentry. http://en.wikipedia.org/wiki/Drag-resistant_aerospike Of course... lasers are *way* more fun than metal spikes.

Occlusion is just a fancy word for the process of "shielding" or covering something. An umbrella could be said to occlude you from the rain, in that sense it could be called a rain occlusion device... though I doubt google would be able to find that term, that doesn't make it less apt or correct. Occlude: stop, close up, block, or obstruct. So in the sense of the original post, one can infer that "shock cone occlusion" refers to a process by which the shock cone occludes or shields parts beneath it from the worst of the shock heating. This would allow radially attached parts (at least those which don't protrude too far) to be relatively safe. Some conductive and convective heating can still be expected of course, but if you try to fly the craft in backwards you'll see just how much difference the shock cone occlusion makes for things like batteries, goo canisters, and radially attached chutes.

It's hard to tell what you're asking about here... your statements are a little confusing. I created some test vessels on the runway and had no issues. All panels were operating nominally. That being said, "nominal" operation and "rated" operation are two different things. Ratings give "ideal" values, which will be off the mark... more or less depending on your situation. Partial occlusion may be a thing now. Panel output varies with distance to sun, and heat buildup also decreases their effectiveness. In my test rig, as panel temperature approached 500, I was only getting about 80% of nominal output (vs a panel in the same situation with the same exposure at sea level temps of around 300). And since nominal output was only about 87.5% of rated output, then output at tested heat level was around 70% of rated output. That said, the ore converter generates quite a bit of heat... it's possible that the heat is decreasing your power generating capability. "my total electricity levels are going up by 0.8"... well, that could be perfectly normal... it depends on your energy balance... how much electricity you're using versus how much you're generating. If you're using the converter to refine ore into LFO, I'd highly recommend supplementing solar panels with fuel cell arrays. EDIT: Also don't forget to consider all potential uses of electricity, like reaction wheels, probe cores, lights (even landing gear lights), and possibly other parts if you have mods which introduce electricity dependent parts.

I deployed a kevlar drag chute at 69km. At 55km it vanishes and a message is displayed by realchute... something like ..."due to heat or aerodynamic forces". I was monitoring heat, aero, and g's at all times... there was nothing alarming about the situation that warrants ripping a kevlar chute (with a predeployed area of 3 square meters) off my craft. What gives? Drag forces should be much less and heating should be minimal at that altitude. Don't get me wrong, I'm no parachute expert... but why can't this be done? Is there an alternative besides heat shields?

I think that it is you who misunderstands terminal velocity. It is not simply an arbitrary speed... it is *the* speed at which the force due to drag is equal and opposite to the forces causing the movement/acceleration... so no further acceleration is possible. This statement is true whether it is gravity alone causing this acceleration, or gravity + an engine (or other forces). And since drag (at high speeds anyway) is roughly proportional to the square of velocity... there will **always** exist a terminal velocity for an object moving through a fluid... regardless of how much power you put behind it... it's just that the more power you add the higher the terminal velocity becomes; however, if you are descending then you have to consider that the air is becoming more dense (thus lowering terminal velocity). If the effects due to increasing density outpace the effects due to increasing throttle... then you certainly will slow down even though you hit the gas (though you will slow down less rapidly than you otherwise would have). This still doesn't consider the effects of reduced weight, if an engine can consume weight quickly enough to decrease the mass at a significant rate... it is essentially increasing drag/weight ratio. So it's possible that if you deorbit a full tank, you will be going faster at a lower altitude than if you had pointed prograde and burned all that fuel up (though I doubt that's possible with any of KSP's fuel/engine combinations... it would probably require a horribly inefficient engine).

I agree with you up to a point; however, given your speculative statement regarding two engines, one lighter and less efficient and the other heavier and more efficient, the one which delivers the most dV for the payload (or for itself for that matter) does *not* depend on dV *or* acceleration. That statement is self-contradictory. "The one that delivers the most dV depends on how much dV and acceleration you need." is the essence of the statement. This is contradictory and circular... further, there is no part of the rocket equation that makes any consideration for thrust or acceleration (though we have to consider those things when *spending* our dV to get the most out of it... which is where my "utility" function comes into play). Given these two engines... which have given ISP's and masses, the engine that will give the most possible dV for a given fuel/payload configuration depends solely on the fraction of mass that said engine contributes to the overall mass. Larger payload/fuel configurations will likely benefit more from ISP than weight savings while smaller payload/fuel configurations will likely benefit more from reduced weight than ISP. Of course this is all relative to the disparity in ISP and mass between the two engines... and it is this disparity which will set the dividing line along the equipotential surface that separates the region where one engine dominates from the region where the other dominates. Of course this also depends on how you define "efficient", I assume for this discussion when referencing an engine's "efficiency" you are in fact talking about ISP. http://forum.kerbalspaceprogram.com/threads/113476-ISP-Weight-tradeoff-on-engines-(graph) Above is a post I made previously for any arbitrary combination of dV, ISP, and engine mass (as percentage of total vessel mass). The upper graph shows the relationship for a given payload mass, while the lower graph is animated to show the effect of reducing the payload mass (and displays engine mass in units instead of percentage)... this shows how the upper graph changes shape as payload size changes. As you can see, as payload size becomes smaller... engine weight becomes more important. I considered placing several of KSP's engines on this graph to show how they relate to each other, but it's redundant information if you understand the basic relationships. EDIT: also, I'm not trying to hijack your thread. I promise

I would like to submit, for your perusal, my own analyses as a response to the OP. First I'll explain what I did and why I did it that way. To the rocket equation! dV=ISP*g*ln(massfull/massempty) this equation shows that ISP and dV are linearly proportional given a constant mass ratio. That's an easy enough relationship to grasp... ceteris paribus (all else being constant)... twice the ISP = twice the dV. If we solve for mass ratio we get e^(dV/(isp*g))=mass ratio. This tells us that for decent values of ISP, changing mass ratio by even a tiny amount can result in increasing dV by an order of magnitude. When you put these two things together, you have a basic understanding of the tradeoff between ISP and mass. For example, if engine A has an ISP of 400 and a mass of 1, and engine B has an ISP of 800 and a mass of 1.2 then you'll likely get better results (at least in terms of dV) with engine B. It is only slightly heavier but gives twice the ISP. However, if engine A weighed only .5, you'd have to look more closely to determine which would be better for your particular vessel. IE: shaving .1t off a 30 ton monster won't do much to change dV... but increasing isp by even 50% will make a big difference. On the other hand, sticking a nuke on a 2t lander won't do you any favors since it's mass will easily more than make up any savings you get from higher ISP... it weighs more than the craft itself! Using a 48-7s or an lv-909 would probably be better choices. tl;dr Here's the graphs The red is my pure dV potential function, essentially ISP(vac) per mass(tons). The best ratio will provide better ISP for any given payload, though the size of the payload will change the relative differences between the engines. Some payloads may notice little difference from one engine to the next, while others may notice significant differences. We all know that putting a microscopic engine on a giant fuel tank would create large dV... but is it really useful? I think not... most of us care about thrust (some more than others), and thrust is needed to execute maneuvers in a clean fashion. Thus the blue line represents my arbitrary "utility" function. It's ISP*(thrust/mass). Thus, it accounts for dV potential (to some extent) and for thrust capability (again, to some extent). The interesting thing to note is the relationship between the raw dV potential and the "utility" function. There seems to be an almost "inverse" relationship between the two... higher dV = harder to use... but this graph illustrates two interesting points. Firstly, the lv-909 represents a unique compromise between dV and utility... as such it is uniquely suited to smaller-scale repetitive ops (like landers that go to the surface to get science and then make orbit to refuel... rinse/repeat); the second interesting point is that the 48-7s (one of my personal favorites, and the one I use on most of my single-seater landers) has the highest combined dV potential *and* utility function of any other engine... this little guy is pure workhorse (if limited in the types of vessels). All of these use an arbitrary coefficient of 1 on all terms, so it's not fair to suggest that it's "accurate" or represents anything other than a "notion" of usefulness. This is just a good representation of the "usefulness" of various engines in *my* opinion. Also, I'd love some feedback on whether you agree or disagree (and whether you find it useful or accurate or not). EDIT: Correcting some verbiage. I keep saying "weight" where I *should* be saying "mass". - - - Updated - - - Also, it's worth noting that I didn't raise any mass terms to exponentials (though that might be more accurate)... So this representation actually favors ISP more heavily than it should. (And is more forgiving of "heavy" engines)

I take offense, good sir, at this affront upon my favorite little engine that could (almost). I agree with NathanKell, your results are so one-sided because your methods (probably unintentionally) bias the results in favor of those engines.

If you're using realchutes, a drag-chute setup can be engineered which will mitigate or eliminate damage due to reentry heating. Last night I deorbited a fully-fuelled 2.5m vessel, including skipper and half-size rockomax tank. No reentry effects were observed and exterior attachments were undamaged. So it's not inconceivable that a small claw-equipped vessel with drag-chute/main-chute combo could perform such a task. Also, it's worth noting that since my design used high-drag high-altitude chutes, I opened drag chutes at 69km. I set target altitude to 35km and target velocity to 1000m/s. Predeployment altitude of 69km, deployment altitude of 40km. Not only were there no reentry effects, but g-forces never went above 3g's. It's also doable in RSS, but you might want to use multiple drag-chute stages, and cut away higher drag stages as you get lower to keep g's from getting out of control and tearing your ship apart / liquifying your kerbals.

This gets *way* more difficult after you've been outside the SoI for awhile. I got a "sun flyby" contract and used valentina. I escaped on a solar radial-in direction, got just outside kerbin soi, then burned radial out (back toward kerbin) to get back in. This works well with radial-in/out escape paths because you aren't changing your orbital period relative to kerbin... (not much anyway), whereas if you escape prograde/retrograde, getting back can be difficult... because once you change your orbital velocity relative to kerbin, you start falling away (both in terms of phase angle and altitude). I recommend radial changes for short there-and-back trips to solar soi. At the very least you can regain encounter in half an orbit with very little dV. - - - Updated - - - To answer your original post, with 200dV and such an elliptical orbit, the best option is to simply wait a year or two for re-encounter. Highly elliptical orbits spend the vast majority of orbit time at their apoapse... in contrast kerbin will be moving quite quickly while your ship is at it's apoapse. This increase odds of encounter significantly, you shouldn't have to wait very long. Save all dV for getting re-captured. Once you have an encounter coming up, try to get a pass through atmosphere by planning a maneuver a ways out, 200m/s should be enough to tweak an atmospheric capture.

Well, I've played with old stock aero, NEAR, and FAR... and it seems the new stock aero is inclined to prefer a slightly steeper/later turn than FAR/NEAR, but much sooner than old stock. I've found (and this is just loosely based of some limited experience) that the best results are obtained by starting gravity turn around 2-4km, gently edging over with an angle of attack that's no greater than about 5 degrees at most (maybe 10 occasionally). Try to minimize mach effects, and shoot for around 65-70 degrees at 10km. After 10km you can slightly increase your angle of attack with less fear of flipping. Try to aim for about 40 degrees at 30km, and continue bringing the prograde down until about 45-50km. Whenever the navball switches to "orbit" mode, you can essentially take any angle of attack, just try to get out of atmosphere somewhere around 45s to 1 minute to apoapse. You can do further, but it's harder to keep it low without burning radial-in... of course if you're aiming for a higher initial orbit, then by all means raise that apoapse. A couple tips that help me out. a) Always have *at most* one gimballed engine (or at least decrease gimbal limit on the others), this decreases SAS-wobble significantly. Consider using control surfaces *only* for attitude control below 35km, will eliminate wobble... take advantage of the new aero. c) Strut *through* fairings. I know, it looks derpy... but it works. And since the fairings don't auto-strut, it's quite necessary. This can easily be done so long as the payload is smaller in diameter than the launch stage (which it should be). Run struts from the size adapter to the payload in whatever way is convenient. I've launched payloads attached by docking port with struts and had no wobble. d) Always use control surfaces/wings on the lower end of your rocket. If in doubt, test it out. You may need larger wings for bulkier payloads that induce more drag. EDIT: e) *Never* use follow prograde SAS setting during launch... it's derpy *especially* if it's given more attitude control than it needs. If you find that when you click the "hold *** mode" button, where *** means radial-in, maneuver node, prograde, etc.... with sas on and your ship gets twitchy and can't seem to point exactly where it's supposed to (slightly off to the side), chances are high that you have too much attitude control... try decreasing by turning of some reaction wheels. EDIT: The "10 degrees at 1km" is highly dependent on your TWR. For people used to playing old stock souposphere which rewarded much higher TWR... this is a valid strategy. If you're using a lower launch TWR of closer to 1.8-2, the method I described is much better. Also, the only time turning SAS off for a "natural" gravity turn will work is if you have sufficient lift. Since your rocket is built in 4x symmetry, it will produce less body lift. It also has nary a wing to speak of, which is why your nose is dropping like a rock (probably combined with a lack of attitude control authority and/or low TWR). If you want a more "natural" gravity turn, build in 2x symmetry and launch with flat side facing the direction you plan to turn in. Wings are good too.

I'm using IR as installed by CKAN, and IR is totally taking over my toolbar. Every time I load a vessel, I get a new IR button. When I quit last time I had like 10 of them. In the magicsmoke industries folder, the version file says 0.12 for ksp version 0.23.5... while CKAN seems to think it's version 0.21 for ksp version 1.0.0. Did I do something wrong? EDIT: okay, I see changelog says latest version fixes a bug with the toolbar... so I guess CKAN is just out of date. I really wanna use CKAN, but I may have to do without.

Karbonite was developed as an *open alternative to kethane*, and this development was prompted by the change in the licensing for kethane. I believe I recall roverdude saying as much himself. Regardless of why it was started, he's always done a very good job of ensuring that people can pick-and-choose which mods they want from the USI catalog without feeling like they are "missing something". Karbonite stands very well on it's own imo, and I'd still choose it for fuel over kethane even if I had no other mods at all. (Huge TWR is super fun ;P). Even though each mod stands on it's own merits really well, or perhaps because of that fact, I find that the longer I played with USI mods, the more I downloaded... until I had to have the entire catalog. Though I may uninstall the one that introduces karborundum... it's pretty overpowered (at least for normal kerbol system... in RSS it might feel less overpowered).

You *could* bounce out if using NEAR/FAR... but as others have said, it would still just slow you down a little... wouldn't speed you up or benefit you in any real way. The only time I can think that this might be useful is if you're highly elliptical and need to rotate your orbit around to get an encounter... and you wanted to do it as cheaply as possible. Bouncing out of atmosphere is somewhat like performing radial-out burn. Not sure if it'd actually save you any fuel, but it could be handy.

I usually agree with Alshain, but on this point I must disagree. It is *purely* a matter of opinion, but Karbonite is superior in virtually every way... like Mary Poppins. Sure, it's different... but it poses it's own unique set of possibilities, challenges, and design angles. For starters, Karbonite can be used as fuel directly or for refining into other fuels. Karonite-based vehicles have some advantages and disadvantages... they are mostly just different. They have lower ISP and higher thrust (fantastic for launch stages)...however, the lower ISP is mostly countered by the fact that Karbonite is extremely dense compared to LFO... this improves empty/full mass ratio offsetting the costs associated with lower ISP. In fact, if karbonite engines had similar ISP's as LFO engines.... they'd be completely overpowered. When coupled with TACLS, there are some parts that can convert LFO into water+oxygen for crew... karbonite cannot be used for that purpose (that I know of). Also, to build a karbonite mining base requires loads of investment (in career anyhow), but is usually well worth it. Coupled with the logistics hub from the MKS/OKS suite, it's a powerful tool. Here's another catch, the tiny karbonite engine is pretty horrible compared to its LFO counterparts and it's bigger Karbonite cousins (apparently Karbonite works best in large doses? Go big or go home?) *however*, tiny karbonite fuelled probes/rovers can make use of the tiny karbonite drills / generators to extend their mission indefinitely. Sure, the tiny drills are horribly inefficient... and coupled with the mini karbonite generators will only drain your karbonite/electricity... but if coupled with some other energy source (solar panels or rtgs) you can refill on the fly in situ (wherever karbonite can be found)... this can be a huge deal, maybe even worth the inconvenience of suffering smaller dV's. Karbonite's more free licensing means that more mods from other authors support karbonite (any which support CRP I imagine). Also, karbonite can be collected in numerous ways, including atmospheric scoops, oceanic extractors (for places like eve) and drills... while to my knowledge, kethane is slightly more limited. And last, (but certainly not least), karbonite is found in unlimited deposits (it can never be mined out)... which means you'll never *have* to move your base... what it *does* mean is that if you want to do anything useful, you need to choose a good site (scansat helps a lot). To contrast with kethane: kethane has deposits which are slowly consumed (at least used to be how it was), you *shouldn't need to ever worry about depleting it, but it isn't impossible either. I will say this in defense of kethane, I freakin love the planetary overlays... if karbonite had those beautiful things, I probably wouldn't have scansat installed (oh, who am I kidding... i like making maps). If it sounds like I'm a raving stupid fanboi... it's probably because I am. </totally biased opinion>

I have an idea... restrict "ultimate" entries to only those which "roll up a ramp". Then the challenge with flingers becomes aligning the flung object with the ground in such a way that it rolls after release (without blowing up). Maybe this makes it too difficult though, just an idea. Perhaps to minimize feelings being hurt, you could simply create a new less broken "ultimate" category... a semi-ultimate. As a side-note, Foxster's would be perfectly legit in semi-ultimate as I envision it. The challenge in semi-ultimate is having something driveable rolling up a ramp and surviving. Nothing aside from the rover and ramp would be considered.

As soon as I have some free time, I'm gonna try for an "open" entry.

So I tried searching google and the forums, but to no avail. Alas, the google is not strong with me today. Also, I'm not entirely sure where this question should go; if it needs to be moved, please feel free. So here's the question: Can you import vessel designs that were created in modded installs into stock installs? Obviously, no design requiring parts from a parts-pack would work unless that pack was installed. But what about mod-manager-type-stuff? For instance, I have a modded install that has KER installed... it's set up to work in "partless" mode, but i'm unsure how/if that affects saved vessels. Also, I have realchutes set up to treat the stock chutes like realchutes brand chutes... would that affect the ability to export those vehicles to a stock install? So, I guess my real question is... Is there any way to know besides asking the author of each and every mod I use? Or is it possible to tell by looking at the craft file? Or does it even matter so long as no mod-specific parts are used?

I can't speak for everyone... but the OP was "No shielding for spaceplanes"... in that specific train of thought, I was addressing the idea of heatshields as distinct parts *for spaceplanes*... I can only imagine those who were less explicit are talking about the same thing (or confused by others who were less explicit).

"No dedicated spaceplane heatshield parts" doesn't equal "No shielding on space planes". It just means that it will likely be a directional shielding coating the underside... which will make reentry quite easy at reasonable angles/descent trajectories. Of course, if your plane doesn't fly well (entirely possible in new aero), you may be in trouble. Otherwise, I assume they will go out of their way to ensure ssto spaceplanes can still be a thing.

Aww.... now I wanna delete my post. Sometimes I forget that weight doesn't equal mass. I'll leave it anyhow so that your post makes sense. Thanks for straightening me out.

I want one of these!! Squad, start selling LV-T45 shot glasses... I'll buy some.

When you stop learning, you may as well stop playing.

I think everyone who responded to me was missing the point entirely. Simply put... if you stick a an LV-T45 engine behind some FL-T800 fuel tanks, you can comfortably push around three of them at 70km orbit. More if a lower TWR is acceptable. Using [a=g*(R/R+h)^2] (from ksp wiki basic orbiting math tutorial), acceleration due to gravity at minmus altitude is about .001556 m/s. The ratio of acceleration due to gravity at 70km to acceleration due to gravity at 47,000km is about 5012:1. Since F=ma shows that the relationship between acceleration and force is linear, this shows that TWR follows the same ratio (inversely proportional). This means that our little theoretical craft (just an engine and three tanks) has gone from a cozy TWR of 1.7 (at 70km) to a whopping TWR of 8547. This little LV-T45 (up at minmus' orbital altitude) could push well over ten times the number of tanks and still maintain a healthy TWR. (Actually, it could push a great deal more... and still maintain a comfortable TWR) Assuming 30 tanks are used on our theoretical freighter if it leaves from minmus altitude, and 3 if from 70km... it has 5835.8 m/s dV with 3 tanks (@70km) and 7661.6 m/s dV with 30 tanks from minmus. These numbers are really just for illustrative purposes. If your computer could handle it, you could launch your minmus freighter with 100 tanks (or 1000). And I obviously didn't account for things like solar panels (who needs power anyway?)... but the idea is sound. Higher TWR = more fuel per engine... and more fuel per engine = more dV. I believe this demonstrates that launching from higher up can more than offset the extra requirements. Of course, the real problem with leaving from that high up (as ever before) is the potential for missing launch windows due to being in a poor spot in your parking orbit... and launch windows trump pretty much everything else. I usually set up my parking orbits (and gas station) somewhere around geosynchronous orbit. Keeps line of sight with KSC (handy for rt2), gets some advantage of lower gravity, close enough to the mun (from which I launch mined/refined fuel), and Kerbin (from whence cometh my kerbals), all the while allowing me to still have potentially multiple launch opportunities within a single window.