OHara

At the risk of confusing things, maybe you noticed the option "Invert Direction" on the rotors. This does let you make rotors in a symmetric pair rotate in opposite directions, leaving the rotors linked by symmetry. The rotor labelled 'clockwise' and 'inverted' actually rotates anti-clockwise. However, there is no similar 'invert' option on the propeller blades, so I see no practical use for inverting one rotor when using them with propellers. The simplest way I have found is to build one fan assembly (with the propeller blades in 4-way or 8-way symmetry around the rotor) and then alt-click to copy the assembly and paste in the other locations -- as Vanamonde said above. Edit: There is another approach that you might like. Let both forward rotors rotate clockwise, and both rear rotors rotate anticlockwise. Then you do not fight with KSP's method of placing parts in symmetry, and the four rotors have zero net torque. If you load the front rotors to pitch up quickly, torques will be imbalanced and you might yaw left, but those torques are small with KSP's propellers so you might not notice the yaw.

There are not any control surfaces acting as elevators. The ones on the top can only turn on their horizontal hinges, so they don't deflect the water flow to make any steering. You need elevators placed like the fins on a whale's tail, or the like the front fins of a fish. The 'remote guidance unit' on the back is rear-facing, so rudder-steering will be backwards. The rudders might be fighting the reaction wheels, causing no steering overall. You can turn the 'remote guidance unit' forwards, or use its 'ControlPoint: Reversed' option to make the rudders steer properly. The propeller blades from the Breaking Ground mod do not work under water, unfortunately. They do not push against water, only air. The stock aerodynamic surfaces do work, although a propeller built using the smallest elevons will be larger than what you have.

Maybe, if you can say your in-game settings on the frame-rate, and any limit set in your graphics driver, that might help people know whether this mode will help them (maybe). There's a similar report on the bug-tracker (link) of faster/slower loading depending on the frame-rate limit ---but that report concerned the in-game setting--- with some people seeing an effect, other seeing none.

Aerodynamics has not changed for a few years. I agree that @BenKerman could make a better spaceplane than the Nifty Plane in that book, but even the Nifty Plane can get to Mach 5 easily. If there is something inside that cargo bay, it is easy to accidentally connect the rear portion of the plane to those contents, rather than to the back wall of the cargo bay. One unfortunate aspect of KSP is that it figures drag based on what is connected to what, ignoring how parts are offset relative to one another, so connecting to the cargo will make KSP think the front plate of the Mk2 fuel tank is facing the wind. That could preventing breaking the sound barrier. You can check that things are connected as they appear to be, by selecting the offset tool, marked 'Tool: move', offsetting all contents of the cargo bay including docking ports, and checking that the remainder of the plane stays put.

I would have thought that craft would be stable on reentry. The heavy fuel is near the heat shield, and those big wings would tend to swing downwind as you want. The nav-ball is pointing retrograde (probably because the command pod will be pointed forward for the return journey) . SAS doesn't know that you are flying backwards, so won't know to tilt the elevons appropriately. So SAS would be commanding those big elevons in the wrong direction, and that might be enough to flip in Eve's atmosphere. If those elevons are always used when flying backwards (relative to the command pod) you can reverse their actuation by setting a negative 'Authority Limiter' in their right-click menus. Or, you can set 'Control Point: reversed' on the command pod on the way down, if you remember to restore that setting before going back up.

Yes it is normal, and Yes you can fix it. The standard advice for beginners is to put the CoL behind the CoM, because that is an easy way to check that the wing just a bit behind the centre of mass. That advice does result in a plane that is nose-heavy, as you noticed. Gravity is pulling down at a point forward of the wing's lift. So in flight, beginners have to command pitch-up all the time or use SAS. If you like, you can rotate the front elevons during assembly, so the plane is trimmed as you like. Trimming to neutral pitch moves the CoL indicator forward to match the CoM. If you select the root part to pick up the whole plane, you can shift-S and shift-W to pitch it slightly and see that the lift of the wing rotates the plane back to level. The aerodynamic center is still behind the center of mass so plane is still stable.

. . . and the disk of the rotor blade gives passive yaw stability as well. This works with the chair as well, flying very carefully using slow changes in trim, and letting it fly at whatever odd angle works best. I wonder if I can make it to the island and back on the charge in that battery. (Helicopters with fore and aft rotors have enough degrees of freedom to control the craft, if we vary the rotor rpm, but there are awkward interactions between controls and I found them very tricky and unpleasant to fly.) It looks no current entrant has been overtaken within the past 24 hours, so we are hoping for new entrants to the challenge.

KSP is, to me, mostly a sandbox game that rewards good planning. There are no random failures in the stock game. The only unpredictable mechanics in KSP1 are ISRU cooling and Kerbnet searching for anomalies, and I dislike both enough to avoid them completely. So I think we don't want weather surprises that frustrate the player's plans. But that leaves room for weather that follows a pattern, as most weather really does. Clouds give a nice height-reference in KSP with the EVE mod, and dust-storms on Duna are an interesting challenge for landing there. They can be seen from orbit and move predictably, with EVE, so we can plan for them or avoid them. Steady wind following a regular daily cycle, plus maybe a seasonal cycle, would be interesting for aircraft and for aiming lightweight probes, and players would build sailboats, or spaceplanes that need to take off into a strong wind. Something like the current ScanSat mod could map winds from orbit if they existed. Seasons barely exist in KSP1; we might try to arrive at Moho in the northern Summer to find the hole at its north pole. If high winds or difficult cloud layers on some KSP2 planet are seasonal, we can choose to accept or avoid the challenge.

I started with my helicopter on KerbalX (link) and removed all unnecessary parts. The result is TinyCopter (link) : cost ¤705 8 parts plus 1 Kerbal 183kg including the Kerbal 42 minutes round-trip time https://imgur.com/a/0qNhTXp I used two rotors for a counter-rotating prop, but just one blade on each. KSP puts the CoM of the helicopter blades very close to the root, so the off-balance rotors do not shake the pilot too badly. The new-with-version-1.9.1 built-in cyclic controls handle pitch and roll. A fin acts as a tail plane for passive yaw stability.

Having many craft and bases in your savefile only makes saving the game take a bit longer. KSP only simulates physics for craft within about 2km of the craft you are piloting. I have 'persistent.sfs' files around 5MB that cause me no problem. I think size of the save-file is a reasonable measure of the number and complexity of the craft in flight. If you keep the game running for a long time (hours) in one sitting, though, @Anth12 has noticed that KSP gradually uses more and more memory, and that problem is worse with a larger save-file (link to bug report). At some point the operating system will slow everything down while trying to keep so much memory available to KSP.

Maybe the antenna in the satellite is not a 'relay' antenna. I don't know the rules for communications links, but there is a post here (link) that explains them and the types of antennas. You can disable the communications rules temporarily with Pause (Esc on PC) => Settings => Enable CommNet :off

This could be a bug that appeared with EVA construction (bug-tracker link) where a decoupled sub-craft doesn't get its physics simulated, if the root of the decoupled sub-craft is a cubic strut or hexagonal strut. (Those two structural parts, like thermometers and small surface-mount parts, are excluded from the physics simulation,)h So far the only suggestion in the bug-tracker about avoiding the bug is to re-arrange parts around the decoupler so some other part ends up the root of the sub-craft.

I see. If you want to use a marker craft, you could place it on the Moon's orbit, 60° ahead of the Moon. There is a configuration file somewhere to define the orbit of Moon for Kopernicus, so you can copy those orbital elements into the 'set orbit' mechanism in the debug menu (a.k.a. cheat menu) except add π/3 = 60° to the MNA, and set your marker craft into the desired Lagrange point. Then you have a direct target for your real craft.

De-orbit and landing in one burn (a.k.a. the 'suicide burn') is the most efficient, for the reason that you describe. Well, the small initial burn, that turns your orbit into a trajectory that contacts the surface about where you want to land, might be called the 'de-orbit' burn, but then the large burn to bring you to a stop just before reaching the ground is called a suicide burn.

I am fairly sure there is no way to show the time to a target's AN/DN directly. (Sometimes I cheat a 'marker' craft into an orbit so that I get the markers that I want.) Myself, from what you described, I do not understand why you want to time any burns relative to the Moon's AN/DN relative to the Earth. Is that a separate goal to reaching L4/L5 ? To reach the Earth-Moon L4 point, I think you can launch from 51°N into an inclined low Earth orbit, place a burn at your AN/DN relative to the Moon to raise apoapsis to touch the Moon's orbit, make that burn on whichever orbit has you reach the apoapsis 60° (5 days ) before the Moon does, and then zero your velocity in the rotating Earth/Moon frame when you reach apoapsis. The zero-ing burn would be at the craft's AN or DN through Principia's Earth/Moon-barycentric reference plane, but I don't see any link to the Moon's AN/DN relative to either Earth's rotation or the ecliptic.

You can find at the bottom of the log that System Heat caused an exception, [EXC 18:05:58.452] NullReferenceException: Object reference not set to an instance of an object SystemHeat.UI.SystemHeatOverlay.LateUpdate () (at <ec1041d6b73c464086f8d8133cb1f2d3>:0) But at the top of the log there several (about 2600) error messages from other mods concerning files missing in "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData" so maybe the update from Steam caused some files from mods to be missing. I have heard that people who use Steam make a copy of their 'Kerbal Space Program' directory and apply mods to that copy. I don't know the reason, but with 160 mods you might need to find out the reason and maybe do it that way yourself.

Well, the original question was about cooling, but I see your point. It is not necessary to fully cool the converter in order to use it. And the "Thermal Efficiency" in the right-click menu actually indicates the percentage of full conversion rate. When the converter gets hot, and the "Thermal Efficiency" goes down to 50%, the rate of electrical use is also 50%. Once I discovered that I could turn off some the the radiators to slow the process and avoid the converter shutting off due to lack of electricity. For me, though, playing a game where I don't know the rules was more frustrating than fun.

So in that case, it is the bug with lots of solar panels around a light part (link link). I don't know what it is about solar panels that causes this problem so I don't know any direct way to avoid it. KSP tries to make these cubes-struts physics-less but then encourages us to attach physics-full objects onto them, so in effect we have 10 solar panels all connected to the single hinge. This problem does not appear on this craft if we turn off that 'physicsless' option, and let Unity simulate normal physics on the cube-struts @PART[strutCube] {%PhysicsSignificance = 0 } Another way to avoid the self-destructive wobbling, would be to put a line-strut from the outermost solar panels to the hinge, but this is awkward with the other panels in the way, so this leads us again to use those evil autostruts. The usual incantation "Autostrut: Grandparent Part" on the outmost two pairs of panels.

I have seen no indication that Squad has any paid person checking for support requests on this forum, after @sal_vager left the job a few years ago. Within the forums, this would be the best place because the technical problems are not hidden by posts other topics --- or would have been the best place while @sal_vager was reading. If I understand your description, GOG currently provides : KSP main game, version 1.11.2 only KSP main-game language-packs, version 1.11.2 KSP DLCs in English for KSP version 1.11.1 (which also work with KSP 1.11.2) KSP DLCs in other languages for KSP version 1.11.0 only I think @ManeTI at Squad might understand what went wrong and eventually solve the problem. Squad has a bug-tracker where you (or anyone else on the forum sees what is on GOG) could report this problem, to let them know to fix it for future customers. I applied the French language-pack to KSP 1.11.2, and then applied the Breaking Ground DLC for the English language version of KSP 1.11.1. The game works, but the Breaking Ground parts are described in English. That looks like a way for @Xavier T to get the game and DLCs running, at least. Maybe @ManeTI can suggest a method to get you the missing file with translations to your language, in a way that respects copyright.

There is a bug in version 1.11 where pilots and probes have all their SAS abilities from the beginning (link link)

You would run the risk of double-counting, though. In any case we should make sure @swjr-swis has access to the proposed repaired drag cubes two posts above, since he did ask for them. You know I have some sympathy that the drag system from KSP 1.0.5 probably seemed like a very good idea at the time. Run an automatic mini FAR-like analysis over each part the first time KSP sees that part, cache the result in PartDatabase.cfg, and combine parts using simple rules. Sound very mod-friendly. I will fault them for the poor documentation, though, because unintended consequences, like ladders acting as if their containers were exposed, are hidden in mysterious tables of numbers. Many parts have worse problems. The new decals (a.k.a. flags) somehow trick the analysis into thinking they have only one side, so they get body-lift from one side only, allowing creative exploits. The part creator knew to turn off drag and leave out any lift module, but the automatic analysis gives them drag-free lift anyway. Zeroing the areas in the 'drag-cube' would be a trivial fix, if those numbers were less mysterious. We have seen our suggested custom drag cubes be adopted into stock in the past, so I'll post theses fixes, once I find or make the reports on the bug-tracker.

I just looked through all the stock craft. I had forgotten how many there are. New players might expect them to be examples of good ideas for KSP, but mostly they are not. The "Kerbal X" Mun-capable rocket is pretty good, though. We could certainly have a forum challenge to make sample craft for demonstrating KSP techniques for new players, one each in categories we choose. Then there is nothing stopping us from putting them in a KerbalX hangar with license statements that make it easy for Squad to republish them with just an attribution. Categories might be (ignoring the DLC parts): +Simple satellite launcher +Three-stage rocket and lander (capable of Minmus Gilly and Mun) +Large lander with a cargo bay holding a rover, all mounted to an appropriate lifter +Launcher for multiple satellites (showing a way to pack them in a fairing) +Atmospheric fixed-wing aircraft +Spaceplane for getting to Kerbin orbit and back The 'Stearwing D45 C' as refurbished by @swjr-swis is a good example for that spaceplane. Giving the wings 5° incidence is a good thing to show new players. If this was put on a challenge thread, I'd suggest making it aerodynamically stable, because it is currently very hard to fly without SAS. I would (and did) move the wings back to move the aerodynamic centre, then flatten the incidence on the detachable wing to bring the CoL back close to the CoM. I would also suggest moving the front gear back so the nose is raised 3° on the runway, so that the plane takes itself off. Everyone has different opinions on how to make craft, though, and not all of us will be happy that the demonstration craft are not build in our favourite way. (I would need to hold my tongue, for example, regarding the use of evil autostruts on the Stearwing.)

It takes some effort, but not any extreme effort, to install Luna Multiplayer and launch two copies of KSP to see how LMP handles the questions raised. (I need to run each KSP instance in its own small window, but that is not too bad.) 1. Time Warp: Anyone can time-warp at will. If any player is ahead of you in Kerbin time, LMP gives a button to time-warp to catch up. This facilitates an agreed mutual time-warp, but does not enforce it. Each player can see if the others are ahead or behind him, and by how much time. While players are at different Kerbin-times, craft in the past can push craft in the future out of the way (and maybe cause damage-- I'll have to check). Each player sees others' craft, even if the others are in the Kerbin past, at their latest position, or their latest orbital trajectory extrapolated forward by KSP's usual orbital mechanics. Pausing the game is prevented by LMP (but it seems to me that their re-synchronization concept could be made to work with pausing at will). 2. Reverting: Reverting a flight recovers the craft (wherever it is) and recreates it as it was in either VAB or launchpad. The server keeps an unpacked version of the contents of an *.sfs file called the shared 'Universe'. Each player's game saves a persistent.sfs file as usual, that contains all the craft and Kerbals in the Universe. Each player can quicksave, but not quickload. To recover from disaster, everyone disconnects, any player who has a desired quicksave converts it using LMP to a Universe and puts that on the computer running the server, then someone restarts the server and everyone reconnects. 3. Communication: Simple text chat Craft-files in the VAB/SPH can be shared through the server Any player can switch to any craft or Kerbal, but if another player is already controlling that craft, the new player is 'spectator' with controls disabled. (There are still bugs in LMP beta. When two players dock their craft, currently sometimes LMP Server disconnects one player, rather than make him a spectator.) 4. Mods: Craft using mod parts are invisible to any players lacking that mod. The server stores a list of all parts allowed/required/forbidden (initially, all stock parts allowed) and tells players at login if there are conflicts. 5. Long-Term Motivation (for players to continue the multiplayer aspect of the game): Keeping a public server populated with players is not something the small LMP community tries to do. The usual method is to arrange with friends to play together, and one of them runs the server. At the moment there are 5 LMP servers with players on them; all but one are passworded.

No answer from me, but I'll point out that KSP Steam Controller was trying to initialize an overlay renderer when the Intel Graphics Driver made an access violation in hopes of getting attention of someone who uses the Steam Controller and who might recognize the problem.

You do not need to enable 'Advanced Tweakables' in order to transfer fuel between tanks, at least not in my copy of KSP. Just in case anyone new has a similar problem and finds this thread. See the posts above, by Reactordome and Snark for example, on many reasons you might not get the 'in' and 'out' fuel-pumping buttons.