AHHans

Are you using a script to launch the satellites? Because I'm sure that I couldn't do a manual launch precise enough for the tiny distance of the launchpad from the equator to matter. I would use one of the following three approaches to this issue: Just don't care about the tiny difference in orbit. (Well, yes, but it is what I would do. ) Adjust the orbit of one of the satellites to the orbit of the other once in space. Launch both satellites on the same booster into an elliptical transfer orbit - with a convenient resonance to the target orbit - and detach them so that they are at the correct phase angle. If you can do your launches precise enough, then adjusting the launch times should give you the needed correction. To get the value of the correction, you can also look at the angle the that orbits of the two satellites have to each other and convert that into a difference in launch time.

Hey, thanks for the nomination! Now we need some talented engineers to help me getting the rocks into the air.

Well, the Go-ob ED didn't loose connection as such, but it shut itself down after it thought that it did its job. The deployed science works in the way, that while they are working every now and then (every 10% of science gained?) they try to connect to the KSC and transmit their science. If they cannot transmit at that moment - either because there is no commnet connection (at that moment!) or no power (e.g. because the solar panels are in darkness) - then they keep the data and continue on. If they have a connection at a later try then they transmit all data that has been accumulated up to then. But once they reach 100% researched science they do another try to transmit data and then shut themselves down, even if they couldn't transmit their data. So if you have a setup with spotty commnet connectivity or are just unlucky then it can happen that whenever the experiments try to transmit their data this fails for some reason or another. And when they reach 100% researched science they give it a final try, fail again, and then stop trying altogether. The only way to "fix" this that I know of is to go there with a Kerbal - preferably a scientist - pick up the experiment, and place it again. This resets the experiment and it can try from scratch. Yes, this sucks. Welcome to the club.

The relevant setting is the one for "Terrain Shader Quality" you only get the new look for the Mun (and all the other bodies) if that is set to "High" or better (available in 1.9).

I believe (hope?) that helicopter rotor disks don't tilt that much under the forces of the cyclic. (I think the main force is still "keeping the craft in the air" and that the control forces are just a minor variation of that.) But that's actually my point: I think that in contrast to what is claimed by some, there is no device that tilts the whole head assembly with the resulting kink in the drive shaft. (The more I think about this the more I come to the conclusion that helicopters are pure maintenance nightmares, even without moving around major load-bearing structures.)

But that's my actual question! And a document that is aimed at teaching pilots how to use the craft is IMHO not the best technical reference. Especially if it shows that the craft has a swashplate at each rotor and doesn't say anything about a device that actually tilts the rotor head assembly. And I wouldn't be surprised if in helicopter-pilot speak "tilting the rotor disc" means "using cyclic blade-pitch control to direct the thrust of the rotor disc". (Actually I believe that most pilots don't really care how system actually works as long as it points the thrust where they want it.)

Do you have proof that the CH-47 Chinook is indeed tilting the whole head assembly and not just using cyclic control to reach the same effect? In KSP you would have to tilt the whole assembly because of the way cyclic control is implemented.

Yes, I'm sure. And, yes, that's annoying. You can still salvage that mission, even if you don't have a docking-port on the lander. You can send a tug with a Klaw and return the lander that way. IMHO that is a fun mission in its own right, but feel free to disagree.

Yes, in a way. Any command module (a probe core, a cockpit, a command capsule, etc.) has an internal "flight recorder" that records where it has been (in orbit around Kerbin, landed on the Mun, whatever). To fulfill the "land on Eve and return" contract you need to recover a command module that has "landed on Eve" in it's "flight recorder". So, no, you don't need to return the root part of your rocket, but the command module that you used on your lander. (Or one of them if you e.g. had a crew capsule and a probe core.) You don't need to redo the full mission if the lander still exists, you can also retrieve the lander from Eve orbit. (Or you can use the cheat menu, that's always a possibility.)

I'm pretty sure that the CH-47 Chinook and other tandem rotor helicopters use regular swashplates and don't actually "bend" the central axis of the rotors. In the descriptions I found they show that the CH-47 does have swashplates fore and aft, but I haven't seen any mention of a coupling that allows it to tilt the central axis. Also the cyclic control has essentially the same effect as physically moving the plane of rotation of the rotor: the direction of thrust the the rotor generates changes. I believe that in the cited document (and others) the control is shown as tilting the rotor because that is easier to display and understand and not because the rotor really physically changes.

Well, in real life adding more dV to an interplanetary probe is way more expensive than computer and scientist time. So they spend serious amounts of computer an manpower to optimize the flight path to use as little dV as possible. (Well, probably within the boundary of not extending the flight time too much.) Planning such a trajectory is probably as much an art as it is science. I think one thing they do - and which would be hard to do in KSP - is that they plan the path as much backwards as they do forwards, i.e. they not only start with the trajectory around Earth and what maneuver would get them closer to the target, but also with their target orbit (around Jupiter or wherever) and what maneuver would have gotten them there from an orbit closer to Earth. And then try to match both up. I'm sure you also could do this in KSP - which would be a lot easier because KSP doesn't use multi-body gravity - it is not what I consider "fun".

That depends on your airspeed. High blade pitch at low speeds means that the angle of attack is too large and the blades stall, low blade pitch at high speeds means that the AoA is too low or negative and the blades don't generate lift. Have a look at the design notes for some more explanation. IIRC it was something like 12 deg at the start of the take-off run and up to 33 deg at 120 m/s. If you don't want to change the blade pitch then 24 or so seems a good compromise. P.S. Btw. I use low blade pitch (down to 0 or even negative) to stop my propeller planes (in the air or on the runway).

Neither! If you want an answer that is more helpful than that, then please let us know what you actually want to do. Without knowing that we cannot tell you how to efficiently get it done.

No. You need a positive angle of attack on the wings for the wings to generate any lift. (At least in KSP, which is rather simpleminded in this regards.) Having a slightly positive angle of incidence on the wings can help you reduce drag by giving you that positive angle of attack on the wings while the main body of the craft is pointed straight into the direction of motion and thus has the least amount of drag. At higher speeds you need only a smaller angle of attack in order to have the wings generate enough lift to keep your plane in the air. So, indeed, the optimal angle of incidence for a high-speed aircraft is smaller than for a low(er) speed aircraft. But in both cases it is positive. That is actually somewhat risky. The CoL display in the editor shows only the center of what KSP considers lift, not the sum of all aero-forces. And the latter are what is important for stability. For "slow and low" flying aircraft that is usually fine, as the "lift" forces dominate. But for "high and fast" craft the drag becomes more and more important. So if you have lots of parts with more drag than lift - like your typical fuselage sections - in front of the craft and the lift-generating wings more at the back of the craft, then the actual center of the aero-forces will move forwards when you get higher (into thinner air) and faster. I'm not saying that this is a problem for your craft, but it is something to look out for. (AKA remember if your craft does become unstable and flip out when you get into thin air.)

Well, aero control-surfaces in KSP work in the way that they can change their deflection, thus angle of attack, and (hopefully) the lift they generate. If you have two rotor discs rotating in the same plane, how can you generate a yaw torque by changing the lift of the rotor blades? (Short answer: you can't.) What you can do is change the RPM of the two rotors so that one generates more torque than the other. The resulting uncompensated torque will rotate the craft in the yaw direction. I did this for the roll control (which is yaw in craft that have the control direction forward and not up) on my Basic Quadcopter. One problem of that solution is that SAS (or the manual trim) will not use self-defined axis groups for control, see also this forum post.

What exactly happened? The Kerbal (your pilot I presume) lost it's hold on the ship - either because you pressed <SPACE> while on EVA or you moved away from the hand-holds on the ship - and the the ship and Kerbal drifted apart from each other? Are they still fairly close to each other or is the Kerbal far away from the ship? Are you aware that the Kerbals on EVA have a jetpack and can use that to get back to the ship? Do you have experience controlling an Kerbal on EVA with their jetpack?

Hmmm... looks fine. Are you coming in at an angle? If you select "control from here" on the docking port on the controlled vessel and "set as target" on the port of the other vessel, then the target marker on the navball with be in the center when the target port is straight ahead of the local port. If you do that on both vessels (switch between them with "[" or "]") then you can see if they are aligned correctly. There is also an IMHO useful guide here: (This guide uses a mod to check display the alignment on the target vessel, I flip between the vessels to do the same thing.) P.S. One thing about the vessel(s): you don't need to attach the RCS thrusters to the monopro tanks, you can attach them anywhere on the vessel. And if you space them out more evenly around the center of mass of the vessel then your vessel will not rotate (as much) when you want to translate or translate when you want to rotate.

Hi @The7O2Guy, welcome to the Forums. As @5thHorseman said, many things could be wrong. One thing I did often wrong in the beginning was that I was trying to dock two docking ports of different sizes to each other, i.e. I was trying to dock a "normal" clamp-o-tron and a junior-sized clamp-o-tron. When I did this then the magnetic forces pushed the two docking ports apart instead of pulling them together. (A bit like real life magnets: get the north pole of one close to the south pole of another and they will pull each other together. Get the north pole of one to the north pole of another and they'll push each other apart.) Switching off RCS and SAS just before docking is IMHO a good idea (aka: I also do that), but that doesn't usually cause or prevent being "kicked away" from the docking port. Having SAS on can keep your craft from being properly aligned by the magnetic forces and thus keep you from actually docking, but then you typically still "stick" to the port without actually being docked. Docking at too fast a speed will result in the two craft bouncing off from each other, but 0.1 m/s is definitely not too fast.

Well, that was the message that the tone of what you wrote conveyed to me. I believe that reporting bugs and reminding the developers of unfixed bugs after a new release in unconfrontational tones is more effective than <snip> about things. Probably not effective enough to get everything fixed though, but considering the number of longstanding bugs that also affect the Windows platform I don't believe that this will change. So my summary is: "because the middleware support for Linux is buggy". Kind of what I was afraid of. Thanks!

About the KSP on Linux issue: KSP works fine on my Linux computer. Granted, I don't have a joystick so the missing support for one doesn't affect me. But the graphical issues - that I know of - don't make the game unplayable. And some Linux specific bugs do get fixed, although with the alacrity that SQUAD applies to all bugfixes. So claiming that Linux isn't supported at all is unfair. I also think that just complaining about how bad it all is and that nothing works is not going to motivate SQUAD to do a better job at supporting Linux.

Coming back to that: I just did a test with using the BG robotics parts to cover the senior-sized docking ports. My test vehicle looks like that (with the ports closed): As you can see it has groups of five rings of docking ports, each ring has four pairs of docking ports where one is the actual port and the other is the movable "cover" of the port. The craft in the image has three such groups, so 3*5*4*2 = 120 open ports when all of the pairs are in the "open" position. And this is the lowest number of groups where I start to see yellow times, although sometimes they flicker green and there is no significant lag. With four groups (i.e. 4*5*4*2 = 160 ports in total) I see measurable lag when they are open (10 s game time in 15 s real time). If I move all of the "covers" to the closed position the lag (and the yellow times) go away. So for my machine about 100 open docking ports seems to be the boundary for "absurd" (Btw.: Ryzen 5 1500X, 16 GB RAM, Ubuntu 18.04) P.S. Due to bug #24435 action groups to open all these doors don't work. (But I guess you - @XLjedi - know that.)

Well, my guess is that with 19 open ports (and a few hundred parts in total) you can measure a difference between having the ports open or not. If you actually notice the difference in normal gameplay is another question. Although now that I re-read your message, 19 senior-sized ports plus a comparable number of normal and junior-sized ports is at least at the edge of what I consider "reasonable". The biggest station that I built has 8 normal docking ports, 4 junior-sized ports, and 5 senior-sized ports open and 13 more senior-sized ports that are attached to something. (And it is already pretty laggy, but it is also the biggest - in size, weight, and part count - object I built.) As you can see from my test, 288 open docking ports is clearly on the absurd side of the scale.

That's also the impression that I have from my tests. Yes, there is an effect. But if you only have a reasonable number of docking ports then this effect isn't so serious. And from a programmers point of view: I can well imagine that in an older version of the game each docking port tested every part within physics range, but that at some point a dedicated list of docking ports was introduced so that now only that list needs to be searched.

O.K. I just did a quick test with a dummy craft with 288 shielded docking ports (out of 295 parts in total). There is indeed serious lag when all those shields are open, compared to when they are closed. Another test: similar craft but with 288 normal clamp-o-trons covered with a nose cone each (583 parts in total) -> the time display flickers green and yellow, and 10 in-game seconds took 10.32 seconds real time (timed manually on a stopwatch(-app on my phone)) Same craft but without the nose cones (so 295 parts in total) -> the time display is a steady yellow, and 10 in-game seconds took 28.92 seconds real time (Well, a bit less. I got bored. ) So, yes. There definitely is an effect! Edit: Another test with a craft with 8 docking ports (uncovered or covered with a nose cone) and enough fuel tanks to bring the total number of parts up to 885 resp. 877 parts showed no significant difference in the lag between the two craft...

Highly refined kerosene, a kind or rocket fuel: RP-1 on Wikipedia. Among other uses it was used in the first stage of the Saturn V and is used on the Falcon 9. Why SQUAD should buy that is beyond me. Maybe the OP wants them to build actual rockets?