OHara

It probably also helps a lot, to have such a clear bug-report, with a clear measure of what needs to be fixed. My thinking is that a programmer is more willing to dive into unfamiliar and maybe messy code if she has a clear goal. I assume the axes on your plots are kB used by KSP.exe versus number of Load / Save / Scene-change events

The player who entered the bug report figured out it depended which part was 'root' in the craft under SAS control. The navball is correct but for some reason SAS holds orientation not so that the docking port points to the target, as you would expect, but so that a line from the root part to the target is parallel to the docking-port axis. So in some cases you might work around the bug in the VAB, by choosing the root part to be along the axis of the docking port. Or, try the other approach to docking: Orient the ship so the docking port is parallel to the target port, ask SAS to hold orientation, and translate to dock.

The *.cfg for each jet engine refers to a model for the internal parts, // model = Squad/Parts/Engine/jetEngines/turbineInside but it is commented out in each case. You can remove the '//' comment indicators, on all lines in the MODEL blocks, if you want a visual model more consistent with the centers of mass.

Hold left-shift while you drag a part, in order to drag it further. For some reason KSP hides that trick well. Somehow, after a quicksave/quickload (or going to another ship and back) with your Turret Test, when I next release the claw, the one cube tucked inside the small battery, that was meant to be part of the rotating section, is left behind with the static section. So the physics engine acts as if a collision had violently pushed that cube inside the battery, and tries to elastically spring back. The only way I saw what was happening was by noticing which parts of the debris were connected to each other. (Mythos's stand-alone utility flags an error on the persistent file when your craft is loaded, about that cube not being connected properly to its parent, but not on the craft file itself.) I have never seen a problem like that before. I hope that if you partially disassemble and reassemble the craft, whatever problem sneaked in there will not come back. I suspect you were extremely unlucky to find a glitch in the craft data structures.

I agree, you do seem to be doing everything right, and what you see is what I would expect as well. Moderate flaps (usually about 10°) let aircraft take-off at a slightly lower speed, by giving the wing a bit more lift, if you pull the stick back (elevator pitching down) as much as you need to lift the nose-wheel. You can see at https://www.faasafety.gov/files/gslac/courses/content/35/376/Use of Flaps.pdf that the usual case "the nose-down pitching moment" from flaps is taken for granted. The pilot almost automatically pulls back as needed on the stick to keep the aircraft in the attitude that he wants. The unusual case is that flaps on some high-wing aircraft have enough down-wash that they can push the tail down, nose up. Stock KSP does not simulate interactions between wing and tail; FAR tries to, but I am not sure it considers interaction that far away. It might be interesting to see if we can build a high-wing aircraft that will pitch up with flaps under FAR.

Very likely we have to continue using using the further away Alt. When this has come up before, no-one found a work-around. https://forum.kerbalspaceprogram.com/index.php?/topic/50205-prevent-quotaltquot-from-decelerating-craft/ https://answers.unity.com/questions/669208/why-right-alt-alt-gr-acts-like-left-ctrl.html https://superuser.com/questions/592970/can-i-make-ctrlalt-not-act-like-altgr-on-windows

I think the only solution (for what people call 'kraken-tech' bearings) is to make the re-joining so easy that you can do it anytime you switch craft. I built a similar bearing for https://kerbalx.com/OHara/Tough-Twin-Electro-Prop, with the spherical collider of the grabbing unit serving as part of the bearing. There is a mod 'Collide-o-scope' (link) that outlines the shapes used as colliders by the physics engine, which helps line things up correctly. On one end of the moving part, a cage of thermometers surrounds the grabbing unit; on the other end an antenna sits inside a cage of RCS ports. Normal docking ports need to back away a few meters before the re-activate their magnets and auto-engage features. Quitessa used shielded docking ports for their re-dockable bearing at https://kerbalx.com/quitessa/Fully-Redockable-Bearing (which uses parts from the Making History mod).

Welcome back. (I couldn't properly load the craft because of a part from a mod that I don't have, but I think I get the idea.) Generally, stock bearings cannot survive load/save or time-warp, as you say, because the two parts are separated craft and KSP puts them on their individual non-interacting orbits, which drift apart during time-warp. When time warp is over, the individual craft find them selves in the same location, and act as if they had been forcefully placed there and spring apart violently. Your redockable rotation bearing is a good way to success; just re-dock it before any time-warp. See the craft here and the thread here for similar solutions. Offset the stack-separator in the VAB, and offset back the parts attached to, it so that the separator alone is outside the craft. Then you don't need the time-warp trick when you decoupler. There are of course mods like 'Infernal Robotics' that provide bearings and Squad themselves now sell a robotics mod called 'Breaking Ground' if you want to build this more simply.

I enjoy flying both XL Jedi's and fourfa's craft over on KerbalX. They get very different things out of the same game. XLJedi is user-friendly controls. fourfa uses the fundamental controls more directly. Two of several ways to "properly build" a "helicopter".

The model should still be there in your Squad/Parts/zDeprecated/ folder, if you are on PC, and since it is still packaged with KSP 1.8.1 and 1.9.1 I would expect it somewhere in the console version as well. I have to go to Manufacturers: "Kerlington Model Rockets and Paper Products Inc" to find it

Some people have avoided this problem by removing a mod, but a different mod for different people https://forum.kerbalspaceprogram.com/index.php?/topic/187188-my-kerbals-are-showing-up-though-parts/ https://forum.kerbalspaceprogram.com/index.php?/topic/191510-kerbal-visible-throughout-parts/ https://bugs.kerbalspaceprogram.com/issues/24734 (Maybe by now the authors of the mods have figured out how to resolve the problem; you can check in the "Add-on Releases" forum for the relevant mod.)

I just noticed this problem from some other cause, my first time plyaing KSP version 1.9.1. The throttle failed to respond on the runway. Clearing 'input locks' solved the problem: Mod-F12 >> Input locks >> Clear Input locks

My only guess is that you have no pilot, or robotic probe core, that can control the craft. In version 1.2 (probably during your years of enjoyment) KSP added a communications system. If you are using that feature, then for some probe cores, and non-pilot kerbals, if there is no signal back to the KSC, you can only full throttle or shut off, not slide the throttle. You can probably get other guesses from other people, if you need them, by posting again with more details.

I attached my build of that ship so you can compare drag. 5--10kN at the speed in our original screenshot, but that triples if you pitch outside the prograde circle. The 'nodes' are those green spheres you see when assembling, and yes the usual way of snapping parts together connects the nodes. It is possible to 'surface attach' tanks on the side of the fuselage (like you do with the two round tanks) and then move them in-line to the fuselage so that it looks connected, but KSP's simplified calculation of drag treats that moved tanks as if it were stuck to the side in the airflow. It sounds crazy but it is possible to do accidentally. Another similar thing is to connect to the part inside the cargo bay, rather than the cargo bay. But as @fourfa pointed out, your original suspicion is correct. That video was from very early in version 1.0.x, and I can see where he reveals the thrust that it is 1.5× what I can get today in the same conditions. In version 1.0.3 the Wheesley was significantly 'nerfed' (bottom of this linked page) --- maybe because they saw that video and realized they had made spaceplanes too easy for KSP to be a fun game. That design is very very difficult to get into orbit, but you might enjoy improving it, but first you might rather try a recent spaceplane design from KerbalX since version 1.2.

Engines nerfed (made weaker) relative to when ? and which engines? Version 1.8.0 had a bug in atmospheric drag, making space-planes much much easier, until version 1.8.1 fixed it. Some engines from the Making History mod had unusually high Isp and thrust, until version 1.6.1 brought them closer to the rest of KSP (thread link) I just tried an early-career space-plane that barely makes it to Minmus, in each of 1.3.1 and 1.91, and both versions left me with the same fuel in orbit. Space-planes from kerbalx should work in the latest version of KSP, but technique is important because space-planes in general are challenging to get to orbit without running out of fuel.

There is a group of bugs about the service modules. What you describe seems closest to this one (link). The way the service module marks as stowed parts outside of it is a separate bug (that I remember seeing but cannot find right now). The Making History mod is noticeably buggier than the rest of KSP, so be warned, but you might like it anyway. You already noticed that you can work around the problem, by leaving the shroud on in the VAB and deploying it in flight. If you want to change the rules in your copy of the game game, so that parachutes don't check if they are stowed,you can edit the configuration files, or use a ModuleManager patch like@PART[*]:HAS[@MODULE[ModuleParachute]] { @MODULE[ModuleParachute] { %shieldedCanDeploy = true}}

You might like putting your wheels put the docking port just below your standard height, then adding landing gear that, when they deploy, raise the port just above standard height. The idea is you roll up to position, touching the target docking port a bit low, and extend the gear to rise and connect. Also, you can right-click on the wheels-or-landing-legs and adjust their 'spring strength' slider to adjust the height. Probably you need to enable 'advanced tweakables' in the escape-key settings menu in order to see that slider; depends on KSP version.

There is some documentation from Squad here https://www.kerbalspaceprogram.com/api/class_module_data_transmitter.html and what players figured out here https://wiki.kerbalspaceprogram.com/wiki/CFG_File_Documentation But mostly, modders and players interested in the internals figure things out through experimentation. People talk some about this experimentation in the sub-forum "General Mod Development Help and Support" xmitIncomplete is probably an abbreviation for "transmission is incomplete" and I have never seen EVENTS or UPGRADESAPPLIED used. UPGRADESAPPLIED probably is there to store "part upgrades" which is a mechanism modes can use so that progress in the TechTree, which usually unlocks new parts, can also improve the specifications of existing parts.

You have found a new bug. In older versions of KSP the "Authority limiter" ran from 0% to 100% and the full 100% was 70°. There are now two sliders, "authority limiter" and "deploy limit", but it only makes sense to have the second for airbrakes, and only the first seems to have effect on deployed airbrakes. Recently (around 1.7.2, I think) the sliders on aerodynamic control surfaces changed from % to degrees, and the separate control for "deploy limit" was added. It looks like Squad made a mistake on the airbrakes at that point. We could report it on the bug tracker. It is very likely that someone in the forum will see how to repair the problem by changing the configuration file. Then we can patch the problem ourselves (on PC versions of the game) and also put the fix we want on the bug tacker.

Guess 1) Sometimes the mouse-clicks are misaligned to the buttons, but I have only seen this on the main menu. That is, you have to click some number of pixels away in some direction (found by experiment) to click the button. When it used to happen in the main menu, we would need to offset the mouse pointer vertically by the top menu bar. Switching to native resolution tended to help. Guess 2) The game has the concept of 'input-locks' to keep track of which inputs have effect at any given moment, and sometimes these get confused. The cheat menu has (Alt-F12 on PC, right-Shift-F12 on Linux, I think 'Komani' code on consoles) has an entry "Debug: clear input locks" that might clear the problem.

It sounds like you might mean that you edited the text in the *.craft file to remove the troublesome part; if so, yes, it is very tricky to clean up all references to that removed part. I think the most reasonable solution is the rebuild the craft, or the troublesome part of the craft, in the VAB editor.

If that is the only parameter that doesn't match, and if the target inclination is not zero, then the portion of the orbit that is above the equator, is the wrong portion of the orbit, and you should be able to see the difference in map view. That is, the orbit might be inclined the desired amount, but below the equator where the goal was to have it above the equator. The place where your current orbit and the target orbit cross is the place where you can align the orbits with one normal or antinormal burn. If the target inclination is zero or very close to zero, then the orbit can visually match the target with the 'Longitude of the Ascending Node' being different because that longitude is not very precisely defined (and shouldn't be a criteria for contracts). That very easy classic mistake, to make your orbit exactly backwards, would show up as the inclination being 180° different to the target.

There was a similar bug report recently (link) which links to video example (https://www.youtube.com/watch?v=6bcHLJe198k) but no-one has suggested a solution yet.

When you are controlling the rover, the CapsLock key (on PC) turns the pitch/yaw/roll indicators blue. When the indicators are blue, pressing W A S D (and I J K L if enabled) briefly moves the pitch/yaw/roll indicators from the center relatively slowly while the keys are pressed. By tapping the keys, you can make small inputs. Some things about 'precision mode' can be confusing. The animations of some parts move just as fast whether precision-control mode is active, but the effect of W A S D is slowed. It works when I J K L control wheels, even though the pitch/yaw/roll indicators do not move. It does not work for some of the landing gear. It looks like that was understood, and part of the plan, because KSP wheels have configuration settings for how much to reduce the steering angle as a function of speed, but this feature was dropped (the relevant bug report). You probably have noticed that KSP shows signs of being started by people with some very good ideas, but not enough technical capacity to make all those ideas work in the complex and imperfect world of coding, who then released an inexpensive but unpolished game (and I'm very happy they did so). The KSPWheel mod linked above reworks the complex details of implementing wheels, including steering angle reduced at higher speed.

True. The best we can do is use the fine-control mode ('caps lock' or 'bloq mayús' on PC) so that the keys turn the steering more slowly. Then we can tap the L key (or D in the default setup) to turn weakly to the right.