Eleven

Hey could you share those probes you designed to visit the Outer Planets?

Not sure if this means anything, nothing went wrong with docking but I noticed this strange message in the docking window: This was with dev version 405

I have a sneaking suspicion this is also related to why I can't see the rings of Sarnus and other texture issues when I try launching the game from anywhere other than it's own directory...

I was tracking down issues with OPM and had forgotten that I installed OP+1.6 (I even forgot it was a WIP) and kept seeing all these exceptions in my log file. I got rid of OP+ and it seems that's where all of those Planet Ui logfile errors were from. Is this going to be the official moons/asteroids/comets mod for OPM, or are they working on that same thing too?

Far out, I was just grasping at straws because that's a common thing when people make mods and aren't familiar with linux syntax. I didn't know about that exact issue back then. For the record, I have no issues with the Rings showing up in Linux when I fire up the game from a window manager and simply double click KSP.x86_64 (or even just typing it out in a terminal window within the KSP directory), but when I try and setup a simple desktop icon to start the game for me, that's when it all goes away. The syntax issue may have been resolved for the Rings themselves, but maybe there is another error somewhere that doesn't use the correct enviroment variables when NOT starting the game directly from it's own directory?

There's definitely an issue somewhere. I don't use steam but it sounds like we're having the same problem. Can you copy your steam install to some other directory and try launching the game from there? I bet your rings show up Also interesting that we're having the same issue and we're both on Linux Mint. I wonder if Kittopia has some setting with a Capital letter somewhere it shouldn't be, or vice-versa. I've seen that simple mistake break mods on linux before. As for your issue with zooming out, that's a new one on me. I have a low-end laptop with intel graphics and I can zoom all the way out in the tracking center. Hope you can get that figured out.

I know this wont help you much, but I too am running linux (Mint 17.1 64bit) and LALT+N does bring up the EVE config window....

I'll save the logs from each type of startup and compare them. Memory is just fine, I've been keeping a window with htop open for a while now trying to gauge my memory usage with KSP. Even with a decent amount of parts and plugin mods I'm barely scratching 3gigs of my 8 available. The Desktop icon launching in 32bit *could* be worth checking into, although I've done that method of starting the game since 0.17, under 64bit linux and never had graphics or texture issues. My first thought was that somehow by starting the game from the desktop, even though it's *supposed* to start from the KSP directory, maybe something is getting screwed there and it's not realizing what it's doing. When I start the game from a nemo file manager window, there is no doubt that I'm starting the game from it's own directory...maybe Kittopia doesn't know where it's running from when I start from the desktop? Who knows, it's nbd, but I'll check logs tonight and see if anything shows up. (EDIT) OK, I checked the logs quickly and even using the method to launch the game that results in the rings of Sarnus and the new oval Ovock appearing correct, I see lots of exceptions. Not sure if those are issues or not but most appear to be Failure to load planet UI errors. (EDIT EDIT!) I just realized that I also have the OP+ WIP mod running, I think a lot of those exceptions were from that. I've removed OP+1.6 and all of the relevant exceptions seem to be gone, but the same issue with rings appearing and not appearing depending on how I start the game is still there. Will re-do the logs and upload again.

The hotfix is perfect. Wasn't looking forward to installing things again. I did leave the @Default.cfg changes in there as well and didn't see any issues. I do have a question if anyone might be able to shed some light. I'm really not sure if this is a OPM issue or just a linux thing, (I'm running Linux Mint 17.1 64bit, cinammon on a laptop) I've never run across this before: I have a desktop launcher icon set up to run the game, nothing fancy just the usual stock launcher icon that you'd make for any program you want to just click on an icon on the desktop to run. When I run the game from that launcher, the rings around Sarnus are gone, and Ovok is round again. Now if I launch the game by clicking on KSP.x86_64 in a FileManager Window there are no issues with Sarnus or Ovok. It only happens when launching the game from the DeskTop Icon...weird huh?

You should have been watching spaceman_spff's LiveStream last night

I have to say, I feel the same way. Could we remove the rainbow rock and still enjoy the rest of the mod add-on?

lol what in God's name are you running to top over 10gigs!?!?! Every mod, ever? (I don't have tons, but I do run a lot of mods and I barely scratch 3gigs in Mint) I Found the AVP configs, and can confirm that your MM patch does indeed resolve the issue.

So you've gotten this new release to work?

I did notice that 1.5.5 does not have the gasgiants and tekto cfgs for BoulderCo any longer. I've tried every possible configuration and steps to get this new release to work but it won't

Thanks for the fast reply. I'm not sure what I'm doing wrong but I just can't seem to get things working now with the new release. I never installed KopernicusTech in the first place, only OPM. Then I added OP+...I've tried several combinations (including finding and installing KopernicusTech first) but I always end up with just the stock planets. Just adding OPM1.5.2 then OP+1.6 after that the first time worked and gave me all the extra planets and moons, but updgrading to this new release just isn't working the same. I'll keep trying though. (EDIT) I forgot, I did follow all the directions in post #689 with regards to AVP and getting this to work with 1.5.2....I'll start over with that I suppose and see how that goes.

"Installation note: If you're updating the mod, please do not overwrite the old version with the new one but delete it instead. This can prevent issues, as incompatible changes can be made between versions. A new save game for career mode is also recommended" So just delete the OPM folder or EVERYTHING in the release?

htop is great, thanks for that heads-up! 0 swapiness did not help, in fact things got worse. I checked things with htop and the only other thing running was dropbox...I don't use it that often so I killed it and went back to 10 swapiness. Things have run well (well enough) since then, and with only htop and KSP running (I use Cinnamon, never liked XFCE!) I'm topping out at around 2.8gigs used. One thing I forgot to mention but now that I think about it, could be significant is because I'm on a laptop with built in graphics I always had to tweak KSP.x86_64 to get re-entry effects to show. I've always used the little hack to edit the file and delete the intel.intel string. What I had been doing was finding three instances of that string and just entering zeros in their places. I thought maybe that was giving me issues so I started with a new file and only changed the very first instance of intel.intel and that by itself did give me the effects I always expect, so maybe changing those other strings adversely affected the known memory leaks? All in all, I'm now getting slightly better performance and with an hour or two of testing it seems that it's not trying to write non-stop to HD like it was before. I do have a smaller laptop HD I'm going to try a new linux install with and see how that works there. Maybe I will try XFCE (I do use it, but not on my main laptop, I have it on a real old laptop that I keep in my workshop for streaming pandora, I just don't like it's look) BTW, all these issues I've had with 0.90 are on a Lenovo G580 with 8gigs of ram, running Mint 17.1 with Cinnamon. Thanks for the help, I'll do more testing and whine about it here

I always got the high fan usage as well, but I can't explain the CPU (EDIT...HDD, not CPU!) activity with 0.90 I did however find something interesting that seemed to help a little. Swapiness. I started looking into the swap area and if that could have anything to do with it, although nothing about a linux install would explain why this only started with 0.90 for me. I found that by default on a scale of 0-100 linux is configured at 60 for 'swapiness'. So if 0 means linux would only access the swap in extreme cases and 100 would mean that linux would always use the swap area, by default it's set at a pretty high number. You can change this easily so I set mine down to 10. After that, the excess hard drive access while playing did go down, but it did not go away. I can never get 'system monitor' to stay running while playing the game, it always shuts itself off. But I did just try the 'free' command in a terminal while playing the game and my memory usage tops out over 7gigs used, and of course some stuff does still get put into swap, about another gig worth. I really don't have *that* many mods running, but for some reason KSP is using virtually all 8 gigs of RAM I have. It's better now that I changed the swapiness and tweaked some settings a little just in case they had anything to do with it, turned off anti-aliasing, turned down physics timing, etc etc....but all in all it's much more sluggish than it ever was before 0.90. I checked my new HD stats and it's the exact same speed and even has a bigger cache than the old one so I don't think it's the issue. I even thought maybe I screwed up the filesystem settings while installing Mint on the new HD but I'm using EXT4 for the filesystem, I'm pretty sure that's what I've used for all of my Mint installs over the years. I did make an extra large swap partition this time (16gigs) but the issues with 0.90 and hard drive usage started on the old hard drive with only an 8 gig partition. I'll keep looking and tweaking, I'm thinking of trying swapiness at 0 to see if that helps any, since I can always change it back

I'm downloading just to see what the Celestia flag is!

I haven't posted much or played much since 0.90. Right after installing 0.90 my laptops HD died, while playing the game. It went into non-stop HD activity and killed it. I got a new HD and reinstalled Mint 17 and now it seems that 0.90 constantly accesses the HD while playing, even locking up sometimes. Also sometimes after shutting the game down, the laptop is unresponsive for minutes while the HD cranks and cranks. I don't know what's up, or why 0.90 would cause so much HD accessing but it's really a bummer. Not to mention one HD died in the middle of the game trying to do whatever it was doing and now it's almost out of control with how much activity goes on.

In the meantime FWIW there has been a plugin for quite some time now that enables this by default: http://forum.kerbalspaceprogram.com/threads/80683-0-23-5-MapShowNavBall-show-navball-by-default

I tried it and I'm guessing that the real issue is those ships he's using. Both vessels auto-launched when I engaged auto-pilot, but I immediately reverted, loaded up several of my own designs and they did not. I even tried both of his vessels in my own save, as well as his persistant file. Same thing. Those two ships launch themselves without hitting spacebar, as soon as MJ's auto-pilot is activated, but those 2 are the only ones that do it for me. I doubt that MJ is the real problem here.

You could try editing the part cfg file, where it shows this: MODULE { name = MechJebCore MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = flightControl } MechJebModuleSmartASS { unlockTechs = flightControl } MechJebModuleManeuverPlanner { unlockTechs = advFlightControl } MechJebModuleNodeEditor { unlockTechs = advFlightControl } MechJebModuleTranslatron { unlockTechs = advFlightControl } MechJebModuleWarpHelper { unlockTechs = advFlightControl } MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl } MechJebModuleThrustWindow { unlockTechs = advFlightControl } MechJebModuleRCSBalancerWindow { unlockTechs = advFlightControl } MechJebModuleRoverWindow { unlockTechs = fieldScience } MechJebModuleAscentGuidance { unlockTechs = unmannedTech } MechJebModuleLandingGuidance { unlockTechs = unmannedTech } MechJebModuleSpaceplaneGuidance { unlockTechs = unmannedTech } MechJebModuleDockingGuidance { unlockTechs = advUnmanned } MechJebModuleRendezvousAutopilotWindow { unlockTechs = advUnmanned } MechJebModuleRendezvousGuidance { unlockTechs = advUnmanned } Change what you want enabled in unlockTechs = to start So MechJebModuleAscentGuidance { unlockTechs = start }

BOOM 1fps. Game didn't actually die, but it was totally unplayable. I was able to uncheck the 'display trajectories' box and it went back to normal again I tried again, this time with good old KerbalX and everything is nice and smooth. Must me something with that craft file of yours?

I did not try to compute trajectories going up, but I suspected that it was was causing the framerate drop before I switched to 1.1.0.0-pre. As for landing, while using MJ's landing function and targetting the KSC, Trajectories correctly predicted the true landing spot, while FAR and MJ kept thinking that the ship was still going to land at the Space Center. So trajectories had it right, but using Far with MechJeb alone, MJ can't correctly predict the effects that FAR has on entering the atmosphere. But using those 2 in conjunction with Trajectories, it's easy enough to make corrections to land where I want. (So yea, now that the framerate issues seem to be gone, it looks like Trajectories is working as intended for me, while MJ and FAR still need to learn to work together)