brainsalad

Seconded! Additionally, it would be nice if I could prevent control surfaces from dementedly flapping around like a wounded chicken when the craft is in vacuum.

That would be cool, thanks for replying. Sometimes Jeb likes to thrust around in space at 50g and I like to accommodate him.

Can the afterburner function be used reliably in space? For me, in vacuum, it seems to work only while the craft remains pointed in roughly the same direction it was flying while last in atmosphere.

Your post helped me resolve a stuck docking occurrence; thanks! My stuck docking situation: I have a base on Duna with docking ports on the side. These ports are provided for big rover trucks to back up against, not unlike a loading bay behind a store or factory. So, they're pretty high off the ground. I constructed a truck back on Kerbin. Not knowing the exact height of the Duna base docking ports, I equipped the truck with magic rams capable of raising it up a few meters. After dispatching this truck to Duna and backing it up against the base, the truck's massive scale became apparent. It's of ludicrous proportion; its docking port stands high above those of the diminutive base. So, I built an adapter with docking ports on both sides and sent it to Duna on a sky crane. I attached the adapter to the truck, detached the other end from the crane, and backed the truck up against the station such that the docking port previously attached to the crane now attached to the station. Kerbals flowed through the adapter tube like hyperactive gerbils, filling the truck and eager to finally tear across Duna in god's own $70 million stretch SUV. A crushing disappointment: the adapter docking port attached to the truck refused to release. Jeb pointed out that it does work to undock the station end and then the truck end, causing the adapter to fall into the red sand where it would forever remain. Alternatively, the adapter could remain attached like some deranged scorpion tale as the SUV careened about the austere Dunese landscape. DMagic's post showed me where to look. The srf file indicated that the adapter port docked against the truck listed its mate as being the sky crane, and the port on the truck attached to the adapter as undocked. Both had correct dockUIds, so it was a simple matter to fix the other fields and add DOCKEDVESSEL section to the truck's port. I loaded the modified srf and finally undocked the adapter from the truck. In the future, I'm going to put a remote command module on all such adapter parts so that they aren't inert. Hopefully it's just inert segments that cause stuck docking.

Romfarer, do you keep your code in a public repo (eg, github)? I'd love to use the latest code if it includes a fix for the Kerbin SOI bug (even if the latest code isn't very well tested)! Thanks much for all your awesome stuff in any case

Yes! Also, it's Methane, not Kethane!

Damn, I am having the same problem. Lazor system no longer functions properly after switching back to a ship outside of Kerbin SOI. Some log entries: [WRN 15:02:58.164] Kerbal Space Program - 0.21.1.276 (WindowsPlayer) Steam OS: Windows 7 Service Pack 1 (6.1.7601) 64bit CPU: Intel(R) Core(TM)2 Extreme CPU X9770 @ 3.20GHz (4) RAM: 8191 GPU: ATI FirePro V8800 (FireGL V) (2032MB) SM: 30 (Direct3D 9.0c [aticfx32.dll 8.17.10.1151]) Log started: Tue, Aug 06, 2013 14:42:04 ******** SNIP ******** [HighLogic]: =========================== Scene Change : From FLIGHT to FLIGHT ===================== [WRN 15:02:58.667] [Kethane] Saving settings [LOG 15:02:58.674] [PlanetariumCamera]: Focus: Sun [LOG 15:02:58.933] AddonLoader: Instantiating addon component 'MapOverlay' from assembly 'MMI_Kethane, Version=1.0.4953.23325, Culture=neutral, PublicKeyToken=null' [LOG 15:02:59.037] ------------------- initializing flight mode... ------------------ [LOG 15:02:59.042] Target vessel index: 13 vessel count: 14 [LOG 15:02:59.044] [FLIGHT GLOBALS]: Switching To Vessel Ultra Hawk VI ---------------------- [LOG 15:02:59.044] setting new dominant body: the Sun FlightGlobals.mainBody: the Sun [WRN 15:02:59.383] Part mumech.MJ2.AR202 cannot load module #4. It only has 4 modules defined [WRN 15:02:59.384] PartModule is null. [WRN 15:02:59.476] Part Romfarer.LazorSystem cannot load module #0. It only has 0 modules defined [WRN 15:02:59.477] PartModule is null. [LOG 15:02:59.557] ++++++ onFlightStateLoad ++++++ [LOG 15:02:59.558] Camera Mode: AUTO [LOG 15:02:59.588] stage manager resuming... [LOG 15:02:59.589] all systems started [EXC 15:02:59.658] IsolatedStorageException: Could not find file "D:\Games\Steam\steamapps\common\Kerbal Space Program\GameData\Kethane\Plugins\PluginData\MMI_Kethane\AlphaUnlitVertexColored.txt". [LOG 15:02:59.919] LazorSystem : RuntimeLogic : OnVesselChange() [LOG 15:02:59.920] [DestructionTracker: OnAwake Ultra Hawk VI] [LOG 15:02:59.921] [LazorGlobals: Added DestructionTracker to Ultra Hawk VI] [LOG 15:03:00.050] [II.overclockMainsail]: Activated (forced) [LOG 15:03:00.051] [II.overclockMainsail]: Activated (forced) [LOG 15:03:00.052] [II.overclockMainsail]: Activated (forced) [LOG 15:03:00.053] [II.overclockMainsail]: Activated (forced) [LOG 15:03:00.058] [RomfarerHSTWlaser]: Activated (forced) [LOG 15:03:00.061] [RomfarerHSTWlaser]: Activated (forced) [LOG 15:03:00.065] [RomfarerHSTWlaser]: Activated (forced) [LOG 15:03:00.068] [RomfarerHSTWlaser]: Activated (forced) [LOG 15:03:00.069] - -- --- FLIGHT START --- -- -Ultra Hawk VI [EXC 15:03:00.103] NullReferenceException: Object reference not set to an instance of an object [LOG 15:03:00.104] [PlanetariumCamera]: Focus: Ultra Hawk VI [LOG 15:03:00.419] ++++++ onFlightStateSave ++++++ [LOG 15:03:00.425] Flight State Captured [LOG 15:03:00.426] Saving Achievements Tree... [LOG 15:03:00.427] Saving Achievements Tree... [LOG 15:03:00.428] Saving Achievements Tree... [LOG 15:03:00.428] Saving Achievements Tree... [LOG 15:03:00.429] Saving Achievements Tree... [LOG 15:03:00.430] Saving Achievements Tree... [LOG 15:03:00.430] Saving Achievements Tree... [LOG 15:03:00.431] Saving Achievements Tree... [LOG 15:03:00.432] Saving Achievements Tree... [LOG 15:03:00.432] Saving Achievements Tree... [LOG 15:03:00.433] Saving Achievements Tree... [LOG 15:03:00.460] Game State Saved as persistent [EXC 15:03:00.489] NullReferenceException: Object reference not set to an instance of an object [EXC 15:03:00.494] NullReferenceException: Object reference not set to an instance of an object [EXC 15:03:00.551] NullReferenceException: Object reference not set to an instance of an object [EXC 15:03:00.556] NullReferenceException: Object reference not set to an instance of an object [EXC 15:03:00.595] NullReferenceException: Object reference not set to an instance of an object [EXC 15:03:00.599] NullReferenceException: Object reference not set to an instance of an object [EXC 15:03:00.628] NullReferenceException: Object reference not set to an instance of an object

My day job is to handle nasty performance bottlenecks where I can put my CS education and research experience to use. I typically do four things: *Replace hot spots written in java/c#/perl/python with little bits of c/c++ structured carefully for auto-vectorization. *Recognize instances where routines boil down to algorithms doing things in big-O exponential ways that can be done in logarithmic time. These are typically problems that reduce to graph search, max flow, binary search, and sometimes your typical linear algebra problems where LAPACK can be dropped in and do it 100x faster. *Divide execution in the simplest manner possible into multiple threads. *Implement any image processing, video processing, procedural texturing, or anything else possible without heroic effort in OpenCL. This is often quite difficult, but can yield 1,000x speedups. KSP sounds like a typical complex game project where an experienced performance person could make big improvements without exploding code complexity in ways that more straightforward approaches (multithread everything!) would. The very best way to do it is include such a person early in the design process, but even a big nasty ball of interdependent, non thread safe code can be sped up in ways that surprise the original authors. Alternatively, a company can make the first version without regard to performance to see if there's a market, and then do version 2 with an eye towards performance from the get go. This isn't a bad idea at all