Ald

I think I haz a bug. Shouldn't mailing be sent as a hidden copy to each recipient? Because now it is sent as a regular copy with mails of users subscribed to a mod (as I persume) available in the header.

ScreenMessageHider http://forum.kerbalspaceprogram.com/threads/130759-1-0-4-ScreenMessageHider-Hides-screen-messages-when-F2-is-pressed

Spaceplanes icon - is badly needed. Had thought about it a day or two ago too. That and also a query/search textfield for filtering by typed name.

Agree. In the meantime http://forum.kerbalspaceprogram.com/threads/125277-1-0-2-Solar-Panel-Action-Group!

Not joking, that is an actual feature of debug/cheat menu. Without save editing.

AS MANY MODS AS I CA- Actually, I can't crash with Linux x64, so I'll say Candlejack inste-

Weird. You loose the ability to rotate camera and click on buildings to change scene, but not the clickability of the buttons. For me it's just having all 4 destinations buttons on space center (VAB, TS, SPH, R&D) and hopping to any other scene (I prefer R&D because it's the fastest), and next update on space center gets a regular camera. Never tried clear input locks though.

It's dangerous to go alone! Take this: http://forum.kerbalspaceprogram.com/threads/95168-1-0-X-Malah-s-Quick-mods#QuickGoTo Preferably with this: http://forum.kerbalspaceprogram.com/threads/60863-1-0-2-Toolbar-1-7-9-Common-API-for-draggable-resizable-buttons-toolbar Helps in my case. And that is almost every time I load my heavily modded career.

Ohhhh... ok then. Those numbers aren't that bad, as I don't see them that often. Also I tried to replicate that bug mentioned earlier. 1.2.2. does work fine, no problems with the launch button or the part purging so far.

Teleportation from other topic Yes I am. There is a slight issue with them stacking in silly numbers. Not only them, I saw it also on RealChutes and the stock ones modified by it. Something like this: Name - Available - In use Procedural Liquid Tank - 10762580 - 6393360 (FUEL) Airstream protective shell - 50000 - 1178893 (AERO) Fairing base - 13285 - 0 (AERO) Procedural Nose Cone - 70660 - 0 (AERO) Procedural Heatshield - 316001 - 0 (AERO) Stack-mounted Parachute Module (1.25m) - 1012099 - 0 (UTIL) RealChute Cone Chute - 6567588 - 547299 (no category) Mk2-R Radial -Mount Parachute - 634000 - 0 (no category) Mk16 Parachute - 973598 - 0 (no category) Accumulated after two in game years. Also I do remember having a weird glitch with launch button. It was always inactive, had to do launches/simulations via the KCT button. Although after doing some reinstalling and reverting saves - it works as intended (also did that part purging thing - no error so far).

Sadly I didn't copy that log when it happened. Long story short: After purging the list of stored parts and doing some modifications in VAB on a previously edited craft a error struck (Don't remember the details, but it scared the hell out of me about save corruption). If I'll manage to replicate that situation, I'll post it in KCT topic for sure.

I did mess up my description. Of course I had this message AFTER upgrading to 1.7.0. That other issue was around KCT so don't mind it. After rolling back to 1.6.6 and an old save copy everything is fine. Anyway I'm happy I could help

Doing as asked: Question is - should I be worried? D: I was messing around in VAB on 1.6.6 version. Misplaced one part and had a huge flow of errors in my debug menu connected with Kerbal Construction Time. So I switched scenes to Tracking station via QuckGoTo and back to VAB. Then I had this message for the first time. So I closed my game, reverted to a backup save and updated the Contract Configurator to latest version shown in KSP-AVC. I know it is a pre-release, so bugs may happen. I'm just informing as stated in the error info I'll check if going back to 1.6.6 and old save will solve the problem.

Basically it is a bad idea to keep KSP in Program Files directory (the UAC stuff problems with permissions). Just place it somewhere else. I bet it should solve your problem. Also you've mentioned that you've moved your career. Just to be 99% sure, reinstall base game, copy the GameData folder items (excluding Squad folder) from your old game to your new ksp dir and saves dir (and screenshots if any). For a 100% reinstall all mods that were used on old game from scratch one by one (newest versions available). You simply can't go wrong with this. And launch normally by KSP.exe. ====== Gah I'm dumb. I think I know the cause. I see it like this. KSP.exe launches the version you're physically in at the moment you start it. But the launcher can launch the other instalation or something. Just to be perfectly sure try that method mentioned above. To do: 1) Get a clean install anywhere else than C:\Program Files\ 2) Copy your old GameData contents into your new installation GameData (excluding Squad folder) 3) Copy your saves, Screenshots, Ships directories from old to new gamedir. 4) Launch your game from the new gamedir by KSP.exe If you want to be extra careful @ point 2 do a clean installation of mods based on your old GameData dir. Now it should purr like a kitten.

Have you tried moving whole installation folder to some other partition? Ex. D:\Games\KSP_win ? (assuming you have more than one partition).

You can try this tool for mod management: http://forum.kerbalspaceprogram.com/threads/26031-AnyOS-KSP-Mod-Admin-v2-Mod-install-with-a-few-clicks. Check it out on a copy of your working ksp environment. Or stick with manual updating via KSP-AVC messages.

From my experience I would suggest Career/Science first. Why? Mostly because you're not overwhelmed with all available parts at once. You get to know them, do few missions, get more science, advance in tech tree, get new parts and repeat the whole process. Once you're familiar with the basics, or just curious of some things - go sandbox. Also sandbox is mostly for making your own goals, while career/science is most about contracts (well career more, because funding is essential). I guess Science would be the easiest mode for getting the hang of things (no problems with funding).

Framerate is somewhat lower than on Windows DirectX option. But stability should be rock solid. Just remember to get official nvidia drivers for your card. Maybe you need this? http://forum.kerbalspaceprogram.com/threads/24529-The-Linux-compatibility-thread! I don't remember the need of doing so on my Linux Mint though.

Perhaps I could throw in my two cents into the discussion. KSP and Unity basically is CPU heavy. While having a much worse CPU here (Phenom II x4) I'm able to run about 80-100 mods without much problems in a sensible framerate. GPU influence is negligible (well... maybe not in the AMD-Linux-opengl case). 1) First of all - you need to answer a question: 32 or 64bit? Second question would be: Windows or Linux? Possible scenarios: - Windows 32bit - basically you play till you hit the 32bit RAM limit. You can delay it by not using RAM hungry mods, or by cutting out parts you know you won't be using (example? I reduce my part list on loading by removing most fuel tanks and fuel adapters in favor of Procedural Parts). - Windows 64bit - You can try stuff mentioned in Windows 64 bit community workaround. It is considered a hack, so no warranty it will work properly (but you can always check it out). Keep in mind, that you better not make any bug reports while using this method, as generally win64 unity player executable is considered unstable and therefore mod authors are not supporting it and/or disabling it in their mods. I do understand the motives behind it, as for getting a spam of support requests can be frustrating (as it is not the fault of the mod that something crashes, but the broken win64 unity player exe). You'll also need [WIN][1.0.X] KSP x64 Total Unfixer for mods that disable themselves when detecting that KSP runs in 64bit. Assuming you're using them. Also (again) I would like to point that important thing about not bugging mod developers while using this method. It is a crash-sandbox for you only. If it is too buggy for you - choose other option. - Linux 32bit - I don't see the point of using this combination, so i'll skip it (similar to win32bit option). - Linux 64bit - This is the place, where fun starts. 64bit linux build of KSP is rock solid (my main career is hosted on this option). It can take tons and tons of mods and still run quite fine. Only downside of massive modding would be initial load time and loading times in scene switching. Everything except that is golden. Well... maybe the borkyness of using AMD drivers under linux (my case), but it is manageable. <- BEST OPTION if you can spare few gigs on making a dual-boot on your laptop. And it ain't that hard (trust me). 2) clean KSP installation. Your base (if you don't want to download it all the time). Keep one vanilla copy. Then make an actual gaming copy (it is nice to also make a testing copy for... testing purposes). 3) If you're going with the Windows variant - try "-force-d3d11" option to save some ram. Or the opengl variant "-force-opengl" ("-popupwindow" for those alt-tab problems). 4) If you're going with the Linux variant - [B]LD_PRELOAD="libpthread.so.0 libGL.so.1" __GL_THREADED_OPTIMIZATIONS=1 LC_ALL=C ./KSP.x86_64 [/B] or #!/bin/sh export LC_ALL=C export LD_PRELOAD="libpthread.so.0 libGL.so.1" export __GL_THREADED_OPTIMIZATIONS=1 I'm never sure which one is better. Both work though. 5) Go fiddle with the ingame config. Experiment with the ammount of physics done in a timeframe. Experiment with renderer. Experiment with the texture quality. Experiment with shadows and lights. Try different options. Go crazy. Hope this may help you. If in doubt - test it Stuff I mentioned above is basically bits and pieces I managed to gather from various topics. I'd like to thank creators of those topics and their participants for all the tech observations and fixes mentioned there. All rep towards them.

Can confirm that. Every single time a "invisible" part of ship falls off throught the rocket with the described effect. In flight log I get info about overheating fuel tank at 0:00 mission time. And on 6000m info about overheating various other stuff. Rest is just spinning out of control and going kaboom.

The last glimpse of loading screen showed microwave*.png for me before crashing, but log stopped on last png in planetresource data.

Well I said I didn't do anything fancy but: 1) open those two files in Gimp 2) export both as the same png (overwrite) 3) change compression level to 8 - rest default Only difference is in size. Originals 2,4kB. Edited 2,2kB. I know it is weird, but now it does load without a crash on Microwave*.png. And that's why I wanted someone else with similar config (linux64 and lots of mods) to test it. I'll check how new version behaves. Edit1 1.1.5 went through the load without any issues on first try. Edit2 Nope, happening again. Computer voodoo I tell you. Edit3 I've sent you a comparison zip with logs and screenshots.

Sure, no problem. Sent you a PM with them. Although its no biggie, just recompressed them. I'm really interested to know if anyone else who had this problem, tried this trick. Would like to know if this helps (as it did help in my case).

Updating libpng didn't change anything in my case. Also note that there are other pngs in the directory that work fine. Last time I had a game crashing problem with some mod, the cause was a texture that had one dimention that was not a power of 2. But that doesn't seem to be the case. Maybe its something with linux being case sensitive? Microwavetransmitter.png or microwavetransmitter.png? Haven't tested that yet, - - - Updated - - - FunFact: I did open both pngs in Gimp and overwritten them with themselves with like an 8 on compression setting. It did work for me. Whole game loaded to main menu

This happens to some people (including me). Try going into GameData/KWRocketry/Aero and delete all folders with a "NoseCone" in it + 150mSRBTop folder (just leave the Fins). Then try launching the game again. Or the thing posted bellow