Snark

I'm sorry, I'm having trouble following, here. "Hinder creativity"? What? To be clear, I wasn't even slightly criticizing your idea or calling it "wrong" in any way-- merely observing that not everyone wants the same thing. Different people are different, yes? So, not sure what your concern is, could you explain a bit more? "Procedural parts" isn't the same thing as "reduce lag". It's just a different design philosophy, that's all. Some people like it (that's why there have been "procedural parts" mods, TweakScale, etc.) and others don't. I, for example, really like the aesthetic and gameplay consequences of having Lego-style construction. That doesn't mean I'm "right", obviously, or that I'm asserting it would be "right" for everyone-- just that I, personally, like it that way. I'm happy to explain more, but you quoted a statement of mine without saying specifically what you wanted to explain, i.e. what aspect, or what about my statement seemed unclear, etc. I'm happy to go on at more length, but it would help if I knew exactly what your concern was. Could you clarify? Prove... what, exactly? About player demand, or about what Squad has (and hasn't) been doing with KSP in recent years, or what? Would help if I had a better idea of what your specific question is. Scale doesn't have anything to do with procedural parts per se. You can have big rockets with Lego-style or procedural parts, and you can have small rockets with Lego-style or procedural parts. A reason to use Lego-style parts would be if that's what most people want and/or are used to, for example. Because I, 1. don't need them, and 2. don't want them. Don't need 'em because I can build the rockets I want the way I want to build them. Don't want 'em because I really, really don't like them. I like the fact that Lego-style parts provide a constraint for me to use my creativity to work around. I like the fact that every individual part has a well-defined set of stats. I like that each individual part is individually hand-crafted by an artist with its own unique look and feel, both for the model and for the texture. My experience with procedural stuff is that it ends up with a certain homogeneous "sameness" about it that, for me, gives the rockets much less "character" and it all just feels kinda blah to me. It's the same reason why I like having a solar system with individually hand-designed planets, rather than some procedurally generated thing like No Man's Sky did: because to me, procedural = lack of personality. I just happen to like individually crafted artwork, that's all. I'm a little concerned that you seem to be getting sorta worked up about this, as if I'm somehow criticizing you, or asserting that my way is "right" or that your suggestion is "wrong". If I've mis-read that, my apologies. However, do please understand that I'm not in any way criticizing your idea or saying that one way is better than another-- just saying that I happen to like what I like, just as you like what you like. Doesn't mean either one of us is "right" or "wrong", objectively speaking. It's just that different people like different things, that's all.

Yeah, the decouplers only have a limited amount of ejection force, and it doesn't scale up well-- especially for atmospheric flight (e.g. the lower parts of the ascent phase), where aerodynamic forces tend to be very large, and dwarf any contribution from the decoupler. Sepratrons can be good for this. Another option is to mount some small fins (e.g. Basic Fin) on the nose of the radial boosters, angled slightly outwards so that when the booster is released, aero force on the fins will pull the booster nose away from the central core, and then aero forces do your work for you by moving the booster rapidly away from your central stack.

Moving to Suggestions. It's a difficult problem, from a game-design perspective. Certainly there are people such as yourself who would like to have them-- but it's not a slam dunk, and there are plenty of people (myself included) who strongly prefer not to have procedural parts and prefer the Lego-style approach. So from the game developer's perspective, it's a hard call, given that not all players want the same thing. And changing this aspect would be a pretty expensive change to make, so I would imagine it would need a pretty strong impetus (e.g. overwhelming player demand) to make something like that happen. Given that KSP has been out for quite some time and there hasn't been overwhelming player demand, my guess would be that this is fairly unlikely to happen, at least in the original KSP-- especially given that they're not in primary development mode anymore, it's mainly "keep the lights on" with occasional DLCs. If there's anywhere this might be a feasible suggestion, I'd guess it would be KSP 2, though even there I'm guessing it'll be Lego-style. (Though they will have much better handling of colors, i.e. you'll be able to customize the main and trim colors on just about every part, so at least they should have you reasonably well covered in that one specific aspect.) Perhaps you might want to go and post some ideas over in the KSP 2 forum?

A discussion of why it would be hard would get long and have a lot of technical stuff in it that would likely be both hard to follow and not very interesting to anyone who's not a programmer. Suffice to say that it would be hard and require a lot of special-casing and likely be more trouble than it's worth. My guess is that it's extremely unlikely to happen. Way too much work and risk for nowhere near enough benefit.

Why is that? After all, it's a new game, with new content. Anything from KSP 1 that's "carried across" has to be re-implemented from scratch, not just "copied over"-- it's just as much work to do that as it would be to implement some new, original thing. So, spending more time porting KSP content across means less time providing us with new features. So, for example, consider the robotics from Breaking Ground-- that's a huge, expensive feature, with lots of code in it. And it's something that not every KSP player wants (as evidenced by the fact that not everyone bought Breaking Ground). So... it's not at all obvious to me that making the gargantuan investment of resources to provide that in KSP 2 is money well spent. I could easily see a case being made that the resources would be much better spent in implementing important new features of the game. So, is there some particular reason that you'd like to see them spending their time re-creating the various DLCs from KSP 1 (which not every player chose to buy), rather than spending that time on snazzy new features and content for KSP 2? Citation please? Where do you get the impression that they intend to do this? I certainly haven't heard that anywhere, myself. Got a link? Okay, now I'm scratching my head. You just said that you wish they'd just copy everything from KSP 1, and complained that they're not doing that. So... they've made the choice to spend their time inventing and building new stuff, instead of slavishly copying everything from the original game. That seems to me to be the precise opposite of "creative laziness". Can you explain to us how choosing to make new things instead of just copying all the old things is somehow being "creatively lazy"? Or, much more likely, that instead of including it-- which would likely delay the launch by many months and require them to jack up the price, for all users whether they want to use robotics or not-- they chose, rather, to spend that time developing cool new mechanics and content to appeal to players. Makes sense to me. Why would you expect that? This is a space exploration game, not a robotics simulator. People buy KSP, for the most part, because they wanna fly rocket ships, not because they want to build robots. And the "just a hinge, a rotor, and a piston" stuff from Breaking Ground, which you're referring to rather dismissively as if it's no big deal, is something that took Squad many months of work to provide even that level of functionality. Robotics stuff is hard, and super expensive (in terms of time and money) to implement. It's a gigantic feature. You do want KSP 2 in 2020, yes? Or are you saying you'd rather force all KSP players to wait an extra year and pay a higher sticker price because you want fancier robots? Even if you personally would prefer that, how would that be to the benefit of the player base as a whole? Why is that? If they're spending all the money to develop a game title, and if their market research tells them that a certain price point is the one that will give good profits-- which, after all, is the entire purpose of any company, and perfectly natural-- what would be the reason for them to do that? You're saying that they should lose money in order to give away free or underpriced stuff? That's... not how companies work. It's a business, not a charity. They offer a product for sale, and they pick a price for it. Nobody's forced to buy it. Individual customers can choose for themselves. Either you think it's worth $60 and plunk down the doubloons, or else you think it isn't and you take your business elsewhere. What's the issue? (Personally, at the $60 price point, I'll be firmly in the "shut up and take my money!" contingent, myself-- KSP is by far the best investment in terms of fun-per-dollar of any entertainment product I've ever bought. But you'll make your own choice about that, of course.) "This" DLC? What DLC? They haven't even shipped the game yet, and haven't even announced all the features it will have, and you're making assertions about what DLCs they're supposedly going to have, and what price it may be? Citation please? Where are you getting this information? This seems like a straw-man to the point of being a total non sequitur. They're bending over backwards and making considerable effort to make KSP 2 as moddable as possible. It's the sensible thing to do, they've stated explicitly that they're doing this, the guy in charge of designing it is a total raving KSP fanboi since 2012 and totally wants the game to be as moddable as heck, and they've demonstrated some of the moddability to those of us who were fortunate enough to visit their studios back in August. And nobody ever tried to stop any aspect of moddability in KSP 1, either-- DLC or no DLC. As far as I know, there is, absolutely zero evidence to indicate that there's any intention whatsoever to artificially limit moddability in any way, and lots of evidence that they're working on making it as moddable as possible-- at least as moddable as KSP 1, and likely more moddable in some ways. (This has been written about extensively in various threads in this subforum.) So, it seems to me, this aspect is something that KSP players who like mods ought to be turning handsprings over. So... what exactly is your concern, here?

I've always found that rejiggering the solar system can add welcome variety. New places to explore, and new ways of getting there. There are lots of good mods for this. You can add on to the solar system (like OPM), or completely replace it (like GPP), or rearrange the existing bodies (like my own Snarkiverse), or move KSC to some other body in the solar system (like Alien Space Programs).

No, because Isp. The rocket equation (which determines dV) does not care at all about thrust. It doesn't care how big your engines are, or how many engines you have. It only cares about the Isp of whatever-it-is that you're firing. If your central-core engine is firing at the same time as your radial-booster engines, and if it has a different Isp from them, then yes, the fact that it's firing does matter because the Isp of the whole group taken together won't be the same as the radial boosters' Isp, or the same as the central-core Isp. It'll be somewhere in between, as described above.

Hello, and welcome to the forums! Moving to Making History Support. FYI, not sure where you're hosting your file, but whatever you've done, it's not something that's coming through as downloadable-- you'll want to fix your link.

Much content has been removed, due to pressuring mod authors for updates, which as we all know (right?) is not okay. Aside from being rude and entitled, it's also explicitly forbidden by the forum rules, specifically 2.2.p. Folks, please remember that mod authors do this in their precious and scarce spare time, for free, as a hobby, so they can give us all shiny toys for free. As such, we owe them a debt of gratitude, but they owe us nothing-- in particular, they do not owe us "speedy" updates, nor do they owe us progress reports. We understand that you're impatient and excited, since Kopernicus is such a vital, useful mod. It's great that you love the mod, and likely you mean well. Please understand, though, that there are tens of thousands of people waiting for the update, and asking about it simply doesn't help matters. Updating a mod like Kopernicus takes a lot of time. It's many hours of work. Likely it's not even knowable in advance how much time it'll take, even for the maintainers; that's how software works. And please remember that these are people, with plenty of IRL obligations (work, school, family, etc.) which obviously take priority over a hobby such as modding. For anyone who is still unclear on the concept, perhaps a brief refresher is in order: Q: When will the Kopernicus update be ready? A: As soon as the maintainers have the time and inclination to do so. Q: No, but I mean, when? I want to know! A: It's nice to want things. However, this is not a knowable thing, per the explanation above. Q: Would it help make it happen faster if I interrupt the authors and pester them for updates while they're trying to get stuff done? A: Why, no, as a matter of fact. No, it wouldn't. Breathing down people's necks and jostling their elbows does not, oddly enough, help the efficiency of the process. Thanks for asking. Q: But then what can I do? A: You can be patient. Just like everyone else is. Q: But being patient is hard. A: Then you could always find some other toy to play with that won't require patience from you. Thread is now unlocked; please don't make us regret doing so, okay? Thank you to everyone for your continued patience and understanding.

Here's an illustrated guide that may help take some of the guesswork out of it. It's a straightforward step-by-step process that completely involves just watching the little icons on the navball, which helps eliminate "mental 3D gymnastics" from the equation: You absolutely can do x-y alignment (translation) with the navball-- it's a matter of learning how to work with the markers (and, conversely, markers) on the navball. See the illustrations in the guide linked above.

Yah, that makes sense. Though I've found that, conversely, there's a different reason why having yaw authority in KSP is helpful for landings. In spoiler, since we're starting to get off-topic from the original person's question.

Folks, a gentle reminder not to get into politics, and this includes comparing / contrasting / making assertions about what happens in different countries. Please drop the matter, thank you.

Yes, of course, it absolutely matters where control surfaces are. That's the most important thing about them. Remember, control surfaces don't generate "torque" inherently, at all They generate force. They're used to make torque, by virtue of applying that force at right angles to the lever arm between themselves and the CoM. And torque equals force times distance. Double the distance, double the torque. If the distance is zero, the torque is zero. The farther from the CoM you place the control surfaces, the more their control authority for pitching / rolling / yawing the plane increases-- in direct proportion. Yes, exactly. That's exactly it, that's how it works. You've heard this all over the place because that's how reality works and that's how KSP works. Really? I've never heard anyone try to claim that, at all. I mean, I've seen plenty of folks who didn't realize how the placement matters, simply because they weren't familiar with the physics involved, but to actually claim that it doesn't matter? Not the case. (In sharp contradistinction to, say, reaction wheels, where the placement doesn't matter because they directly generate torque, unlike control surfaces which only generate force. But that's not what we're talking about here.) Well, it's helpful for doing yaw maneuvers, and also extremely helpful for maintaining yaw stability. Not sure how the presence or absence of "wind" enters into it? I mean, unlike pitch and roll, it's not an absolute requirement, but it's certainly helpful in a variety of circumstances-- I wouldn't go so far as to say "no need".

Moving to Gameplay Questions. Regarding the plane: Your CoM is way far towards the back of the plane. This makes it aerodynamically unstable, plus your control surfaces are too close to the CoM so they can't help much. Try moving the CoM forward, plus I'd suggest bigger stronger canards up front. Make sure you've disabled roll authority on the tail fin.

Thanks. I got tired of forever having to link people to an archived page, and couldn't stand it any longer, so I just now went and ported it to the Tutorials subforum here: Hopefully that'll make it a bit easier for folks to find.

After just getting something into orbit (and perhaps a Mun landing), the next big challenge for a new KSP player is how to dock in orbit. Here's a step-by-step illustrated guide for how to do so. (There are various techniques... and plenty of other guides out there. This is just how I like to do it. I hope you may find it useful.) (Author's note: Please forgive the out-of-date screenshots. This post is ported from a blog entry I made on an older version of the forum software, back in 2015, so screenshots reflect what KSP looked like at the time. The appearance has changed a bit since then, but everything I wrote here still applies.) The big picture Docking proceeds in four main steps: Rendezvous. This is the part where you use maneuver nodes to arrange for your ship and the target to be in the same place at the same time, or at least as close as possible. Careful fiddling with the maneuver node will generally get you a rendezvous within a kilometer or so. Fine tuning the rendezvous. This involves making small burns as you approach the target, in the last few kilometers, so that your closest approach is zeroed in to a few dozen meters (from the kilometer-or-so you got in step 1). This involves close observation of the navball and light touches on the throttle. Kill relative velocity to target, right when you're at your closest approach. Also a navball-and-throttle operation. You're now parked right next to the target, just a few meters away. Actually dock. This involves eyeballing docking port alignments in the camera view (unless you have a mod installed to show docking alignment on the navball, which is a big convenience). This is where you use your RCS thrusters to jockey for position. The following sections go into detail on these steps. Step 1: Rendezvous Navigation tool: Maneuver nodes and map view Control via: Main engine and throttle The first thing you have to do is to send your ship on a course that will put it and the target in the same place at the same time-- or, at least as close as you can get with maneuver nodes. I'm assuming here that you in fact have maneuver nodes (i.e. you've unlocked them by upgrading the tracking station), and also that you're familiar with how to use them. I'm also assuming that you know how to set up a fairly good orbital rendezvous with maneuver nodes, i.e. one that will get you a closest approach within a kilometer or two. This is a big assumption: doing that is actually a significant challenge, and if you're a new player just learning how to dock, there's a pretty good chance you may not have mastered "orbital rendezvous with maneuver nodes" as a skill yet. However, I'm not going into it here, for a couple of reasons: It's a whole complex topic in its own right, and this blog post is about docking rather than general orbital navigation. (I may add a "how to rendezvous" post at some time in the future, in which case I'll link to it from here. If my glossing over this part is frustrating, please let me know so that I can gauge demand. ) Here's a handy guide to rendezvous (not mine). The details of how to set up a rendezvous vary a lot depending on the starting situation (e.g. launch from surface to direct intercept, or two craft already in orbit, are their orbits coplanar or not, etc.). But even though I'm not telling you how to do it here, I can show you what "good" looks like: Exactly what your own situation will look like depends heavily on circumstances. But the important bit is that it's a close rendezvous. You want the closest approach to be as close as you can manage with the maneuver node-- no more than 2 km at most, preferably under 1 km. (In the above example, it's 0.3 km, which is pretty good.) One more side note: See how the target (yellow) line and my own ship's (cyan) line are crossing each other like an X, rather than being close to parallel to each other at the point of intersect? That's actually pretty bad: it means that they're orbiting in significantly different directions at the point of intersect, which in turn means that they're going to have big relative velocity to each other, which means I need to burn a lot of fuel. I've done it that way deliberately, here, so that this guide can show you "how to dock" even if the situation's not perfect. Ideally, you will set it up better than this, so that their relative velocity at closest approach will be smaller, and therefore your job will be easier in the remaining steps. Step 2: Fine-tune the rendezvous Navigation tool: Navball and map view Control via: Main engine and throttle Your eventual goal (in step 3, below) is to coast to a stop so that you're parked right next to the target (as in, just a couple of dozen meters apart). Chances are, however, that unless you're either super lucky or an ace at maneuver-nodes, the rendezvous that you set up in Step 1 above will only get you to within a few hundred meters at best-- perhaps a kilometer or two. You'd like to be closer than that when you match velocities, since your final approach (using RCS) will be very slow, just centimeters per second, and you don't want to have to do that for a kilometer or more. So the way to solve that is to make minor course adjustments with light touches on the throttle of your main engine, using the navball for guidance. Here's how: First things first: Make sure navball is in "target relative" mode Once you get close to the target, you don't care what your orbital velocity is. You only care about your velocity relative to the target. Chances are, the navball is probably in "Orbit" mode when you're in orbit (the game does that automatically, unless you've manually tinkered with it). Normally, when you approach your target within 60 km, the navball will switch automatically to "Target" mode instead of "Orbit": this causes your prograde/retrograde markers to indicate your target-relative velocity rather than your orbital velocity, which is what you want. It looks like this (note the "Orbit" or "Target" indicator at the top of the navball): ...Typically, it will do this automatically for you and no action is required on your part. I only bring it up because it's possible this might not happen, and you need to make sure that the navball is in "Target" mode, or nothing after this point will make any sense. You can change the mode manually by clicking on the label. This will toggle the navball between Orbit, Surface, and Target modes. Why this fine-tuning step is needed As you get within several kilometers of your target, your navball will start to look something like this (again, make sure your navball is in target mode): This looks pretty good: your marker (target relative velocity) is pretty close to your marker (target direction). The fact that these two are close together means that you are heading almost directly towards your target. However, the key word here is "almost". If you just coast towards your target and do nothing, you'll see the marker slide farther and farther away from the marker, like this: That's because you're not heading directly at the target. Unless you got super lucky (or are an ace) with the original maneuver node, your closest approach is likely to be at least several hundred meters away from the target. This means that without any course corrections, you're going to go past it, and the target will slide off the side of your navball in the same way that someone standing beside the road slides off to the side of your windshield as you drive past them. Therefore, you need to adjust your course when you get close by, so that you are sitting right next to your target (and not a kilometer away) when you come to a stop relative to it. What to do When you get reasonably close to your rendezvous (say, when it's 1 minute away, which you can see in the map view when you mouse over the intercept marker), start the process. What you're trying to do is to move your marker so that it's precisely centered on your marker (i.e. so that you're heading directly at the target). To do this, start by lining up your navball so that your crosshairs, , and are exactly lined up in a straight line, like this: Note that the marker is exactly on a straight line in between the navball crosshairs and the marker. Why do we do this? Well, firing your engines "pushes" the marker away from the center crosshairs on the navball. Since what we want to do is move the marker onto the marker, then by lining the navball up this way, it will "push" the marker in the direction we want it to go. Once you've got it lined up, gently throttle up to move the marker. How much throttle you need will depend on your ship's TWR and how big your target-relative velocity is. So just keep a careful eye on the navball, gently throttle up, and be ready to kill the throttle immediately when things line up. As your engine burns, you will see the marker drift towards the marker, like this: When the two markers line up perfectly, cut throttle. (Don't worry if it's not pixel-perfect; all that matters is that it's better than it was. If you're off by a smidgeon, what will happen is that as you get closer to the target, the two markers will drift apart again, and you can do this correction maneuver again. Repeat as needed.) Prograde fine-tuning (if you end up too slow while still far away) In the preceding discussion, we did all our fine-tuning while thrusting close to . I recommend this because it kills two birds with one stone, thus saving dV: not only does it fix our heading to get a close approach to the target, but it also helps kill some of our velocity (since we'll need to reduce that down to zero in the next step). However, it could happen that you end up approaching too slowly while still far away: i.e. your target-relative velocity is very low while you're still at a long distance. In such a case, fine-tuning in the prograde direction is an option. Details in spoiler. Step 3: Kill relative velocity to target Navigation tool: Navball and camera view Control via: Main engine and throttle This is the easiest part of the process, since there's little steering involved. All you have to do is slow down to a stop in the right place. As you approach the target, line up your navball so that you're pointing perfectly retrograde (i.e. the marker is centered perfectly in the crosshairs-- again, make sure your navball is in target-relative mode, not "orbit"). If you have a level-1-or-better pilot, or if you have a HECS-or-better probe core, then this is easy: just choose the "hold retrograde" SAS button (red arrow in the illustration below). But if you don't have that convenience, just do it manually. As you approach the target, the marker will want to drift away from center; if necessary, you can do more correction as described above in step 2. Reduce your speed gradually as you approach the target. If you wait too long, you'll overshoot; if you start too soon, you'll go too slowly and it takes forever to close the distance. I find that a handy rule of thumb is "stay 30 seconds away from intercept": switch to map mode and mouse-over the intercept marker, which will give you a timer countdown to closest approach. Thrusting to slow yourself down will increase the time-until intercept. Just keep that at 30 seconds until your speed gets down to whatever you're comfortable with (I usually go for around 10-15 m/s), then switch back to camera view and you can eyeball it the rest of the way. When you get really close, slow yourself to a stop, 0 relative velocity. You're now parked right next to the target-- if you got things lined up well up to this point, you'll be very close, just a few meters away, like this: Step 4: Prepare to dock Navigation tool: Navball and/or camera view Control via: reaction wheels only First, get roughly lined up. We need to get the docking ports at least approximately lined up (facing towards each other). If possible, the easiest way to do this is to switch briefly to the target ship (using the [ ] keys) and rotate it so that it points its docking port towards your ship, then switch back and rotate your ship appropriately. This is a lot faster and easier than flying your ship around the target to get in the right spot, which is tedious. (Sometimes that might not be an option, if it's not practical to rotate the target-- for example, if your target is a huge, massive, asymmetric space station with random stuff docked all over it. In that case you just gotta fly your ship to where it needs to be.) Next, set your target and control-from to the two docking ports. Right-click on the target docking port and choose "Set as Target": Right-click on your own ship's docking port and choose "Control from Here": Now, get your orientation precisely aligned. That is, you want the axis of your docking port and your target's to be precisely parallel. (They may be laterally offset from one another for now, but we'll deal with that next). There are a couple of ways to do this: Option #1: Use a docking-alignment mod. My personal favorite is Navball Docking Alignment Indicator. It's very minimalistic, uses no screen real estate, stays out of my way when I don't need it. What it does is this: whenever your target is a docking port, it adds a red icon to the navball showing your alignment relative to it. When that red icon is perfectly centered in your navball cross-hairs, it means you're perfectly aligned for docking. So if you have this mod installed, all you have to do is rotate your ship to center that red icon. Your navball would then look like this: ...all you need to do is to rotate your ship to center the red icon in the navball crosshairs. Option #2: Just eyeball the orientation. This is doable but less convenient. Not only do you generally have to monkey around with different camera angles, but it also becomes a royal pain in the dark, since you can't see what you're doing unless the ships are lit up. This is what I did for the first several months (and several hundred dockings) in KSP, until I got fed up and switched to option #1. Really, that mod ought to be part of the stock game, IMHO. Either of the above two options will work. For the remainder of this discussion, I'll use screenshots that have the mod present, not only because that's how I do it when I dock, but also because it makes the screenshots much easier to understand. Next, turn on fine-control mode. This is caps lock by default (on Windows machines; I think it may be different on Macs). Doing this will turn your control indicators at bottom-left from red to cyan, like this: ...The reason why you do this is described in another blog post, but what it boils down to is that it makes your RCS thrusters smarter so that it's easier to control your ship. Next, activate RCS (press R). There, we finally get to use our thrusters! Step 5: Dock! Navigation tool: Navball and/or camera view Control via: RCS thrusters Okay, now the fun part. Thrust gently prograde using your RCS thrusters until you get your speed up to 0.2 or, at most, 0.3 m/s. Slow slow slow. Your ship is now heading directly straight ahead. However, that's not quite right yet, since the target is offset to the side by a bit. We need to apply some lateral thrust in order to get us heading in the right direction. Initially, your navball might look something like this: How to read this: You're pointing in exactly the right direction: the red icon (from the mod I discuss above) is perfectly centered in the crosshairs, indicating that you're aligned correctly. Your position isn't quite right, because the target isn't directly in front of you. The is off to the left, instead of perfectly centered in the crosshairs where we want it. Your velocity isn't quite right, either-- the marker shows that you're moving up and rightwards as you drift forward, whereas your target is off to the left. So now you need to use your RCS thrusters to correct that. Use your lateral thrust (IJKL for up, down, left, right) to nudge the marker to where it needs to be. You want to arrange it so that the marker is directly on a straight line between the marker and the center crosshairs, like this: ...What this means is that as you drift towards the target, you're also drifting sideways so that you're lining up with it. As you get closer, you will see the slide towards the center crosshairs. As it gets closer to the center, you can nudge the marker inwards, too (using RCS), still keeping it lined up: When the marker reaches the center of the crosshairs, use RCS to center the marker there, too. You're now all set up perfectly for docking: Centered red icon = you're facing the right way Centered = the target port is right in front of your port Centered = you're traveling directly towards it Now all you have to do is just let it coast until docking completes. Ta dah!

Aerodynamic instability is a strong possibility. Where's the CoM on this beast as it sits ready for liftoff? If it's very low, that's likely to be your problem right there. A really low CoM would cause two problems, both of which would make the thing very unstable. First, it would have a long draggy fuselage sticking out in front of the CoM; and, second, the fins and gimbaled engines at the back would have a reduced lever arm (due to being too close to the CoM) and would be therefore have much less control authority, i.e. much less effective at stabilizing the craft.

You're welcome. And just to be clear, the rules say that everything posted outside the international forums needs to be in English, even if everyone in the conversation is able to speak the other language.

If you hover the mouse over the UI control at top left that looks like "cell phone signal strength" bars, it'll show you your communications path back to KSC. That, at least, will tell you what you're routing through. What does it say?

The earlier comment from @Laie perfectly covers this, exactly as already stated: Exactly this. However, there is one additional complication. If you're firing multiple engines at the same time, and those engines have different Isp values, then coming up with the combined Isp of the engines (in order to work out the dV) requires some additional calculations. If you have some set of engines E1, E2, E3, etc., such that their thrust values are T1, T2, T3, etc. and Isp values are Isp1, Isp2, Isp3, etc., then the combined Isp from firing them all together is calculated thus: Isptotal = sum(Tn) / sum(Tn/Ispn) You can simplify the math by treating a set of identical engines as one big engine. For example, consider your craft that you pictured that above. If I read that correctly, you're lifting on: one Mainsail six Reliants Let's say you want to work out what your Isp is for that rocket, sitting on the launchpad in atmospheric pressure. Well, each Reliant has ASL thrust of 205.16 kN, and an Isp of 265 s. So, you can treat them all together the same as if it were a single engine that's 1230.96 kN, Isp 265 s. The Mainsail? At sea level, its thrust is 1379 kN and Isp is 285 s. So, to find their combined Isp, we just plug into the above equation: Isptotal = (1230.96 + 1379) / ( (1230.96/265) + (1379/285)) = 275.2. So for the combination of engines here, the launchpad Isp would be 275.2 s.

Moving to Gameplay Questions. Nope.

Folks, just a gentle reminder that anything posted outside the international forums needs to be in English. If you'd like to post in French, there's a French forum for that. Thank you for your understanding.

Some off-topic content has been removed. Folks, a gentle reminder that this is the Kopernicus thread; please try to keep discussion to that topic. Thank you for your understanding.

Moving to Gameplay Questions, since it looks as though this is an issue about "how to play the game".

Various content has been removed due to the thread getting completely derailed into arguing-about-arguing. Let's try to keep it on topic, folks. And while we're at it, please try to be reasonably polite to mod authors. Modding is a time-consuming and thankless task, which modders do simply because it's fun (it's not as though they're getting paid for this). So, anything you do that makes it less fun-- such as being rude to mod authors-- accomplishes nothing helpful. All it does is discourage modders, which I don't think any of us wants. Thank you for your understanding.