diomedea

This issue is a known one, was fixed with KSP 1.3, but while using KSP 1.2.2 the nodes are locked (just as if the tracking station was at the base level 1), unless a previous tutorial was run in the same game session that unlocked them (e.g., run the "Orbital 101" tutorial first; leave it, and you'll have the orbital interactions in that "To the Mun part 1" tutorial).

@Marshal Nedelin: your output_log.txt shows you have unpacked the KSP zipfile within C:\Users. Don't, it is a widely known cause for issues, as the operating system (OS) protects content in that folder from any unauthorized application. Avoid any other folder with a special meaning for the OS, best to create one of your own (e.g., C:/Games/KSP). Now, the above can easily be the cause of the crash, when KSP tries to write info on any file within a protected folder. But the output_log also shows "Error while initializing dbghelp.dll", so in case it still happens after having correctly installed KSP, do check that dbghelp.dll is fine (it is a Windows stock library, within C:\Windows\System32), compare with e.g. what reported here. More info on that library here, but to be short, it is invoked to write on the log the stack trace after a crash is detected (your output_log shows a null stacktrace, the result of the dbghelp.dll not working correctly). Should you find on your system a file dbghelp.dll not matching filesize, date, version, I'd advise to scan it for possible malware (if any is found, scan everything on your system). After having corrected both the KSP install and the issue with that library, should the issue persist, provide a new output_log file.

Steam updates games in the Steamlibrary, not with separate copies (to be said, KSP is one of few games allowing to be copied and run outside of Steamlibrary). Provided you have the game updated in the Steamlibrary (/SteamApps/common/Kerbal Space Program), and after verifying its local cache is correct through Steam (oftentimes Steam garbles updates, verifying the cache would ensure the correctness), you can use its files to update the separate install by copypasting them. To avoid obsolete files no more valid with 1.3 hanging around, best first to delete all these subfolders and their content: - /KSP_Data; - /KSP_x64_Data; - /Launcher_Data; - /GameData/Squad; - /GameData/AsteroidDay (in case the official add-on was installed). Also, make a backup copy of settings.cfg, you certainly would like to keep what crafted for that install. Then paste everything from the Steam KSP install to your separate install; and restore the settings.cfg from the backup. Please note, this doesn't ensure add-ons will work unless updated to a version compatible with 1.3, and therefore not your saves depending from add-ons either. Therefore, I'd wait all of the add-ons with your install to be available in a version compatible with 1.3, and keep playing the old KSP version until then

Perhaps 4 years ago this was an issue. Certainly KSP improved greatly since then, all heat/thermal data and computations were introduced with version 1.0. Though some minor improvements could still be worked (e.g., temperature on bodies at a given latitude and altitude changes only with the Sun incidence angle, there is no stored heat with ground, ocean or atmosphere to modify the temperature; also the relative inclination of the body axis in relation to the orbital plane isn't a factor for seasonal changes) there isn't anything currently in stock KSP code to result in negative temperatures.

Indeed, also the error.log with the new crash report shows the same: 134217728 MB user address space [134216651 MB free]. Write to location 0c610750 caused an access violation. 128TB user address space, against 8TB which should be normal. Again, no exceptions, no errors logged with KSP output_log. Therefore neither KSP itself nor Unity are aware of any issues. Certainly there have to be system settings allowing the OS to behave that way; but couldn't yet find which. Some settings (e.g. 4GT Tuning) reduce user address space: could be worth a try even if going below the 8TB, so to verify the game becomes stable that way. Beware if not an expert with system settings, even more with the registry: changing things unappropriately may result in a unbootable OS.

Can't find anything in the KSP logs hinting at the cause of the crash, sorry. Error.log tells of an Access violation, but is pointing to a perfect valid memory location. However, the user address space reported (= 128 TB), though perfectly addressable with a x64 architecture, is way larger than what a Windows x64 system allocates (8 TB). From error.log: 134217728 MB user address space [134215289 MB free]. Write to location 0412e270 caused an access violation. While the above is not conclusive, it hints at the OS directing KSP.exe to use memory locations that aren't in the virtual space (which is perfectly manageable); the result could very well be crashes when the OS function allocating memory returns a invalid location. Can't say how your OS figured that much address space, nor how to reset it.

Duplicate of this. Closed.

Duplicate of this and this. Closed.

As KSP doesn't allow to directly manage backup files ingame, one has to move (better: copy) the one desired from the saves/<game>/backup folder outwards to the saves/<game> folder. Then, to make KSP load it when asked to start an existing game, its name has to be changed in "persistent.sfs", therefore overwriting the persistent.sfs with the error. About the reported error: the savegame seems be missing one of the very many objects KSP deals with, while loading them and not finding one as expected an error is shown. Can't tell what is missing unless that savegame (and best, also the output_log.txt/player.log) are uploaded to some file hosting service and then linked here for anybody to check.

Another thought. Some users have reported to have solved input device issues by installing a virtual device driver (e.g. vJoy). Can't say this would solve your issue too, but if you like to experiment possible fixes, give it a try. While the OS can see all of your G940 suite, and believe other applications do as well, the problem may really lie in how the suite is recognized in Unity: by having Unity recognize a virtual device instead (itself set to properly do with your devices) could be a way to have it usable, before a proper fix is done.

Yes, lots of good points. To start with the suicide burn been considered as the perfect solution to every case (which really isn't). My own solution shows that: it won't be feasible to land in deep spots with other features around. Even more, though it should allow a perfect landing at a spot already visited, the maneuver may interfere with already existing structures at the site. The efficiency I'm talking about is being able to perform the landing with the minimum possible DV. Mathematically, there is no doubt about that (one approach to demonstrate that is with the energy equations). The simulation itself isn't the most efficient method of computing, some RK integrators may be tested to find faster convergence; but the real breakthrough would come finding an analytical equation to the problem. Which seems to be where nobody could come with good enough suggestions, not even examining different sources. My own attempts at an analytical equation were met by overcomplicated results for even very simplified problems (e.g., this is the result for integrating pitch (φ) over time: φ(t)-φ(t0) = - ((2*M^2*g^2+2*T^2)*(t-t0) * arctan(M*g*(t-t0)/(T*(t-t0) - M*s)) + M^2*g*s*log((M^2*g^2+T^2)*(t-t0)^2 - 2*M*T*s*(t-t0)+M^2*s^2)+2*M*T*s*arctan(((M^2*g^2+T^2)*(t-t0) - T*M*s)/(M^2*g*s))) / (2*M^2*g^2 + 2*T^2); where g = gravity (simplified), T = thrust, M = vessel mass (simplified), s = initial H speed), therefore such approaches had to be discarded. But indeed, the simulation method is equally usable with any vessel, doesn't depend on an autopilot optimization given e.g. size or moment of inertia of the vessel or control authority. All that said, I'm not pretending anybody have to use my method. IRL, landings are conducted with adequate safety margins; and IRL nobody does a suicide burn, this concept is more known to us in the KSP community than elsewhere. To tell the whole of it, before coming to this method, I started testing with another that would put the vessel on a suborbital trajectory (optimized to "impact" ground at the landing site) and the suicide burn done to stop the vessel just there just in time: no margins for error at all, if an engine didn't start at the correct time or could not reach 100% thrust, the vessel was doomed (method was discarded not because unsafe, but less efficient than my current one). This method has at least this failsafe (which is one of those used in reality too), if something goes wrong, the suicide burn can be aborted before execution. Then, in the first part of the suicide burn when still with a high Hspeed, if a problem develops, all required is just to turn to pitch up and raise speed to orbital again. During the whole descent, corrections will be made to keep the vessel within the programmed descent path. In the end, the safety margin is with programming a end altitude not at 0 AGL, but some meters up. Last, though would make for a fake of a suicide burn, safety may drive to program a maxThrottle < 100% with the simulation, so to always have some spare (costing more DV than needed, but safety is paramount); this maxThrottle setting is in my plans to make anyway.

Yes, did notice about throttling. If I may, that is a good example of a working autopilot able to perform landings; but when throttling we aren't any more in the case of "Suicide burns" (as this thread implies). Sure, a maneuver can be planned to first stop on the vertical of the designed landing site (kill all Hspeed relative to the surface) and then perform a suicide burn for just the vertical part. Works, but isn't as efficient as I would like: the time it takes for the vessel to fall in any suborbital trajectory (a vertical descent being an extreme suborbital trajectory at Pe = 0 (from bodycenter) and SMA = distance(vessel, bodycenter)/2)) before starting the suicide burn, is all time when gravity builds up extra V speed (all going in extra kinetic energy to be than depleted); therefore best if that time is reduced to zero, by having the altitude at which the suicide burn is started being the Apoapsis with our final descent, vertical or not). Also, when a pure vertical landing (or, any straight trajectory landing) is the case, my preference still goes with computing the suicide burn altitude using Energy equations rather than speed.

@Pand5461, no, my model isn't meant to handle the case you showed. You're right, a suicide burn wouldn't stop the lander, not until TWR is > 1 at the very minimum. But the idea of doing a double burn to achieve landing (first burn to kill most of H speed, followed by a suicide burn to kill all speed remaining) works, could have to be implemented at least for increasing final pitch (so to not slam in ground features on the way), at the price of resulting less efficient. Willing, I could easily modify the simulation to achieve the "constant horizontal deceleration" or "to kill all horizontal speed before doing with vertical speed". Wouldn't say is much easier to do that way: all I need is to change how pitch is updated, instead of going by the tangent of the trajectory (which is, atan(Vspeed/Hspeed), it can be set fixed (until Hspeed gets lower than a set threshold) or proportional (e.g., = atan(k*Vspeed/Hspeed), where k is the proportional factor). The latter would actually be my choice, with a low value of k the trajectory would end very vertical but still ensure the correct burntime. As you may notice, the true gravity turn case (= atan(Vspeed/Hspeed)) is in reality the simplest to compute, but not by much.

@Pand5461. I know my model appears counterintuitive because we are so used to land vertically. In fact, KSP tutorials covering landing (e.g. To the Mun part2) all have excess altitude, and that's how we generally plan our own landings too. Any excess altitude means the vessel could stop completely mid-air, and then the gravity alone has to be countered, resulting in a vertical landing (as written, time to deplete H speed is shorter than time to deplete V speed in this case). Gravity turn suicide burns are different, horizontal speed is depleted together with vertical speed. Though curved, the trajectory never reaches a pitch = 90° (vertical); the larger the TWR, the less the pitch at landing. The only way to get a final vertical landing is to deplete H speed before landing on purpose, meaning the trajectory is no more a gravity turn. My model really goes to find the perfect altitude for the suicide burn, the one that will take the least time to come to a landing (therefore less gravity effects and less DV spent to fight gravity losses). Meaning, both H speed and V speed come to zero at the same time, and that time is when the vessel touches ground (or almost, if we add some altitude for safety margin or correcting attitude). Exactly what you wrote may be impossible to achieve, is the object of the simulation with the suicide burn: to find that perfect starting altitude at which, keeping the vessel in a gravity turn at all times while burning with full throttle, the moment its speed (relative to the surface) comes to zero has the vessel at exactly the ground altitude (plus safety margin). Which always finds a solution for TWR > 1 (and enough DV); but the solution could be unfeasible with atmospheric bodies (e.g., my model computes for landing at KSC, for a trajectory at an Apoapsis altitude = 70 Km, a starting altitude for the suicide burn (at Periapsis) = 4634.5 meters, resulting in a speed = 2486.68 m/s and a dynamic air pressure (at 0°C) = 1.886 Mega pascal !! meaning it would require a drag coefficient unrealistically close to zero to avoid all that pressure to slow the vessel and convert its kinetic energy in heat). Interesting situation when the starting TWR is < 1, thanks for sharing. Yes, provided TWR increases beyond 1 before the fall makes increasing gravity (therefore reducing TWR), a landing has to be possible. But it would require engines with very low Isp (therefore burning more fuel) to reduce vessel mass at a rate greater than the raise with gravity due to falling. This doesn't generally happen with any gravity turn, not even with the (relatively inefficient) RCS thrusters: indeed my model couldn't but show TWR going further down instead of increasing with time. That video shows the vessel being pitched to keep it from falling (though it couldn't stop it still reduced vertical speed consistently) therefore TWR ended being large enough. Of course my model only considers gravity turns, so can't pitch that way, but it wouldn't be consistent with its purpose (that still is to achieve the most efficient landing) if it burned DV that way.

@Pand5461: interestingly, I also went with a project to optimize launch profile before this one (optimal gravity turn ascent). Can agree timestep isn't critical doing an ascent profile, allowing to solve in less cycles still with an acceptable accuracy. I preferred the "simulation" approach for the powered descent (timestep should actually be set identical to frame interval in KSP) to make no compromise on accuracy: unlike with an ascent, integrating precisely the position of the vessel is very important to land exactly where planned. The final resulting horizontal distance moved during the simulation is fed backwards to modify the argument of periapsis (and thence the earlier maneuvers planned to meet the periapsis at the correct time). Have to say, duration of the simulation isn't a constraint for the purposes of my model. Unlike what LGG is coding (with your help), that requires to reevaluate the descent in real time to modify thrust, my model solves the landing with a true suicide burn: throttle is at a fixed level (currently 100%, could become a setting later) until speed is totally depleted. The accuracy of the simulation totally depends on the correct knowledge of the ground altitude ASL at the landing site (which KSP provides, or a previous landing in the same spot would allow a player to know); a vessel using the computed approach would then stop at the final altitude with the last simulation (bar navigation errors or floating point inaccuracies during execution). That all allows to completely compute the maneuver long before its execution and not having to do in real time. What I have planned for the execution part (and is shaping in code) is instead to check every 1 second the difference of actual positional and speed data of the vessel against data recorded with the last simulation. This is similar to an approach I found applied with a landing guidance program from NASA: using "gates" to check how the maneuver proceeds. Still have to consider how the autopilot will then apply corrections to bring the lander back within the planned descent path (but errors should be low enough to be correctable by RCS). Not having to do in real time, have no constraints about how long it takes to compute a simulation, and that's why the model goes to repeat it (each time correcting initial altitude by the error found in the previous) until final error is within bounds. Most often testing the model, found it takes no more then 3 passes with the simulation alone to achieve an error lower < 0.5 meters, but having the model recompute periapsis speed after each pass (due to periapsis altitude being changed) requires 4-5 passes. I know about the limitations with my approach, but thanks for examining them: 1) The starting altitude with the suicide burn (that is the periapsis with the approach orbit) is very low, in particular when TWR is high. In practice, is best to land on highlands and to check the approach orbit doesn't cross mountain ranges; also, if landing in a crater, always better to do at a location on the far side from the direction of approach. Indeed that's all physically correct, but a refined version of the add-on could have to perform a check about the feasibility of the plan against features standing in the way, in particular when the trajectory is lowest. Can see three different approaches to be used to modify the plan: a) raise apoapsis with the approach orbit (works better the more orbits to be travelled before the landing site comes aligned, keeping the same total time by increasing orbital period while reducing number of orbits); 2) lower TWR (e.g. by changing maxThrottle applied during the suicide burn), that results in a steeper final trajectory starting at a higher altitude; 3) instead of performing a continuous gravity turn, split the suicide burn in a early half meant to deplete most of horizontal speed but not vertical speed in the same proportion, ending in a pitch a lot higher; and a second half (now gravity turn) that starts with a velocity vector now pitched enough to be free of ground features. 2) The simulation actually takes care of allowing exactly the time required to come to a stop at the desired final altitude. Wouldn't be a suicide burn otherwise! Besides, when constraining vessel to a retrograde attitude at all times during the burn, it follows a gravity turn (reversed), which means the horizontal and vertical components of speed change by the ratio of horizontal and vertical accelerations which are kept (apart for gravity) in the same ratio as speeds because of that retrograde attitude. The result is, always, that both horizontal and vertical components of speed are depleted in the same time (apart computing inaccuracies) by using the retrograde attitude (and, as the trajectory tangent is the ratio of those speeds, its rate of change (derivative) is = (gravity+ thrust/mass*sin(pitch))/(thrust/mass*cos(pitch)). The case of horizontal sliding occurs when time to deplete vertical speed is lower then time to deplete H speed (as done when landing an aircraft on a runway); the reverse occurs for vertical landings, when all horizontal speed is depleted earlier than vertical.

Yes, I use integration. I tried other solutions, to derive an analytical equation. Under specific circumstances it was possible (any straight trajectory bringing to the landing site could be, in particular a vertical descent, as the math you showed proves) but couldn't find an equation valid in general with curved trajectories. Therefore am using an integration (or, simulating the powered descent under strict gravity turn) handling change in pitch, mass of the vessel, gravity, curvature of the body surface, surface speed at the given latitude, to integrate speed and position of the vessel. The "stop" occurs when the vessel is at its minimum speed, there the integration provides the final altitude (plus horizontal distance moved, DV expended, final pitch and mass of the vessel). The final altitude difference in relation to the ground altitude is then used to correct the initial (entry) altitude and the procedure is repeated until the final altitude matches the ground. Plus a selectable height (have still to create a routine to define such final height based on the vessel size) to allow a final attitude correction once the vessel is practically hovering the site: the suicide burn starting from a horizontal velocity vector, in particular with very high TWR, ends with a final pitch very far from vertical. I've examined a few programs used or proposed for landing guidance with real space agencies, all use the integration method both to predict the maneuver and to control its correct execution. Though CPU intensive, each suicide burn simulation should be doable within 2-3 frames from my estimates (which would be unacceptable if conducted within the same thread KSP runs, but I'm coding that to occur in a separate thread).

I have a very simple but very effective trick (learned practicing ascents with Gravity Turn Continued). Always keep an eye to the Time-to-Apoapsis (TtA) indicator (uncomfortably with the Apoapsis marker in map mode in stock KSP; much handier having KER or other similar add-ons windows open). Apply full throttle at launch and make the vessel pitch down (generally to 85° is enough, vessels with very high TWR may pitch down more) eastwards as soon as you leave the ramp. Engage the SAS to hold prograde mode (and never leave it until in orbit). Only apply lateral correction as needed to obtain the required launch inclination, but otherwise don't try to steer the vessel, ever. What you have to do is to modulate throttle so to keep TtA = 50 seconds during all ascent from KSC (aiming for LKO). At first you'll go full throttle and TtA will steadily climb; once at 50 start closing throttle and aim to keep that value. Of course keeping prograde at all times, the vessel will follow a gravity turn. Only when close to the orbital speed (> 2000 m/s) reduce throttle further so to progressively reduce TtA to 0 (should more thrust be applied at this point, Apoapsis altitude will increase and TtA shift farther away).

For what I know, the operating system may force a low but safe screen resolution when the one required by an application isn't supported (something alike a control panel should list all supported resolutions with your display). KSP stores the resolution in the settings.cfg (lines "SCREEN_RESOLUTION_WIDTH = " and "SCREEN_RESOLUTION_HEIGHT = "). Of course those can be changed via the settings (Graphics) in game, but better check what really is stored. It should also work directly editing those two lines with values supported by your display. Therefore, check what the values stored are; if they don't both match one of the supported resolutions, change them to one supported you like. Maybe do some experiments with lower resolution first, I've heard of some crazy high resolution being working in KSP but can't tell if the one you wish would. Also, did you change any other graphical settings before having this issue? Not having a Mac can't tell, but could be possible not all combinations of settings like V-sync or Frame Limit work at such resolution (Frame Limit in particular, its frequency by Width by Height by 4 defines the number of bytes your GFX must send to the display each second, with a Frame Limit = 120 that would amount to ~7.1 GB/s which is pretty high and may not be supported).

Many years ago had a X45, my current HOTAS is a X52Pro but doesn't change much (though I can't just pass my KSP profile for that, won't work). Anyway, I have a solid configuration very easy to use with all kinds of maneuvers, docking included: what I can do is share what would work. As you wrote, lots of buttons. Unity (and therefore KSP) can't recognize them all, only ones in the ID range 0..19. Unfortunately that makes for extra buttons to only be recognized if they are (via a profile created by Profiler) assigned to mimic a key Unity understands (like, all those on the keyboard). To avoid trouble with double input, don't program in the profile buttons that were assigned via KSP settings (I like for consistency to assign all via a profile anyway). Now, rotations on the three axes (those working with standard keys A-D, W-S, Q-E) can easily be assigned to the corresponding axes on the stick. Same about throttle. If desired (as I do having so many buttons available) as a handy alternative, some of those keys can go with the Hat switches (in 4-way mode) on the stick. Handy for short pulses, sometimes better then an axis deflection to provide exactly that amount of rotation one needs. The translation controls in my profile are all programmed to buttons on the throttle. The Hat (in 4-way mode) holds the I-K and J-L up/down and left/right translations; two other buttons on the throttle are programmed for H and N allowing the forward/back translations (with a X45, you may use "fire D" and mouse button, or the three-state AUX switch, or normal "D" and shifted "D" (using the pinkie) as you like to have both H and N keypresses available). Now, you may ask, do I ever use the docking mode? No, there is absolutely no need to change modes. All maneuvers come so easy and natural by having all the commands available at the same time, one never needs else than flight mode with my configuration.

Indeed KER is one of the add-ons I consider about finding how to properly manage some of the side problems (e.g. about determining the maxThrust and DV available with the current stage) for the porting (not with the model itself, those quantities can just be user inputs for the model). But KER isn't an autopilot and many users wouldn't want it to become one. Trajectories certainly would fit the purpose better, same for the new add-on LGG is making (though it seems aimed for atmospheric bodies, therefore exactly what my model won't help with), or even MechJeb.

The model is here. Please note I'm still testing, debugging and improving it, can't yet tell it works correctly everytime. The math in the model works, but I have yet to consider all possible situations and apply the correct implementation for the case (e.g. have yet to change the way one of the procedures to determine the orbital change works, for the case of an initial hyperbolic orbit and angle η < 0° (the angle between main axes of the initial and following orbits), though I rely on another more compact procedure in such cases). Please note, the model provided is alike a demonstrator of feasibility, of course repetitive equations fill some of the sheets. I'm already at work coding the equations in C#, though it may take time for me to complete an add-on based on the model. Should there be interest, I would consider a cooperation to port the model to a proper add-on, of course will then provide plenty of details about all this math stuff. Would be nicer to have this model extend the features with an already existing add-on rather than having to create a new one just for it (what I started doing in the meantime). That's also the reason I didn't want to talk about this project before having something working and now for keeping the model under a limited license, it will be reconsidered to adapt with the add-on(s) going to implement it.

For information to all who may be interested, I now have a fully developed and working math model to compute the ideal suicide burn on any body without an atmosphere. "Ideal" meaning it is the most efficient possible. While the routine simulating the suicide burn can solve with any starting condition, the model computes how to arrive at the perfect starting altitude for the suicide burn from any orbit around the body, and how to synchronize the vessel to arrive exactly at a designed landing location. All of the above using the least possible DV. The model is NOT meant to work on bodies with an atmosphere, also because the ideal altitude for the suicide burn would be that low a vessel would almost certainly burn before getting there.

OK, sure some weirdnesses show. From the output_log.txt, lines 57 to 85, KSP is finding 3 different input devices, none of them providing its name. Lines 69 and 85 show only device identified as #0 is then recognized. From the settings.cfg, lines 150 to 153 show again shows which devices are recognized, again only #0. However in the following sections are a number of references to diverse devices (e.g. lines 237, 469, 477 referring to a "Joystick3"; line 1024 referring to "Joystick0"; lines 974, 999, 1099, 1124 referring to "Joystick1"; line 1049 referring to "Joystick2"). One of Unity weirdnesses is about the base used, the first device with buttons is named "Joystick1"; whilst for axes the base is from "Joystick0"; therefore that settings.cfg is effectively showing to have registered input from 3 different devices though only one is recognized! Now, the DXDiag (great it is mostly in English!) shows 4 entries under a Logitech G940 name: the throttle (line 251) with a Controller ID: 0x1; Flight System (line 281) with a Controller ID: 0x0; pedals (line 317) with a Controller ID: 0x2; and Joystick (line 347) with (again) Controller ID: 0x0. (of course the ID is Hexadecimal). So, Joystick (or Flight System), Throttle, and Pedals are those 3 input devices shown with output_log.txt. Now, I can only make a comparison with what KSP shows with my own device (a Saitek X52 pro, so with separate throttle and joystick parts): output_log.txt (at the input devices lines) shows to recognize both parts (as #1 and #0, giving the latter the correct name passed by the OS). Settings.cfg again shows both parts in input devices; clearly input from both are then usable in settings. Can't get why KSP doesn't recognize all three parts after having found them. No wonder KSP doesn't bind a command to a unrecognized part (even if the command was detected). I'd like if you could make a few tests to further define the issue: - can you detach independently any of the parts? What shows with e.g. only the joystick, or only the throttle connected? or both joystick and throttle but no pedals? (of course KSP has to be started after having detached what isn't required, not before). Please check output_log.txt to find if the "input devices" lines hold anything different than before. - axes KSP is unable to bind belong to all parts? or are with one part specifically? - are drivers for your G940 suite updated for Windows10 64bit? and with all the evidence coming from such tests, would fill an issue report with the official bugtracker therefore allowing developers to have a look at it.

None of the bugs that I know does what you reported (many are implied with KSP not recognizing a stick or not registering a stick input, but none about not recording something that appears to have been detected fine). Please provide some information (as suggested here) to help us diagnose that issue; in particular: KSP version (including build number), Operating system, output_log.txt / player.log, settings.cfg. Should you have a Windows OS, please provide DXDiag saved info too. Hope some of the above show a reason why the axis info with the stick isn't saved. Some of the most common issues with sticks are: having multiple connected being recognized by the same device name; another program getting in the way and intercepting any of the input coming from a device (so that KSP isn't getting any: most of stick programming or control applications do); plugging/unplugging USB devices while KSP is running: none seem to be your case but please help us rule out those possibilities.

@nikolak533, @ilionius, please provide all the information that @Kerbal101 mentioned. Even better, provide all relevant information as suggested in this guide. Without such information we can't really diagnose your issue, would only be wasting time trying.