diomedea

ops, you got me! maybe, is @Deddly around too ?

ok, thanks for that latest log. It still shows the pagefile being = 0 MB, though I'm sure you noticed. Actually, pagefile serves to allow RAM be swapped between applications, without that any other process loaded (even if currently inactive) stays resident in RAM and can't be swapped out. Meaning, the effective RAM available for KSP to run is even less (indeed, was reported as 725 MB free with that last error.log). With a pagefile large enough, OS swaps RAM content of inactive processes to disk, so to let all RAM available to the process in foreground. Am I right your system is Windows7 32bit? 32bit OS can only map up to 4GB memory with any application; however the low 2GB of RAM are by default to the system itself. Is possible to change how the system reserves RAM by use of 4GT and /userva system settings (info here). Glad you see launching in OpenGL works, indeed that mode takes less RAM. But if you observe the amount of RAM used by KSP (e.g., from a Task Manager reading) you'll notice to be quite close to the limit; anything like a complex game or add-ons will push over that. Indeed, before KSP_x64 was stable, I also had to use OpenGL with the 32bit versions of the game (plus some add-ons to reduce textures size, now no more required as KSP changed the format of those files to be smaller).

Could you please show a new error.log after having set the pagefile? Previously was reported the OS had allocated only 2GB address space to the application, and KSP really can't work with that low amount of memory. I hoped the pagefile could allow the address space be increased, would like to see if the issue is still that or a new one.

Someone feels not able to speak freely here...

Falling through ground is the result of missing or wrong colliders with the model of the part (same would be for moving through other vessels). If the tanks fall bottom-first, would be a collider for the bottom missing or oriented improperly. This could be an issue specific with the Procedural tanks add-on, if confirmed with only that add-on installed on a stock KSP install (plus all required dependencies for Procedural tanks to work properly, of course). In that case, better to report in the proper thread for it.

Please provide us something to look at (what listed in this guide would fit for starters).

Happy the workaround worked for you Thanks for DXDiag.info, interestingly in Diagnostics section it also reports a problem with KSP_x64.exe. However I'm not able to find hints in there showing the real cause, sorry. Believe at this point the cause be tied to that d3d9.dll, though it seems fine to me. Should you have other games using DirectX 9, those also may encounter issues (not necessarily all, sometimes a copy of that dll is installed with a game folder so to not depend on the one in system).

Yes, I was allowing myself a bit of humour. But you did well to alert me about the mood, sometimes I lose the meaning in such messages

Believe that won't happen. Squad still has a partnership about KSPEDU, a spin-off devoted to schools. That one can't be rated 18+ anytime and I'm sure Squad will honor that agreement making sure the base game doesn't either.

Thread is too old, the issue has changed with all revisions of atmo drag and thermal effects in KSP since then. Should a similar question arise with a current version of KSP, users should open a new thread instead. Locked.

Glad to know you solved it, thanks for sharing the cause. From now on, will have to insist to get info about BIOS and overclock settings too when it is a system issue, instead of just one with KSP.

What about Squad services (this forum in particular with all the content from community members) ? Will these still be Squad property or transferred under T2? In which case, rules will change to suit the new property (hint) ?

Thanks for that, it's all I need to feel better.

@UomoCapra: a partnership with a renowned, experienced operator in the game industry like T2 is certainly a positive step, it ensures more funding for future development and (maybe) even plans for a sequel. Don't know of many other indie developers who stayed on their own for 6+ years with a product able to sell as much as KSP, Squad showed to be really committed to the game and community doing so. But now, should we expect another change in the EULA? even worse, will the DRM policy change and make our digital lives with KSP somewhat harder? Perhaps early to say, but this is my main concern with these news.

The error.log shows "d3d9.dll caused an Access Violation (0xc0000005)" instead of a KSP or Unity file. d3d9.dll is Windows library for DirectX, isn't known for causing such errors (and your dll version seems fine). Also the nVidia driver (nvldumdx.dll 22.21.13.8233), though having been reported in connection to various issues, has never emerged to be the cause. So, can't find any evident cause just now. Would you like doing a couple tests to better define the issue? 1. Launch KSP in DX11 and/or OpenGL mode instead of DX9. Doable by adding " -force-d3d11 " or " -force-glcore " as arguments; with Steam, open Properties for KSP, General tab, Launch settings to paste the argument. If the issue was really caused by d3d9.dll, there shouldn't be an issue in these modes. 2. Save a copy of your settings.cfg file somewhere safe, then use a text editor to open the file within KSP root directory. Search for lines with "SCREEN_RESOLUTION_WIDTH = " and "SCREEN_RESOLUTION_HEIGHT = ", those hold the current resolution settings. Change those to any valid combination supported by your display. Please make sure to use a combination supported. The display control panel should show which are valid combinations, those should be the same available in KSP settings. Should test 2. work successfully, please verify what KSP settings show for valid resolutions, it is expected those to match with the display control panel. If none of the above works, further info could be of help. Mind providing output from DXDiag?

To make this clear: your system can't have 0 RAM. Otherwise it won't boot at all. But the OS shows 0 RAM being available when KSP is concerned, the amount with RAM and other memory is a OS function being invoked, the wrong info isn't from KSP, but from the OS. Indeed that info isn't correct, can't be: but is effectively what the OS is providing and that is causing KSP to crash (when it is KSP crashing, not the BSOD). As for the BSOD, you are welcome to look for help anywhere else you like: there is no reason you'll get worse help about that than on this forum, and I may well not waste my time trying to help with such system failures.

Can you provide an explanation for a system (not KSP) that reports to have 0 RAM available, that allocates 0 MB as virtual space for an application (again, this isn't KSP fault)? And that often crashes with a BSOD (what no application can cause, but is tied to kernel or drivers). Perhaps another explanation is, KSP is the only application calling a defective driver installed on your system, and that driver is the BSOD cause. Did you update any drivers lately, after installing 1.3?

Good your PC is still that new, probably you may get it repaired for free if the warranty hasn't expired yet. Provided that covers the fault. If really it has a damaged drive, that may come from having slammed hard, a kind of damage not always covered. But first, you need to verify what the cause is. A damaged drive shows doing a disk check: here all the info needed to perform it in Windows. In the meantime, mind showing some details about your system? Brand, model, CPU, OS installed, RAM, Drives, Graphics, GPU, Video RAM. Most if not all are available from Start - Control Panel - System. Also, you know how to check the BIOS settings? (there should be a function or ESC key shown during boot-up for entering those). How to enter advanced system settings, e.g., to set paging file size? (Control Panel - System - Advanced Settings - Advanced - Performance - Settings - Virtual memory). Should the disk not be damaged and another cause for those troubles have to be found, such info will be if importance, BIOS and advanced settings included. It may not be that easy to perform all the steps required to verify or even fix other possible causes, if you have a friend or someone there able to help could be best.

Error.log with the crash folders show: 0 MB physical memory [0 MB free]. 0 MB paging file [0 MB free]. 0 MB user address space [xxx MB free]. (Note: xxx = 153, 163, 164, 183 MB with the different logs) Write to location 02000000 caused an access violation. First line shows amount of RAM, total installed and [free]. Second line shows amount of paging file (on disk), total configured and [free]. Third line shows total address space the system allows for the application (virtual space). The fourth line shows what caused the crash: writing to a invalid memory location. Now, if the OS sees 0 as available RAM, there won't be any possibility to make it work. Not even if the paging file wasn't 0 (though it is). The OS set 0 as address space because it had no space available to manage, KSP had no virtual space and tried to write at the very first location programs know to be where their space normally starts. This has nothing to do with KSP, there are some serious issues with your system. No application (like KSP is) working at ring 3 can cause a BSOD with modern OS, it is the result of a fault at inner rings. Seeing no RAM (nor a paging file) isn't normal for any OS, and no application can fake that. Clearly, you can't have crash logs for BSOD, it is the OS to be crashing leaving no chance for an application to do anything. You're saying this happens only with KSP and not with other games. I was considering the cause to be a defective area with the D: partition where KSP is installed, as that may result in crashes only related to KSP; and if the drive is damaged, a defective area may be where system files are held too, springing BSODs and false readings. Can't tell for sure a defective drive being at the root, but remains to me the most probable cause (even considering all the other troubles listed). Unless you have a better explanation for a computer able to boot without RAM...

Yes, those "System out of memory!" lines really show the issue now. Actually, you were right to provide crash logs before, the error.log in them shows memory with your system: 2048 MB user address space is really too low for a game like KSP. Doesn't help the total RAM with the system is ~3GB (pretty low, the OS really can't manage enough RAM for applications), and the paging file shows 0 MB total [2144 MB free, but that seems a mistake]. That paging file should actually be set to a value ~ 4GB (check e.g. here) for the amount of RAM and OS in your system to work best. That alone should provide enough to increase the user address space for the OS to be able to allocate memory for KSP to work.

Believe this "issue" has more to do with how your MIG-21 replica was built, than with technical issues with the game. Therefore this thread has been moved to GamePlay Questions. The very first possible cause when planes go out of control is inherent instability in the design. In KSP, a good enough rule of thumb about longitudinal and lateral stability (Pitch and Yaw) comes by comparing the positions (visible in the editor) of the plane Center of Mass and the Center of Lift (though, to be correct we should use the Center of Pressure that KSP doesn't show). Having Center of Lift (best, Center of Pressure) forward of the Center of Mass makes the plane unstable, any amount of Angle of Attack would only increase by itself until no amount of control from elevators can compensate it. Roll stability is generally ensured if the Center of Mass lies lower than the Center of Lift. Please note, stability is quite complex, changes with the relative angle of the airflow, attitude of a plane and its airspeed (some add-ons in KSP do a very good job to compute stability, e.g. CorrectCoL or FAR). Also to note, real fighter crafts (as the MIG-21) are designed so to have very low stability or even be inherently unstable (because that reduces time to perform aerial combat maneuvers), therefore a replica of them in KSP is probably showing as low (or even less) stability. Anyway, examining your replica will certainly show the cause of that behaviour: would you mind uploading the craft file for others to check?

Yes, can confirm that seam to be still visible in KSP 1.3 under some circumstances (e.g. I see it only when the camera is facing east or down, not west). Very small and not bumpy for what I can see:

Your output_log from the most recent crash shows you are running KSP modded (specifically, Kerbal Engineer and MechJeb2). Delete those add-ons and test if the issue persists. You may have installed an obsolete version of those, or have incurred in an issue with one add-on, to be reported with that add-on thread (or, if you can't identify a specific add-on causing the issue with a modded install, report here). Only in case you verified the issue with a pure stock KSP install, provide us all the info suggested here.