Brigadier

"Mods that every player should have" certainly leaves the door open to interpretation. I'll try to meet the spirit of that title by suggesting the following for an improved KSP experience, from my POV. I've played mostly in Science and have started a Career game so this taints my perspective. Should Have KER (or something equivalent), just because that data should be available to any budding rocket scientist. Don't leave home without it. Kerbal Alarm Clock, because time waits for no one (except for quicksaves and reversions to launchpad) More system memory. My crashes almost completely disappeared when I upgraded from 4GB to 12GB RAM. (Just thinking outside the box; is this not a mod too??) I've not tried MechJeb or FAR, so can't praise their usefulness. Nice to Have Orbital Science SCANsat Science Alert USI MSK/OKS (too many new parts...I can't find the stuff I need ) I have about 30 mods installed (some are dependencies), but these are at the top of my list. I guess I, too, need to try some others based on what I've read here, such as Precise Node and Asteroid Day. Then again, wasn't that the point of the thread? Disclaimer: No criticisms of others' play styles is stated or implied . You mileage may vary.

Admirable goals. I believe that the in-game help would be the best first step but it depends on how most people learn their mods in KSP. Do they visit the github (or any other) widi pages, troll the forums, wing it, dive into the sandbox...? For me, it's the in-game help. Just my 2 cents worth.

You're absolutely correct. I reread (a couple of times) all of the documentation on github and that what it says in Section 3c - disabling Stock Scanning also turns Instant Resource Scanning off. I'm also clearer now on the what those actually mean to gameplay. If I have it right, amongst other effects, disabling Stock Scanning means that all scans will require surface overflight to build the scan results (non-instantaneous) and if there is a separate scanner for a given resource it will be used instead of the stock parts. My difficultly came from not understanding what stock scanning did and how it did it, having only had access to the M700 from the tech tree before I installed SCANSat. Gotta love the learning curve.

Thanks, I was hoping it was that way. I'll eventually get to MKS once I've figured how to get into orbit reliably with payload. Sorry, another question came to mind: I'm not clear on what the options "Instant Resource Scan" and "Disable Stock Scanning" do and how they interact. I've reviewed what you've already written on the first page and on github but I don't understand the ramifications on the game enough to feel comfortable changing them. Which combination provides the most immersive game play? If I understand it correctly, the former disables the stock parts' instantaneous scan time. The latter completely replaces stock part behaviour and makes everything work like SCANSat parts.

Just wanted to say that this is truly a great, playable mod. I'm not doing career yet (soon, soon), just playing around in science mode mostly, but it provides a great incentive to plan missions, establish different orbits and teaches patience. I've read half of this forum and the github release pages, and still have a question. I use the Resources button on the big map and under that I see only "ORE". I've been scanning Kerbin and the Mun with a M700 and all of the SCANSat parts (I realize that they aren't resource scanners but I'm just to figure out what they do and how best to deploy them) in sandbox mode. I compare what I see on these forum and release pages and am wondering how to view all of the other resources that seem to be available. Are these from other mods or have I just not gone where these resources exist?

I think I've planned more rescue missions than actual science-gathering missions. Getting stranded because of a lack of fuel/electricity/landing craft stability is only just behind showering pieces around other worlds as I struggle with limited resources at landing.

According to the error.log file, it appears you have a 4GB system. When I got this same error (and it happened a lot), I had to reduce the screen resolution and turn anti-aliasing down to none. I'm running an older Radeon HD5700 series card with 1GB of DDR5 memory. I've since returned the AA to its previous level (x2) and haven't experienced a crash since. There may be other graphics effects that might impact this phenomenon but I haven't played around with it too much. I'm happy it's stable and without doing any research, I don't understand most of the graphics settings anyway. Time to do some digging, I guess. My 2 cents worth.

In my limited experience, my mono.dll error was caused by my setting s too high a screen resolution. I reduced it and set AA to none and haven't had a crash since (easily 16+ hours of game time). Could it be because of your gfx card? YMMV

Likewise, thanks.

Well, as far as the re-entry heating is concerned, since I understand the heating algorithms have been significantly changed with the 1.0.x releases, try using a heat shield on the re-entry vehicle. The parachute is now burning up if you release it too soon (this happened to me until I understood the more realistic physics being applied to re-entry), so wait until the heating effects are gone before deploying. Right click on the parachute before deploying and look for the recommendation on chute deployment in the part window (I've seen Unsafe, Risky and Ok flags so far). I've also noticed that the SAS modes are much more sensitive. I tend to leave SAS ON and manually adjust the vehicle orientation on descent or use RETROGRADE but sometimes my capsule flips, even with a nose cone chute. It also means watching your battery power carefully.

I had the same error and, according to the error.log file, it appears you have a 4GB system. Try reducing the window resolution in Settings before running the game. This solved the problem for me.

I think I may have resolved this. I decreased the window screen resolution from 1360x1024 to 1280x1024 and turned anti-aliasing from 2x to off. Ran for 8 uninterrupted hours. Next, I'll increase each of these one at a time to see what my limitation is. I guess I might need a new gfx card.

KSP: 1.0.4 (Steam) Windows 7 SP 1 32-bit Problem: KSP crashes frequently, often when recovering a mission but just as often after a period of playing time (not consistent). Mods Installed: KER v1.0.17.0, Active Texture Management - X86 - Aggressive v5-0, via CKAN v1.8.4 (beta) Extract from error.log Unity Player [version: Unity 4.6.4f1_99f88340878d] mono.dll caused an Access Violation (0xc0000005) in module mono.dll at 001b:10107259. Error occurred at 2015-06-27_231248. D:\Program Files\Games\Steam\steamapps\common\Kerbal Space Program\KSP.exe, run by xxxx. 77% memory in use. 3580 MB physical memory [792 MB free]. 0 MB paging file [2645 MB free]. 2048 MB user address space [133 MB free]. Write to location 00000000 caused an access violation. I can upload the output_log if it's required and someone tells me how best to do it. I've seen discussions of access violations related to the frequency of reversions to the Space Center but this error can occur, for me, without any reversions. It appears that I'm running out of memory but I reduce the running software to reasonable minimums (no browser running, no email client, unnecessary TSRs stopped, etc.). The error occurs regardless. The game has been removed and reinstalled and I've tried playing without and with ATM Aggressive and Basic in attempts to reduce the memory load. They don't seem to help at all but I'm not sure I'd see a difference. This is a fascinating game and I really enjoy it but the crashes are annoying and will prevent me from trying longer missions in fear of losing valuable progress (I don't have that much free time!). I recently played it on another computer (Windows 7 64-bit, 16GB RAM) and it never crashed after 30 hours of gameplay over several days. I'd upgrade to 64-bit and add memory (not just for this game ) but I've seen posts that suggest 64-bit KSP isn't stable. Do I run 32-bit KSP on a Win 7 64-bit? I was hoping that 1.0.x versions were going to solve this. I keep hoping.