Jacke

The first post and thread subject line are still saying v2.6.2.0.

I have a rule with complex autopilot mods like MechJeb2. I always try to do the maneuver manually so I really understand what's going on. And then I start using the autopilot and see what it does and how I have to instruct it to get what I want. And I've been thinking and figuring about this sort of stuff since reading Von Braun's The Mars Project around 1980. You have a polar orbit space station. You have a launch vehicle sending up a new component. You first have to launch in the same plane as the station. You have to fly to bring your launch vehicle's orbit to the same inclination, 90 degrees (which means taking out the eastward velocity component from planet rotation). You need more delta-V for the polar orbit and you need more for the rendezvous maneuvers. From experience, I know MechJeb's Ascent Guidance often has problems pushing all the way to 90 degrees inclination soon enough and completely enough, so you probably have to add manual inputs to the autopilot to force it sooner, by watching the orbit parameter display. You want a slightly lower or higher orbit if you want to wait out a close pass, or a lot of extra delta-V. The way you're currently using MechJeb isn't working. You should trying following some of the advice here. You should also try just doing the launches differently and see what those differences do. That includes pulling other mods and building a new spacecraft to check to see if it's some weird mod interaction.

Sarbian could speak more knowledgeably to this, but he'd need a log file and perhaps more. You're have such strange errors I'm going to suggest a complete rebuild. It's a pain to do so, but it could remove some of the issues. A log file examination could narrow things down to avoid this. A complete rebuild means: 1. Wipe everything and get KSP back to stock. If you have it from Steam, wipe all files and ask Steam to download and verify the files after download. 2. Get all your mods in the most current versions. As well, skim the last few pages of the mods' threads to see what issues they may have. Then install them. 3. Start a new game. 4. Rebuild your spacecraft from scratch. Previous .craft files could have artifacts that can persist in causing problems even with everything else rebuilt.

Not sure about that, considering BTSM metamods DR. FC is still working on moving BTSM to KSP 0.90, so this is from KSP 0.25 & BTSM 1.64999. I found for DR 6.1 and 6.2, Kerbin polar orbit reentries weren't survivable. Going to 6.3 (and I imagine 6.4) solved that, but then the 1.25m heatshield worked at Kerbin escape speed reentries (3000m/s+) with apoapsis of 30km and a single-pass reentry, when it should have burned there and only survived on a multipass with an initial reentry somewhere around 48km.

Look here for the MJ Changes page for the devel versions. Lots of mods are changing a lot as they adapt to the massive changes in KSP 0.90. Click on the links on the left-hand side Build History to go to a page for a particular version to download it. Follow the thread here and the MechJeb2 Changes pages to see when new ones come out and for what reasons.

I put them with the mod they change, so for MechJeb, they go in the GameData/MechJeb2/ folder.

I normally only play with BTSM. That mods DR. Under that condition, I found with DR 6.1 and 6.2 I couldn't fly a Kerbin polar orbit mission as they always burned up. The 6.3 beta fixed that, but then it allowed the 1.25m heatshield to survive a 3500m/s Mun return reentry. Until FlowerChild, the author of BTSM, has another look at BTSM and DR when he gets to doing a KSP 0.90 version, with BTSM in KSP 0.25 I'm using DR 6.0.

Go to the 1st post and the download link. The file with the icon 'A' from 2014 July 21 is the Edge of Oblivion .zip.

Doesn't matter to a 32-bit process. It has a 4GB memory map and over 0.5 of that is used for special memory mapping. Somewhere between 3 and 3.5GB of memory use, 32-bit processes hit the limit.

What it will do is created a 2nd 'name' variable in the module and hid the 1st one. They'll have the same value. Minor issue but because 'name' is used to access the modules via MM scripts, it could cause issues.

MOARdV has recompiled the RPM .dll's for 0.90 and posted links to them in the RPM thread.

Thought it over and you need to use '%name' as well. @PART [*]:HAS[@MODULE[ModuleCommand]] { %MODULE {%name = MechJebCore} }

If you're including MechJeb's parts, that MM code will put a second MechJebCore module on them. Perhaps change it to this: @PART [*]:HAS[@MODULE[ModuleCommand]] { %MODULE[MechJebCore] {%name = MechJebCore} } So it only creates a new module if one doesn't already exist. EDIT: Thought it over and you need to use '%name' as well.

New dev release shows version number 2.4.0.0-361. Shouldn't that be 2.4.1.0-361 as a KSP 0.90 release, like the previous release 2.4.1.0-360?

v0.33 now only has Aerocam, Aerocam180, and KerbPro cameras. Was that intentional?

When I use -force-opengl, KSP crashes much more often than it does otherwise. Now with the lastest EVE and Astronomer's Interstellar pack, it's even worse, as only about 1 in 3 program starts gets to the main menu successfully. I don't think it's due to EVE or Astronomer's Interstellar pack, but on the off chance it is, and to get some help, I'd thought I'd ask. Here's an example output_log.txt. I see it go through the entire loading screen, then the process becomes unresponsive. Sometime later I see its memory crash from around 1600MB to a few hundred MB. I usually end up killing the process, but the rare time it has terminated itself. I see a few errors, but before the end of the file they appear to be survivable. Then a whole bunch of: make up the end. This example I killed the process.

No, do not haphazardly delete files. Once you have partless MechJeb working, you can then think about deleting the whole MechJeb2/Parts tree as you won't need them. I think it's time for you to clean up your GameData tree to reinstall all mods to make sure there's no cruft. 1. Remove all subdirectories under GameData except NASAmission and Squad. 2. Reinstall all mods with their current working version 3. Make sure ModuleManager's dll goes in GameData directly, not in a subdirectory. (It's how it makes sure it's started early to modify all it needs to.) 4. When you install MechJeb2, put my .cfg file in the MechJeb2 directory. 5. Start the game, make a rocket in the vab with a command pod without any MechJeb parts, and go to launch. You should have access to MechJeb.

As I found out from Astronomer in his thread on his lastest visual pack, for night-time city lights make sure you load a vessel. Load a vessel and then check for city lights.

Well, my game crashed out. Saw Astronomer final got Curse to accept his upload, so I downloaded Interstellar v2. Removed ATM Aggressive as it wasn't helping and appeared to be causing image artifacts. Installed v2 with 128MB Volumetric Clouds and other recommended choices. Ran that with "-force-opengl" and memory was under 1600MB. Previous image artifacts mentioned in my quote weren't present. Exited and decided to add Lightning and New Sun. Step 2 of New Sun is incomplete. From checking the config and other files, it appears whichever "detaileve2.jpg" you pick goes in "GameData/BoulderCo/Clouds/Textures/". And started okay! Thanks for crafting such an amazing visual improvement, Astronomer! EDIT: Didn't like the frantic nature of the lightning (is that realistic?), so decided to remove it. First tried using the Alt-N menu (which overlaps with the ingame Notepad mod), was very confusing, and when trying to "Reset to Default" many of the options, managed to turn off Lightning, Clouds, and Aurora. Exited out to reset config, remove Lightning, and try other Volumetric Clouds. Clouds are less thick over Kerbin compared to the May release which I'd been running up to now (with 1500 Clouds ). And as others have noted, no City Lights (but I did have them in the original Interstellar). EDIT2: And City Lights are back (yellow-green and orange-red). Don't know how.

When I installed Interstellar (x86), tried going without -force-opengl as I'd had more crashes in the past using it. Ended up using ATM Aggressive and the 128MB Volumetric Clouds--and a lot of runs to get all the textures compressed. After it finally launched without crashing, the sky was large blotches of red and white, Kerbin has a blotchy glowing sky both on the ground and from space, and Duna had a dark side with a blotchy glow. Removing the Skyboxes mod fixed them. To get rid of the unwanted blotchy glow, had to remove both Core Clouds and Lightning. Launched and looked okay, but memory was ~3500MB. So I went with launching that with -force-opengl to get memory down to under 1600MB. I too was wondering what the difference is between the 2 Sun options.

Here's a ModuleManager file to modify command pod parts to include a MechJebCore module as well as adjust the tech nodes that unlock the functions to be available at start. You just install the ModuleMananger dll and save the stuff below in a file "MMJ-MechJeb-ModuleCommand.cfg" and put it in the MechJeb2 directory. I don't use the MechJeb2 parts as they cause problems with BTSM. (Note: the RemoteTech code should work but has never been tested.) // MMJ-MechJeb-ModuleCommand.cfg // // ModuleManager coding by Jacke // // Include this file with mod MechJeb2 // // for MechJeb2 >= 2.1.1 // // add MechJeb2 functions to all ModuleCommand // // 2014 Feb 20 Thu MM coding by Jacke // 2014 Aug 30 Sat changed order of HAS tests // // where mod MechJeb2 // what MechJeb2 // file all ModuleCommand files // part all ModuleCommand parts // // Standard Command Modules // @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = start } // flightControl MechJebModuleSmartASS { unlockTechs = start } // flightControl MechJebModuleManeuverPlanner { unlockTechs = start } // advFlightControl MechJebModuleNodeEditor { unlockTechs = start } // advFlightControl MechJebModuleTranslatron { unlockTechs = start } // advFlightControl MechJebModuleWarpHelper { unlockTechs = start } // advFlightControl MechJebModuleAttitudeAdjustment { unlockTechs = start } // advFlightControl MechJebModuleThrustWindow { unlockTechs = start } // advFlightControl MechJebModuleRCSBalancerWindow { unlockTechs = start } // advFlightControl MechJebModuleRoverWindow { unlockTechs = start } // fieldScience MechJebModuleAscentGuidance { unlockTechs = start } // unmannedTech MechJebModuleLandingGuidance { unlockTechs = start } // unmannedTech MechJebModuleSpaceplaneGuidance { unlockTechs = start } // unmannedTech MechJebModuleDockingGuidance { unlockTechs = start } // avUnmannedTech MechJebModuleRendezvousAutopilotWindow { unlockTechs = start } // advUnmannedTech MechJebModuleRendezvousGuidance { unlockTechs = start } // advUnmannedTech } } } // // RT2 Probe Command Modules // @PART[*]:HAS[@MODULE[ModuleRemoteTechSPU],!MODULE[MechJebCore]]:Final { MODULE { name = MechJebCore MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = start } // flightControl MechJebModuleSmartASS { unlockTechs = start } // flightControl MechJebModuleManeuverPlanner { unlockTechs = start } // advFlightControl MechJebModuleNodeEditor { unlockTechs = start } // advFlightControl MechJebModuleTranslatron { unlockTechs = start } // advFlightControl MechJebModuleWarpHelper { unlockTechs = start } // advFlightControl MechJebModuleAttitudeAdjustment { unlockTechs = start } // advFlightControl MechJebModuleThrustWindow { unlockTechs = start } // advFlightControl MechJebModuleRCSBalancerWindow { unlockTechs = start } // advFlightControl MechJebModuleRoverWindow { unlockTechs = start } // fieldScience MechJebModuleAscentGuidance { unlockTechs = start } // unmannedTech MechJebModuleLandingGuidance { unlockTechs = start } // unmannedTech MechJebModuleSpaceplaneGuidance { unlockTechs = start } // unmannedTech MechJebModuleDockingGuidance { unlockTechs = start } // avUnmannedTech MechJebModuleRendezvousAutopilotWindow { unlockTechs = start } // advUnmannedTech MechJebModuleRendezvousGuidance { unlockTechs = start } // advUnmannedTech } } } // // END OF MMJ-MechJeb-ModuleCommand.cfg

Aviation Lights on both craft and Illuminators Mk 1 on the active craft help those darkness dockings. And then there's Ambient Light Adjustment as well.

Don't rant. Understand first. Aircraft and ships uses altitude in feet and ranges in nautical miles because that's the international convention that all nations, pilots, and traffic control work on. It will be the last use of non-metric units because it will be the hardest to change without mishap. Like what happened in World War 2 in the Pacific theatre when the United States Navy used nautical miles and the United States Army Air Force used statute miles. And U.S.A.A.F. aircraft were sent on a mission given data in nautical miles and compared that to their aircraft loaded radius of action in statute miles and thought it would work and it didn't and air crews died. Which lead to all air forces and then civilian pilots standardizing on nautical miles. Altitude in feet got included. All operating systems now can run in 64-bit mode. But a lot of the software is still 32-bit. Which is why all 64-bit operating systems have robust ways of running 32-bit code. I'm typing this post into the latest Firefox. Firefox on Windows is still 32-bit code, even though the OS is 64-bit, because that's the compiled versions supplied by Mozilla. Under Linux, Firefox can be 64-bit. And then I have other hoops to jump through because other stuff that runs in the browser is still 32-bit. My OS right now is Windows 8.1 64-bit. But I run the KSP 32-bit executable because under Windows Unity 64-bit and KSP 64-bit are full of bugs. Game-breaking bugs. Squad called Windows KSP 64-bit experimental and says it got worse in KSP 0.25. Just because you've run Windows KSP 64-bit without issue for a while doesn't change that. And doesn't change the fact that you will likely hit one of those bugs. And you add in the number of players who play any mod and they will have issues with KSP 64-bit. Which they demand the mod writer fix. Even though it's impossible. Because they don't know and don't care to figure out. And thus a lot of mod writers are sick of this crap and now have their mods refuse to run under Windows KSP 64-bit. Because it's experimental. That won't change until Windows KSP 64-bit improves.

Reentries with current DR are now more like real-life ones. A highly simplified calculation in an aerospace book I read showed that successful reentries start with an approach velocity less that 1 degree from horizontal. In KSP with DR 6.1+ I found reentries from both LKO and returning from Mun needed periapsis no lower than 30km or the craft burned up.