AHHans

Hi, welcome to the forums. No. ... O.K. O.K. I'll (try to?) explain that a bit: the way that crafts are modeled internally means that every part can have only exactly one upstream (in the direction of the root part) connection / part. I.e. from every part there can be only one path to the root part. Connecting an SRB via two decouplers (or pylons or whatever) to the same central core would mean that that there are two paths from the SRB to the root part, so that is not possible. The struts are more a variation on that rule than a violation of it: they are attached to one part, and then they point in a certain direction and transfer forces to the first part that they find. If you don't like the looks of the normal struts, then you can try using autostruts. (You need to activate "Advanced Tweakables" in the settings if you haven't done so already.) If you do so then I suggest to use "autostrut to grantparent", the other settings can be dangerous under certain conditions. But in general, there is a reason why "more struts" is the got-to solution to many KSP design problems. I usually first try to place the decoupler in a way so that it tilts the top of the SRBs outwards so that the airflow will push the SRBs away from the core. Often I also attach small airfoils (typically the "Basic Fin") to give the air some more area to push against. A "simpler", more reliable but also more expensive method is to attach sepratrons to the SRBs that will push them away from the core when staged.

That shouldn't happen, if everything works then you can load any (non corrupted) save-file at any time. Even one saved in another playthrough. (E.g. loading a career mode save-file in a sandbox game.) So I think this is less a gameplay question, but more a case for tech-support. For this I also suggest to have a look at: https://forum.kerbalspaceprogram.com/index.php?/topic/83213-stock-support-bug-reporting-guide/

One neat trick that I got from a Scott Manley video is to put flags at the ends (just outside of) of the runway. That done, you can set the nearer flag as the target and have a much more precise marker for the direction in which to fly to get to the runway - both in azimuth and elevation(!). Then you should position your craft so that this marker is exactly at the 90 deg or 270 deg line of your navball. And finally: training, training, and more training. I, too, used to suck at landing in KSP. But after doing it often enough I now manage to hit the runway (and not crash) more often than not.

Have you tried double-clicking on the craft that you want to target? (In the non-map view, once you are close enough that you can see it.) Oh, are you playing on PC or on console?

Oh, I didn't want to say that it is impossible to run out of Xenon, or anything like that. And having "infrastructure" (i.e. different craft that mine/collect the Xenon and other that actually use the Xenon) is certainly something that can be done in KSP and makes some sense. (Might even make more sense in real life - if we ever get that far to build serious infrastructure in orbit of other planets.) I just wanted to give some possible reasons why SQUAD didn't implement in-situ Xenon mining.

I think another reason - both for in-game and in real life - is that ion engines are not really suited for planetary landers. If a body has enough gravity to keep an atmosphere, then you cannot realistically launch with only ion engines. Distilling Xenon out of the soup that surrounds Eve should indeed be rather straight forward, but then what? You don't have enough TWR to get off the ground. In-game I also didn't feel the need for mining Xenon: it is easy to bring enough Xenon for a couple of hours at full throttle. Mining even more Xenon would mean that I would have to wait even more hours while the craft slowly accelerates...

Don't worry, you were right. The default is the longest variant. But to get on topic again: if you are still struggling, then you can attach the next stage without attaching any engines to see where the attachment node of the engine plate is. That should be a bit easier.

Well, in this case I was probably wrong.

To summarize the answers already given: you lost touch because you left communications range of the HG-5s. (They are only good for communication within the Kerbin SOI.) A very helpful explanation of the communication in stock KSP is the wiki page about CommNet.

One comment: the engine plates have different variants that gives them different lengths. IIRC the default is the shortest variant, in this case the lowest node may not be the one from the engine plate but from the central engine.

Sounds to me like you are having trouble with the "differently curved" issue in LKO. But without knowing where exactly your problems are it is quite hard to give you more specific help. Two more things that might help you: when considering the speed (and thus the amount of thrust I use) with which I move around a target, then I think mostly in terms of "time to target" (and how long I need to slow down with my TWR while I'm still far and fast). E.g. when I'm 1 km away then at 100 m/s it will take me 10 s to get there, at 100 m I need to slow down to 10 m/s so that it will take me 10 s. The other is the "Fine tuning the rendezvous" section in @Snark's: Illustrated guide to docking

There are two effects: one is that at small relative velocities even a small change in absolute velocity can result in a large change in the direction that the velocity points to. This is the reason why SAS will not to prograde-/retrograde-hold anymore if you get below 1 m/s. If it would try to do so and you keep pushing with your engines, then it would start wildly throwing the craft around every which way. The other one if that in LKO the orbit is quite curved and if you are not already at zero-zero with the target (i.e. directly next to it with 0 m/s relative speed), then your orbits curve differently and you'll start drifting away over time. The practical solution is to either use very small thrust (e.g. - but not limited to - RCS), or to just not bother. For your average rescue mission in which you EVA the rescuee over to you craft anyhow you don't need to get to a zero-zero intercept. Being 50 m away with 1 m/s relative velocity is already pretty good and allows you several minutes to gather the the rescuee. For my rescue missions I don't bother getting that close. My limits are: closer than 1 km and less than 100 m/s, but that requires quick reactions to get the rescuee out of their capsule and pointed towards the rescue craft. So I usually get onto a trajectory that brings me closer than 100 m, slow down to 10 - 20 m/s or so, and get the rescuee out of their capsule when I'm 1 km or so away. You do need the zero-zero intercept for docking, but that is another kettle of fish.

In my limited experience the "bounciness" of the robotic parts is a lot less bad than the bounciness of the landing gear. I think that is because the restoring force of the robotic parts is not a (badly modeled) spring but the engine power of said part. Thus my suggestion to mitigate this by reducing the mechanical load on the landing gear.

Not implemented (yet?), see: Bug #23179 Did you do the test on how much engine torque you need, that I suggested? You can also try adding more propeller blades to the engine. To find it you need to find where your copy of KSP is installed, and in there in "saves/<YOUR_SAVEFILE_NAME>/Ships/SPH/<YOUR_CRAFT_NAME>.craft" E.g. my test plane that I just did is in: "/data/SteamLibrary/steamapps/common/Kerbal Space Program/saves/sandbox/Ships/SPH/Prop Plane Turbo.craft" Publish that file on a file-hosting service like Google-Drive, or Dropbox, or whatever, and post the link to that here.

I think I did this after a fashion with this craft: ETS. But I didn't encounter the problems you describe. My guess(!) is that after docking one of the crafts pushes the other one into the ground, and then the landing gear (or legs or wheels) start their (usual ) jumping around. What could help is: a) not having the stationary mining rig on landing legs, but on girders with grip pads. (I.e. retract the legs after landing.) And / or b) reduce the torque on the robotic parts so that they can barley lift the docking boom that they are supposed to move. (In the hope that this will reduce the stress on the landing gear.)

The math is the same as if you use a more traditional staging. The rocket equation doesn't care how many engines you use to accelerate your craft, or where each engine gets its fuel from. It only cares about "total mass at start of the stage", "total mass at end of the stage", and "effective velocity with which the lost mass was ejected" (the latter usually being calculated as "average Isp times 9.81 m/s^2"). So calculating the dV for each stage is straight forward (but tedious): record full mass and average Isp at the beginning of stage empty all tanks of stage in editor record empty mass at the end of stage remove all parts that will be staged away in editor rinse and repeat until you did all stages In reality there are two complications: one(*) is that the dV calculations of KSP get easily confused when you set up complicated fuel transfer schemes. (It usually does well enough when you use the external fuel duct, but often screws up when you manually change the fuel transfer priority.) The other is that you probably don't manage to (manually) stage away the empty parts at the exact moment when the tanks are empty, so you probably still have some more empty mass with you than the idealized calculations were assuming. (*) O.K. I wrote that before I remembered that you don't have that feature (yet, hopefully!) in the Enhanced(*cough*) Edition, but I didn't want to delete it. P.S. If you use engines with different Isp at the same time, then you need to calculate the average Isp, by doing a weighted average over all (simultaneously firing) engines with the rate of fuel flow as the weight.

If you don't see that option in the PAW, then you may need to activate "Advanced Tweakables" in the settings. Also: please let me know if that does work, I don't know if it will.

Normally no. I haven't tested it myself, but I think if you set on both docking ports "Same Vessel Interaction" to yes, then they may dock to each other. Same for two docking ports that were moved to each other with robotic parts.

Disclaimer: I don't know RO, RSS, RP-1, or MechJeb, I essentially only play the stock game. That means that either the game or MechJeb got their math wrong. (Well, probably more: "have different ideas about the relevant parameters".) What does the game show you about the start and end mass of the stage and the Isp? Are you still in atmosphere (as thin as it might be)? What is start and end mass of the stage after the burn? (I.e. did the end mass change?)

You are not really missing anything. But when I switch from map view to vessel view a few minutes before the (predicted) intercept, then I kind of assume that I'm closing. Also when I set my vessel to point target-retrograde and I see that it is pointing its ass - errr ... the end with the rocket engines - towards the target then I also know I'm closing. And finally if I see target-retrograde marker on the navball next to the "retro-target" marker (this one: ) - or prograde next to target - then I'm also closing. Are you talking about setting up the maneuver node, or actually doing the burn? For the first one see @Goody1981 comment: I use the mouse wheel (one "click" at a time) for fin adjustments. For the second: it's a combination of practice and reducing the engine thrust. Sometimes I also do some corrections with small puffs of RCS.

There's your problem, you are missing the wings! SCNR! O.K., jokes aside. First the easy part: Yes, that's intentional. If you don't want this, then you can remove the turboshaft engine from the "Brakes" action group. Another issue is that if you only have one propeller, then you have to counteract the torque from that propeller with your controls. (I.e. ailerons, reaction wheels, or - if you are crazy enough - RCS thrusters.) Depending on your plane the severity can go from being a mild annoyance to making your plane unflyable. The way you phrase this sounds like you have problems getting up to speed, is that correct? Even the small turboshaft engine is ridiculously overpowered for a small plane, but it can be that you don't have enough propeller area to convert that power into thrust. For my small planes I use two of the largest propeller blades with a small electric motor. If you set the deploy angle to 90 (i.e. have the blades perpendicular to the air), which torque setting do you need to get the engine to max RPM? Otherwise there isn't much I can say. It would help a lot if you would post the craft file of your plane.

In the map display you can switch on the display of commnet connections. You probably have a relay somewhere that you weren't aware of. Also the radio waves can "bend" around the planets somewhat(*). Well, if your closest relay is really close then it doesn't matter if you are using a weaker or stronger antenna on the rover. If the first leg of the connection is already at 100% with the internal antenna in the probe core, then a stronger antenna cannot improve that. (*) This is a real thing, but - as usual - KSP overdoes this.

My $0.05: for a rendezvous in low [Kerbin/Duna/Eve/whatever] orbit, I fiddle with the maneuver nodes until the predicted closest approach is way closer than 10 km. I usually go to at least less than 1 km, with 0.3 km being a typical value. Then while performing that maneuver I keep an eye on the closest approach in the approach info tab in the maneuver display (that was introduced with KSP 1.7), to see how close I can get. Then, during the approach, I follow the method outlined in @Snark's Illustrated guide to docking to refine my trajectory and get close to the target.

Assuming that you didn't hit a more serious bug, it could be that some spurious input locks were/are active. You can go to the cheat menu (<R-Shift> - <F12> on Linux, afaik <L-Alt> - <F12> on Windows) and got to "Console" -> "Input Locks" and click on "Clear Input Locks". That helps with many similar issues.

I personally would not. Since 1.7 all the really important information is also displayed by the stock game. But it's really up to you, if you like KER or mechjeb (or whatever) then go ahead.