MechaLynx

Indeed, I didn't think of that at all. This makes perfect sense. If the object pulls the craft counter to its velocity vector it loses speed, if it pulls it prograde it gains speed. Thanks to you both. Just to clarify, does the rotation speed/direction/tilt of the planet, relative to the craft's vector, have _any_ effect on it at all? If so, is that effect comparable to the effects of its gravity alone or can they be ignored as far as its new trajectory is concerned?

Since this thread has been slightly necroed, I'll perform the sin of making a post here, although normally I wouldn't. And it has everything to do with Universe Sandbox. First of all, Universe Sandbox (not 2), which I unfortunately own, is hardly a game or simulator. Very little, if anything, interesting can be done because: 1. It's capability to realistically simulate gravity between bodies is quite poor, abysmal even. It would be ok for a game mechanic, but there is no gameplay to be had here. It can use either the Euler method to perform the computations (which is generally considered so inaccurate in terms of the n-body problem, that it's effectively useless and should never be used - I think even Scott Manley has said as much) or RK4 (Runge-Kutta, which is mispelled as Runge-Katta in the game), that is considered marginally acceptable if I recall correctly. Add to this that the default step is quite huge considering that the scale of the solar system (and celestial objects in general) is quite large and gravitational systems are quite chaotic, which is evident even when playing the game itself. Any accuracy in a simulation within Universe Sandbox is too much to expect. 2. There is so little control over factors. Sure you can change mass for instance, but as most people here already realised, if you can't change that mass gradually, the simulation is absolutely useless. There is practically no control besides arbitrarily placing arbitrary objects with arbitrary properties - any dynamic change is merely the result of its hugely inaccurate physics. 3. The effects on any object are merely destruction (loss of mass), change of orbit due to collision or the gravity of other objects and addition of mass through collision. No magnetic fields, solar wind, volcanism, temperature, nothing (although Universe Sandbox 2 adds some of these, in a very rudimentary way, but still quite insufficient to project any meaningful assumption). It's a game with exactly no audience. People who are interested in a game will get bored almost immediately. People who are interested in a simulator will be disappointed quickly and will also quickly realize how incredibly inaccurate it is. Perhaps it appeals to those who _think_ it's realistic to even the smallest degree and like simulators or those who are completely casual about games and want to feel cool because they play a "space" game. I don't really know. Additionally, it is poorly coded. The framerate jumps all over the place and drops to the single digits whenever you want to overlay something essential such as projected orbits. In fact, having it show the projected orbits tells you, in one picture, how useless it is at simulating anything, since the projections change radically at each step. When I see a simulation like this, where almost every interesting change in the bodies results inescapably in the solar system falling apart, I can't take it seriously. It completely circumvents any and all stabilizing feedback mechanisms which must necessarily exist for the solar system to acquire any sort of (even short-term) equilibrium and prevent it from falling apart within a few thousand years. Personally, I think that expecting radical changes is unrealistic - natural systems have self-stabilizing mechanisms. It's unlikely that a slow mass increase of Jupiter, enough to become a star, would cause an apocalypse. Chances are, it would be a lot calmer and stable than most of us would expect. If you want to simulate something like this, you really need to break out the computational physics packages.

On Scott Manley's video with Ed Lu ( ), when Scott asks how much fuel their craft will need to get into position, Ed Lu tells him that they won't need much because they'll use Venus's gravity to circularize.Now, the entirety of my exposure to orbital mechanics comes from KSP, plus some extra reading here and there, but I am aware that real orbits don't work with some simplified SOI-based model. However, this still puzzles me: Whenever we enter the gravitational sphere of a celestial body in KSP, we need to circularize by adjusting our speed, hence we spend fuel doing so. Even if one considers real orbital trajectories, it still makes sense that it would work that way: if you fly by a planet close enough to use its gravity as assistance, to save fuel, it only makes sense as a maneuver if it's accelerating you and increasing your speed along your current trajectory - from what I understand, that's because your distance from the object and your speed don't correspond to a stable orbit, hence you get a gravity assist due to the force the object is applying on you (which should, by this logic, be the difference of your current speed and the speed of a stable orbit at that distance from its center). Thus, I see two ways Ed Lu's statement can reflect what they're actually doing: 1. Somehow, in the real world, you can pass by an object at lower than escape velocity and have its gravity assist increase your velocity enough to circularize your orbit (not around the object itself, I think their probe is intended to somehow get a circular orbit similar to Venus's) instead of just getting left with a sub-orbital trajectory 2. You pass by it at a high speed, but counter to its rotation, thus losing speed. The second one is pretty much my question: I know that when you're already on an object, it's wise to use the planet's rotation to get a bit more ÃŽâ€v, but when you're passing by it, does entering a retrograde or prograde orbit matter in terms of how its gravity assist will work or the scale of its effect? As far as I understand, it shouldn't matter at all since the body is pretty much producing a gravitational field and as long as its strength is the same, the way it alters your own energy should be the same, no matter the angle of attack. Do tidal forces apply here? As an addendum, do we see any strange effects in KSP related to this? For example, if one enters a body's SOI retrograde, prograde or in a polar trajectory, do we get a different kind of gravity assist?

Wow the craft you've made are remarkably similar to my own (most of them) - it seems career mode funnels designs pretty tightly, at least in these beginning stages. My tourist craft is exactly the same, except I have double the fuel in the first liquid stage and a service bay between the command pod and adaptor (and I don't have the landing legs either).

I will try that next time for sure, though I've got a hunch it won't work. For now, I did one of those contracts again with pre-configured staging and it worked and I don't have any similar contracts planned.

So the contract should be done even if the part doesn't activate? Because in both the cases I mention the contract wasn't done, which is why I'm wondering if I'm making a mistake or the game is messing up.

So you're saying that whatever stage was previously active is the next one to be activated, whenever stages are re-arranged, no matter how they are re-arranged? No offense, but the lack of punctuation in your sentence makes it hard to understand what you mean.

I've had this problem several times in career now. I get contracts that want you to test X at Y conditions etc. and when that's a parachute or decoupler, the usual way to do it is to just place it somewhere (if it isn't functional to the craft) and just stage it when the conditions are met. However, many times already, I've rearranged stages to satisfy the requirement of "staging" the part rather than just activating it and most every time it results in the part's stage not working at all. I got it with the tiny stack decoupler, placed it on the mk1 module and when the conditions where met, I moved its stage to the bottom, pressed space and nothing happened. Spamming space didn't help because it staged everything else but left that stage intact, resulting in a kerbal dying. The same thing happened now when I tried to stage the mk16 chute - it remained intact while pressing space once did nothing and the next time it activated the next stage. For many of these contracts it's important to be able to stage something whenever you need to, rather than as part of a sequence, since you can't always explicitly design craft just to make sure they're in some exact point and speed so you won't have to change the staging at all. What am I doing wrong? I thought that perhaps putting the stage at the bottom of the list makes it the "current stage" somehow, so even if it isn't activated, the game just moves on to the next one, effectively skipping it. But this doesn't happen at launch (clearly) and it doesn't happen when I repeatedly swap stages on craft with only the parachutes left (I create an empty stage, place it at the bottom, stages properly - then do the same and place the chute stage at the bottom, again works properly). edit - just tested it at the launch pad, same craft - placing the chute's stage at the bottom and pressing space stages it properly.

Nice Duna craft, looks pretty solid compared to what I usually make xD Have you tried to recover discarded stages? I did some testing with the BACC boosters - it works, but it doesn't seem to allow recovering them. A shame, since it would help tons in hard mode to save money.

Not sure if it's ok to reply to this kind of thread - if it's inappropriate I'll delete the post Nice going - I'm doing a hard career myself at the moment (have only managed as far as a Mun flyby, next is the Mun orbit contract) and I can already see trends in how the early parts are handled. I did the same "hopper" kind of vessel (except I named them "Exploiter"s ) and just tonight did the plane runaround of KSC (nice mention of the crew report stacking trick btw, I've been playing for like 200h+ total and I didn't know that lol). I'm playing without saving and reverting (and mod-less) so I build my vessels in career and use a separate sandbox profile to test and practice on them before launching (and when a kerbal dies or is stranded I restart - so far I've restarted 3 times ). A couple of questions: What do you think of the minor contracts? From what I can tell, you're skipping most of them, as am I. They seem to cost more than they're worth and it also seems a lot more efficient to just go for the major steps (orbits, flybys etc.). How far did you get in your previous hard careers? By the way, that Mun flyby without patched conics is scary - I do it manually, by eyeballing the lead angle and I had no idea that it wouldn't even show me the encounter, the first time. In the two times I tried it outside of sandbox, I got a 12.5km and 16km periapsis and the first time I panicked when I left the Mun SOI and despite having enough fuel to return, I managed to waste it trying to reduce my re-entry speed and got Valentina stranded . Re-entry heating so far has no been an issue, even when entering at 3.3km/s.

You can always just disable the payload's tank until you're ready to release it.

Can't say with 100% certainty but this seems to solve the problem. I made a craft with this approach and it didnt suffer any yaw instabilities, then went back and replaced half the parts with symmetry from the others and once air started to get a bit sparse it started yawing to the left again. Strangely, the effect was nowhere near as pronounced with this craft than with others I've made, but at least it seems to be under control for now. I'm marking this as Answered for the time being. Thanks

Indeed the lowest possible stable orbit is at 70km, I probably wrote 75km because my mind averaged the 80km of the contract with 70km

I've had the "cannot deploy while stowed" weirdness happen to me as well and it was partially why Valentina died (you will be missed ). I had it happen again with Jeb on the next flight, same craft, only one of the radial chutes deployed while the other complained about being stowed. I know that fairings, service bays etc. do cause this, but while I did have a service bay, just like your craft, it was nowhere near the chutes.

This seems like a mission that requires infrastructure or encourages it. Perhaps just go with the idea of having a mining station on the Mun or Minmus, refuel orbital tugs in Kerbin and Eve orbit through ferry vessels designed for this purpose only, haul the Eve lander and Gilly tug separately to orbit, move them separately and possibly even set up the mining base on Eve beforehand. After this, pick up the contract with the final stage (Eve lander?) which should have at least the builtin storage (if not its own drill - the mining base would be for refueling) to prevent unhappy cases where the game decides you didn't actually mine the ore or something. It would be quite strange if, especially after adding mining, the contracts in career punish the use of infrastructure. The only problem is, all this would probably cost you a fortune, but I think it would be possible without a cpu-hungy beast of a craft and a single mission for everything. edit - oh btw, ISP drops further after 1atm: http://forum.kerbalspaceprogram.com/threads/116993-Helpful-1-0-observations?p=1872318&viewfull=1#post1872318 So perhaps it won't be that easy to get something to take off from Eve

Interesting. This means you can adjust the drag of parts by adding struts, or distribute the additional drag by choosing which direction you connect struts in.

Which bits explode first? Perhaps you have too many things hanging off the side (I assume not, if you're used to FAR, but I've never used it and have no idea how heat and drag work there compared to 1.02). I generally don't have a problem with overheating, just tumbling over.

You need a complete orbit, with both peri and apoapsis above 75km, AFAIK. It can be confusing when the navball says "Orbit" but you're not actually in one, as per the mission's definition.

I don't understand if this is to get around manual errors or how the game prioritizes the intakes or something. I'll try that, not really interesting in going for a mod-based solution just yet.

I didn't play much career in .90 but I can say I like career science scarcity as it is, although I am playing on hard and looking for a challenge. What I do, is exploit the little science around KSP and on Kerbin and I launch a couple of missions just to get pilot experience and science from low and high orbit around Kerbin. It's got me to the point where I have enough funds for a lvl2 landing pad and enough parts to flyby the Mun (in fact, enough ÃŽâ€v to escape Kerbin), so I'm probably close to landing, which should yield a truckload of science and It's been around 3-4 missions (I think) plus 2-3 weird launches to get cheap science from the launch pad and surrounding area.

Indeed, I'm finding the game easier with the new aero than I used to back in .23, although I might have not progressed enough yet. Excellent job getting those drills up there! It reminds me of how much easier it is to refuel now.

I was practicing for this mission in sandbox and this is exactly what happened to me on the first try - I just kept burning from periapsis and i got my orbit to pass right through the Mun - thankfully I had enough ÃŽâ€v to correct and get back. Overall, I think the only difficulty in getting to the Mun or Minmus without maneuver nodes is figuring out leading angles. For the Mun its 110 degrees if I'm not mistaken, better to start your burn when the angle is higher than that if you're just eyeballing it, rather than late, since that puts you an entire orbit behind. Definitely possible though - I've got a craft that with a lvl1 vab and lvl2 launch site can escape Kerbin if I wanted. All you need is the leading angle and you're set.

I've got a problem that may be related to this, could be the same issue at its core (only mine is asymmetrical engine thrust, only one fuel tank): http://forum.kerbalspaceprogram.com/threads/119684-Mk2-bicoupler-causes-asymmetrical-thrust-in-ramjets-%28bug-%29

You can definitely skip the heat shield, at least for lighter craft such as a capsule + service bay + 2 science jrs and chutes. I put the shield on anyway and it burns up more with a shallower re-entry (which makes some sense) but it generally isn't essential at this time. Just make sure, if you have a pilot of lvl1 and up, to have them point the craft retrograde or do it manually. I have had chutes burn up, but it was with a test flight that went straight up and fell back from an altitude of 600km, gaining a lot of speed in the process. I've also had them burn up a couple of times when I couldn't maintain retrograde orientation and they got destroyed due to being right in the drag cone. Other than these, I've noticed that even the science jr, with a heat tolerance of 1200 degrees, will still survive reentry. I'm assuming this is because it gets rid of heat fast, as opposed to chutes and certain other parts, but that's just my assumption.

Whenever I make a Mk2 spaceplane using the bicoupler that lets you add 2 engines at the rear, I have an extremely hard time stabilizing it. It consistently yaws to the left and I tried to figure out what the problem was. I didn't have any asymmetries in the design, but when I checked their thrust during flight, while it was the same between them, the left one was producing less electricity, so I'm assuming its thrust was more unstable. I added more intakes and it pushes the problem further into the future, but it always ends up happening. I've added the extra engine cooler intake at the rear, before the ramjets and have tried with 3-4 radial intakes per engine but the issue still occurs at both low and high altitudes. Is this a bug or am I misusing the bicoupler? I haven't had the same problem with multiple ramjets on other craft. Here's an example of a craft that had this issue: http://steamcommunity.com/sharedfiles/filedetails/?id=438080906