dewin

I suspected they were driver-related as well, but in my case I'm using VMware's video drivers inside the VM so it might not be that easy. That said, nVidia cards are horrendously buggy -- an issue the drivers mostly patch around. The best example of this I've seen is when WoW first released a 64-bit client: tons of minor graphic issues, fixed by... renaming wow64.exe to wow.exe so that the drivers could apply the correct game-specific fixes. (Renaming games to hl2.exe has been suggested fix in other cases, as well.) I'll tinker more after work today.

This was a problem with RealChutes parts mounted in symmetry back in 0.23, but I'm pretty certain that instance of it has long been fixed. Still possible something else is triggering it though, but update your mods. If it's the problem I remember, it always triggers just above a certain altitude (5km, iirc) when Krakensbane activates (a game mechanic that changes from moving your ship around the universe to moving the universe around your ship.). Is this what you are experiencing?

Here's an update: I opted for the latest Linux Mint for my testing. Virtualbox Virtualbox claims accelerated graphics, and they certainly felt reasonably 'snappy' during the install process. It also worked with Virtualbox out of the box, including proper sharing of mouse/keyboard and being able to resize the VM window and having the VM's desktop scale accordingly. However, KSP ran at a crawl (seconds-per-frame speed, as opposed to frames-per-second). I fiddled a bit -- but even after confirming that hw acceleration was, in fact, happening -- no luck. VMWare Player Free for personal use, which is all I'm doing here. (Otherwise it's an evaluation). Much more of a headache to get setup, but KSP started much faster and definitely had proper acceleration going on -- though I also had some impressive graphical glitches, like sometimes having a hall of mirrors-effect (the background of the scene not redrawing properly) and, at one point, everything being rendered on a solid white background. Oh, also, KSP doesn't think it can run at 1920x1080, but this might be due to the VM not having the full screen real estate available (due to VMWare player's window chrome). This is minor and probably easily fixable. Also, Steam launches the x86 client by default, but the x64 client is also available. Will need more tinkering to see if this is remotely feasible... also, while it's getting accelerated, it's probably still not as fast as running native. I'll tinker more to see what I can find out. Observed graphical glitches: Vessel background doesn't update when there's no objects in the background (e.g. ship in Kerbin orbit, looking away from Kerbin). This causes the vessel to render on top of previous frames until a body comes into view. (Fixed by turning off Edge Highlightting (PPFX)) Making any change to graphics settings hangs the game for a long time Space Center models are basically partially-rendered wireframes, unless I zoom in close to one -- which causes other issues. (Fixed by turning off Edge Highlightting (PPFX)) Space Center looks extremely ugly, with lots of z-fighting. Large chunks of the VAB UI don't display, including buttons for categories and the background behind parts. (Fixed by Force Fallback Shaders, but that breaks most of the text.)

I've also ran into this problem, FWIW, and I use to be able to run a much heavier install in 0.22/0.23 as well. My hope is that I can free up some memory so I can at least go longer between crashes/restarts. (Actually, now I'm on a project to see if I can get KSP to play nice in a 64-bit Linux VM so I can play it without dual-booting, but there's already a topic for that.)

It looks like Virtualbox may have proper 3D acceleration support, it's just disabled by default as it's "experimental". Presumably it presents itself as a generic video adapter if disabled. I'll be trying this when I get home tonight, though there's going to be a lot of other overhead (Like figuring out Steam for Linux, whee!). I'm hoping I can get the two KSP installs to share the same space, but we'll see -- one problem at a time.

(Forums ate my first attempt at this post, take 2!) I specifically don't want to dual boot because I want my Windows environment to continue to be available while playing KSP. The reasons are personal, not technical -- I'm more than capable of setting it up but I'm looking for an alternative. Some versions of VMWare claim support for hardware acceleration in the guests, though it's unclear as to whether that applies to any of the free versions. As noted above, there's reasons I don't want to dual boot (mainly the 'rebooting' part.) 12GB available, so I could easily give the guest 6-8GB. Modded KSP installs can start causing memory issues (fairly quickly with large part mods), and and running KSP's 64-bit Linux build seems to be the recommended way around them if other efforts don't work (AdvancedTextureManager, etc.)

Edit: Got this ALMOST working at acceptable framerates but with pretty severe graphical glitches, findings are in post #19 [sorry if this is the wrong forum for thus.] I've decided that I'd like to be able to run KSP x64 -- and it's pretty well known how stable the Windows x64 builds are... So I was pondering building a Linux VM for KSP (and Minecraft, but that's not relevant) -- as a bonus, it gives me an extra layer of protection in case I inadvertently install a malicious mod. I have plenty of experience with virtualization and Linux (I work with both professionally), but I've never actually tried to play graphics-intensive games in a VM before. I know that I'll need a hypervisor that supports hardware accelerated graphics -- any suggestions? (Ideally free or low cost) Alternatively, is there anyone running KSP in this arrangement who'd care to share the details of their setup and any observed pros/cons? [No, I'm not interested in dual booting or making Linux my primary OS.]

Based your post and my own observed crashes, you're definitely crashing due to memory. I see you already have AdvancedTextureManagement in your mod list. You might try setting your texture resolution to half and/or using more aggressive settings for ATM to squeeze out a bit more memory. Alternatively, the -force-d3d11 or -force-opengl launch options may help with memory usage -- but you may notice some pretty significant graphical glitches. Lastly, you can try removing some texture-heavy mods. Regardless of all this, there does appear to be a memory leak so this merely buys more time between crashes. Whether the leak is stock or an addon or both is anybody's guess though.

TL;DR: You might have a corrupt .craft file. I just ran into a similar issue, presumably caused by somehow having a corrupt .craft file. In my particular case, this was the sequence of events: 1. I named a ship, put the first part on, and saved it. (Not entirely certain of order.) 2. I realized I had an existing craft which would be a good basis to modify, so decided to load that .craft file instead 3. Clicking Load did nothing -- even after exiting the VAB and some other trickery. I opened up the debug log and saw it complaining about a particular ship not having a root part: [ERR 22:14:13.443] [ShipTemplate]: Could not locate root part in Comsat KP1 as 0 entries remain after eliminating all parts listed as children. This is probably wrong. [EXC 22:14:13.445] NullReferenceException: Object reference not set to an instance of an object ShipTemplate.SetIfControllable () ShipTemplate.LoadShip (.ConfigNode root) CraftBrowser+..ctor (System.IO.FileInfo ) CraftBrowser.buildCraftList () CraftBrowser..ctor (Rect rect, EditorFacility facility, System.String profile, System.String title, .SelectedCallback onFileSelected, .CancelledCallback onCancel, UnityEngine.GUISkin guiSkin, UnityEngine.Texture2D fileIcon, Boolean showFlagButton) EditorLogic.loadShip () -- then realized that it was the ship I had saved in step 1. Sure enough, I managed to somehow save a ship with that name with zero parts, which results in a .craft file that looks like this: ship = Comsat KP1 version = 0.90.0 description = type = VAB size = 0,0,0 To see if this what happened to you, look at the debug log in game (Alt-F12 on Windows), or just look over KSP\Saves\Company\Ships\VAB for an extremely small (1kb, actually <100 bytes) .craft file and delete it if present. Hopefully, Squad can fix this to skip loading of the affected craft and possibly indicate it as corrupted) rather than breaking the load facility in its entirety, as it prevents loading any craft if one craft is broken.

Built a reusable mobile science station in my career-mode game. Took it to Minmus. Edited my persistence file to fix an addon bug that was duplicating Kerbals. Deployed a lander in a bazillion biomes, docking with the station in between each visit. Visited my first-ever anomaly. Returned to Kerbin orbit at a 200x200 parking orbit for future use and sent the return craft home... with 37 experiments onboard. Landed safely (phew, I hadn't tested either lander)... except the lander somehow duplicated itself -- one copy would insta-explode, the other copy spammed NullReferenceExceptions and wouldn't work. Spent about 30 minutes figuring out how to fix my persistence file to allow a successful recovery, and brought home 2300 science (+ the crew and EVA reports I transmitted along the way). Next up: Resupplying the science station to do a similar run on the parts of the Mun I haven't landed on yet.

Found a slight bug: I have -- as my crew aboard a vessel -- Jebediah, Bill and Neddun. Jeb and Bill are both sitting in a mobile processing lab, Neddun is in a command module. When I click the EVA button in Science Alert to do an EVA report, it makes Jebediah EVA. The only problem is that he ends up EVAing out of the Command Module, not the Mobile Processing Lab... except since he wasn't in the command module in the first place, he doesn't get removed from the ship. So, in short, I end up with two Jebs. (Before I noticed this I ended up with two Bills as well.) I'm also running Crew Manifest (which is how I moved them to the science lab in the first place) so it's possible that it's contributing to the problem, but the problem persisted even after cleaning up my persistence file and testing it again. I suspect EVA report targets the first crew member it finds (which is okay), but doesn't identify where they're housed correctly to determine where they EVA from?

As an aside, PreciseNode has this as a built-in feature as well

Agree, especially with the Mediafire bit. Mediafire is downright malicious with the crapware they try to trick you into downloading. (Fortunately my Chrome setup negates most of the crapware, but that still doesn't excuse their behavior -- and KSPModAdmin sadly uses an ancient embedded version of IE which makes Mediafire even worse.)

ModuleManager doesn't have any requirements beyond a text editor (aka Notepad). So, all's you would need to distribute is ModuleManager and your own configuration file (which is allowed) as opposed to distributing all of Squad's parts (likely not allowed)

Update your version of RealChutes, and delete the old folder in the process. I was experiencing the same issue. (Essentially the CoM gets "misplaced"). The problem actually happens at 6KM for me, and gets worse every additional 6KM -- odd, but I think it's due to some sort of universe offloading that happens at that altitude (aka Krakensbane). While the update fixes the COM issue for me, I'm experiencing an issue where I get NullReferenceException spam as soon as I hit that altitude while Realchutes is installed -- so some portion of the original problem still remains. The problem goes away if Realchutes is removed (same vessel). Occurs on both 32-bit and 64-bit builds (though my 64-bit build is now crashing as soon as starting or resuming a game due to another mod, so I'm not touching it at the moment.)

First of all, I am not a physicist (much less a real-life rocket scientist), so the math here is likely wrong -- but I'm hoping the premise is solid even if the math itself needs some adjusting. It's frequently useful to launch spacecraft that have stages with extremely low TWR (< 0.10), particularly when doing interplanetary travel where fuel efficiency becomes king. Unfortunately, this frequently results in burns that are 20+ minutes long -- which can only be reduced to 5 minutes (at best) by applying 4x physwarp. My usual fix for this is to add extra engines -- but of course this is inefficient, as it means I'm trading dV for TWR, weight, and cost. What if, as an alternative to physics warp (or extension to it passed 4x), there was a level of "time dilation" that essentially did: rate X (normally 1) => increase effective thrust and rate of resource consumption of all engines by X; scale current velocity and gravitational effects on physics-loaded objects by X; time for objects on rails (including bodies) advances at a rate of X seconds per 1 second of time in the local reference frame (Essentially, if all of the math was corrected -- temporarily multiply the current vessel's thrust, but alter the world so that the thrust multiplier doesn't gain any advantage other than real-life time savings). This could happen as an extension of physics warp -- 6x could be 4x physwarp * 1.5x time dilation, 8x would be 4x * 2x, etc.

Honestly, having run into this problem myself even with some LV-N powered craft, I think that there needs to be some sort of way to handle extremely long burns better myself. Something's wrong if I have to go back and add engines to a craft simply because I don't want to wait 5 real minutes for a burn (at 4x physwarp) Maybe adding higher levels of physwarp that are only enabled outside of atmosphere is an option. Spacecraft with very low TWR don't tend to be experiencing drastic forces during their burns anyways. I almost wonder if a sort of pseudo-time-dilation could fix this... which I'll post as it's own suggestion because it's a bit more complicated and affects way more than just Ion Drives.

Note that the individual parts in Science have individual unlock costs (I think that's what they are?) -- this is why you need to manually unlock them when you install new addons midgame. But the unlock costs currently aren't deducting from funds, so this is a possible additional hit to them that's not currently in game. (If those aren't unlock costs, there should be something similar IMHO -- so that the science points expenditure is to learn that it's possible, and then the unlock costs represent the R&D expenses for full scale testing, etc.)

The latest version includes "Included JsonFx.dll, which is required by ModStats", but there is no JsonFx.dll anywhere to be found in either download.

Man, I'm wishing I had saved images of my first (and only) successful SSTO from a few days ago. Admittedly, it did lose parts: Both jet engines. At 65km. Somehow managed to glide to a safe landing from that altitude (there was no LFO for the nuke)...

Edit: Not a MM bug. Apparently a MM configuration file ended up in the Squad folder and broke lots of things when I removed its respective addon post-0.24 Original post:

As clarification, Chrome is reporting it as a "Uncommon Download". Which means that Chrome thinks it might be dangerous (likely because it contains a DLL) and it hasn't been downloaded enough to determine a reputation that confirms it as dangerous/"safe" yet. Not quite the same as "Malicious." -- see https://support.google.com/chrome/answer/4412392?p=ib_download_blocked&rd=1

I finally managed to get a working SSTO spaceplane that didn't randomly veer off the runway (much) during launch, disintegrate, or burn up in the atmosphere (FAR + Deadly Reentry) Aaand.. botched the descent by trying to turn on the turbojets too early, which instantly exploded from overheat. Aaand... managed to glided it down to a safe landing from 60km with NO ENGINES and NO PARACHUTES. I'm pretty proud of myself right now.

Hmm. Does the new RemoteTech release fix the long-standing issue posted here?: I'm not the plugin author (nor have I poked at the source), but I practically have a 100% "breaks games until next reload" test case of build comsat as subassembly, build multi-satellite carrier craft, attach comsats in symmetry, deploy 1-2 satellites successfully, crash somewhere around the third or fourth deployment when changing ships. The one common link I can think of is that the satellites all have the same origin vessel and have been renamed. (In fact, one crash was while cycling between them to change them from "Kerbin Comsat Launcher Probe" to "Kerbin Comsat E1" etc. The crash only seems to be on scene change, so cycling with '[' and ']' doesn't trigger it (nor switching from the map if the target is in physics range) (Sorry for odd quoting, not entirely certain how to properly quote from a closed thread.) I checked an earlier dev snapshot (it was never published officially, I just snooped around on Github) and it didn't seem to be then, so I figured I'd check again.

Should work fine in Python 2, though you might want to add: from __future__ import print_function (Yay, I'm not the only person who targets Py3k in my Python code)