Thrombo

I may be totally off the mark here, but I don't think crashing with a full mod setup is unusual for the first load of either ATM or new mods. I know in my 1.0 install with ATM with the mods I'm using I crashed twice - just bring it back up and let it do its thing. Uncompressed textures are loaded into memory where ATM can perform the DXT compression and creation of texture cache - but obviously memory is a limited resource (esp with 32-bit build). Once it's out, it will crash on alloc - when you bring it back up, it won't have to do all the files it's already done and will pick up where it left off. After however-many loads it takes, everything will be nicely DXT-ified and good to go. I don't know if this is your issue, but if your mods were previously working without ATM, I would encourage you to try loading all your mods again with ATM and just let it crash a couple times on load.

Hey ddaf/nlight, Found a bug (I think). When I build a rover with AFBW installed, I can't go backwards. That is, when I hit the 'rover throttle back' key (as defined in the settings on main menu), it does nothing. When I release that key the rover drives forward. Holding the back key again sets the wheels to neutral. When in this state, if I tap rover throttle up the wheels will reset to neutral (zero throttle). Uninstalled AFBW and the problem went away. Just figured I'd let y'all know. Was infuriating for a long time for me until I figured out who the culprit was. Edit: rover controls in this case are on the keyboard, not the controller/joystick.

Yay! Glad you were able to find the issue so quickly. Looking forward to a fixed version! By then I'll probably have unlocked my *drumroll* Kerbodynes. Cheers!

I figured it shouldn't, but just wanted to make sure it was known that I don't yet have access to this part (it's experimental by virtue of the contract). I haven't seen anything like this before with such parts, though - just this one. Let me know if you need any other data or reproduction from my setup and I'll see what I can do.

Hey Diazo, pretty nifty mod. Couple things - it would be nice if it were possible to set the desired vertical velocity rate without spooling up the engines when the mod is turned on. Also, I got a contract to test the Kerbodyne KR-2L big engine on the launchpad, so I tossed a pod on with that engine, and upon launch got a kraken black screen. Some mod troubleshooting later (admittedly I use a lot of them) I removed vertical velocity controller and the problem went away. Here's the last output_log information I see before the output_log is spammed with "Look rotation viewing vector is zero" . . . NullReferenceException: Object reference not set to an instance of an object at VerticalVelocity.TWR1Data.FixedUpdate () [0x00000] in <filename unknown>:0 (Filename: Line: -1) 1/15/2015 5:37:04 PM,KerbalAlarmClock,Setting App Button True (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) 1/15/2015 5:37:04 PM,KerbalAlarmClock,Vessel Change from 'No Vessel' to 'Untitled Space Craft' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) 1/15/2015 5:37:04 PM,KSPAlternateResourcePanel,setting true (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) 1/15/2015 5:37:04 PM,KerbalAlarmClock,Contracts System Ready (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) NullReferenceException: Object reference not set to an instance of an object at VerticalVelocity.TWR1Data.FixedUpdate () [0x00000] in <filename unknown>:0 (Filename: Line: -1) NullReferenceException: Object reference not set to an instance of an object at VerticalVelocity.TWR1Data.FixedUpdate () [0x00000] in <filename unknown>:0 (Filename: Line: -1) Look rotation viewing vector is zero . . . Edit: This is with the CKAN-installed version (1.17a) on 0.90 32-bit KSP.

Sooo, booted up a game on hard (the money situation really makes things...interesting). I had been only accepting ground contracts (or ones that are relatively risk free) for some time. I previously had attempted to orbit without a gimballing engine (using FAR) and had to abort after an in-flight ...equipment malfunction, costing the program a great deal of its wealth and yielding very little. This time would be different, with the newly researched LV-T45. So, the engineers strung a couple fuel tanks on top, big 'ol booster below, some winglets for stability, and we were off to the races. Lift-off. Large SRB lifts the vehicle up ~1km before Jeb turns at a very slight angle to start some semblance of a gravity turn. Staging event. As the booster sails away, the vehicle loses a great deal of stability without the stabilizing winglets. Jeb finds himself tumbling through the atmosphere. Fortunately the vehicle was in thin-enough atmosphere not to fail catastrophically. Jeb regains control after some time. The decision is made that the fuel losses are acceptable, and the mission will proceed. Near apo, Jeb fires up the engine again for orbital insertion. And then it happens. The tanks are dry. But wait - a quick check reveals we may indeed be in orbit - even if Jeb is doomed. No. Periapsis of 69900. Jeb is furious. KSC is a flurry of activity as Gene yells for the Kerbal engineers to come up with a solution. They come back quickly. Jeb's EVA suit is loaded with monoprop. All eyes are on the sky as Jeb orients the craft prograde, dons his suit, and maneuvers to the rear of the vehicle. One hand on the rocket bell, the other on controls, Jeb activates his suit. Thirty seconds later, the craft Periapsis is checked - 72km. He's done it. Several experiments are done for a variety of manufacturers - the last being the firing of the experimental sepratron engines. The mission plan called for them to be fired after achieving orbit, but the lack of fuel necessitated their thrust be used to try to bring Jeb home. The sepratrons bring the Periapsis in to 56km. Jeb doesn't want to wait for the several-pass aerobrake, and gets out and pushes some more. The mission ends in a wild and resounding success, and Jeb returns home to Kerbin a hero.

Fixed my problems as well. Thanks for the quick patch!

Yep, understood. Not sure if the GUIContent is relevant or not. Else I suppose it's extraneous info. If you think it's collateral damage from ExLP I can try again with with AGX and w/o ExLP.

Bit of a strange issue, here - new in 0.25. Fair disclosure: I have a number of other mods running, some of which are out of date. When I try to launch from the VAB the button doesn't do anything. Looking at output_log I see: [...] [Pre-Flight Check]: All Checks Complete. Go for Launch! (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) Launching vessel from LaunchPad. Craft file: C:/Program Files (x86)/Steam/steamapps/common/Kerbal Space Program/KSP_Data/../saves/Ryan/Ships/VAB/Auto-Saved Ship.craft (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) AGX EditorSaveToFile called (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) AGX Editor Fail (SaveGroupNames) 7 System.NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXEditor.SaveGroupNames (System.String str) [0x00000] in <filename unknown>:0 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) AGExt No parts to save 17d System.NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXEditor.EditorSaveToNode () [0x00000] in <filename unknown>:0 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) AGX EditorSaveToFile FAIL 23 System.NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXEditor.EditorSaveToNode () [0x00000] in <filename unknown>:0 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) NullReferenceException: Object reference not set to an instance of an object at ActionGroupsExtended.AGXEditor.EditorWriteNodeToFile () [0x00000] in <filename unknown>:0 at ActionGroupsExtended.AGXEditor.EditorSaveToFile () [0x00000] in <filename unknown>:0 at ActionGroupsExtended.AGextScenarioEditor.OnSave (.ConfigNode node) [0x00000] in <filename unknown>:0 at ScenarioModule.Save (.ConfigNode node) [0x00000] in <filename unknown>:0 at ProtoScenarioModule..ctor (.ScenarioModule module) [0x00000] in <filename unknown>:0 at ScenarioRunner.GetUpdatedProtoModules () [0x00000] in <filename unknown>:0 at Game.Updated () [0x00000] in <filename unknown>:0 at GamePersistence.SaveGame (System.String saveFileName, System.String saveFolder, SaveMode saveMode) [0x00000] in <filename unknown>:0 at FlightDriver.StartWithNewLaunch (System.String fullFilePath, System.String missionFlagURL, System.String launchSiteName, .VesselCrewManifest manifest) [0x00000] in <filename unknown>:0 at EditorLogic.goForLaunch () [0x00000] in <filename unknown>:0 at EditorLogic.proceedWithVesselLaunch () [0x00000] in <filename unknown>:0 at PreFlightCheck.Complete () [0x00000] in <filename unknown>:0 at PreFlightCheck.runNextTest () [0x00000] in <filename unknown>:0 at PreFlightCheck.runNextTest () [0x00000] in <filename unknown>:0 at PreFlightCheck.runNextTest () [0x00000] in <filename unknown>:0 at PreFlightCheck.runNextTest () [0x00000] in <filename unknown>:0 at PreFlightCheck.runNextTest () [0x00000] in <filename unknown>:0 at PreFlightCheck.runNextTest () [0x00000] in <filename unknown>:0 at PreFlightCheck.runNextTest () [0x00000] in <filename unknown>:0 at PreFlightCheck.RunTests () [0x00000] in <filename unknown>:0 at EditorLogic.launchVessel () [0x00000] in <filename unknown>:0 When in the VAB idle, my output_log is spammed with: [...] NullReferenceException: Object reference not set to an instance of an object at ExLP.ExWorkshop.Update () [0x00000] in <filename unknown>:0 (Filename: Line: -1) GUIContent is null. Use GUIContent.none. (Filename: Line: 32) GUIContent is null. Use GUIContent.none. (Filename: Line: 32) NullReferenceException: Object reference not set to an instance of an object at ExLP.ExWorkshop.Update () [0x00000] in <filename unknown>:0 (Filename: Line: -1) GUIContent is null. Use GUIContent.none. (Filename: Line: 32) GUIContent is null. Use GUIContent.none. (Filename: Line: 32) NullReferenceException: Object reference not set to an instance of an object at ExLP.ExWorkshop.Update () [0x00000] in <filename unknown>:0 (Filename: Line: -1) GUIContent is null. Use GUIContent.none. The mod and textures seemed to load ok and AGext is up to date: AGExt Ver. 1.18 loaded

Hi all, curious if anybody has a good solution for this problem. I like to play with a lot of mods. Some of them I imagine to be very low memory usage (mostly computational) and some are higher (textures, textures, textures). Nothing irks me more than going on my merry way on a long mission, reaching the destination, and then loading the terrain, leading to a game crash. I am regularly around 3.3 GB memory util. after removing B9. I'd like to find which mods are the top culprits so I can decide what I really must have in the install. I do not want to go through the onerous process of loading one mod at a time. Any thoughts? Cheers!

Sounds suspiciously like an incompatibility with....gimbal autotrim: http://forum.kerbalspaceprogram.com/threads/77710-0-24-Gimbal-Auto-Trim-1-1-(Sept-2) From that post's OP: Haven't tried using both, but perhaps try uninstalling GAT?

Disclosure - I'm obviously late to the party, because I'm not aware of the 'great controversy' or who it drove away. I can see what you're saying, but doing this kind of work is a sizeable effort for any decently sized mod. I certainly may be mistaken, but I would find it hard to believe anybody using mods to play a game is going to comb through the source for everything they're using to look for "something suspicious". At the end of the day, you're letting a community member's untrusted code run on your machine - IMO if you don't trust the mod author, don't use the mod.

What's the difference having one 'central' mod to manage this or doing it individually? Having a central data collection/distribution mod isn't going to prevent mod authors from being able to do whatever they want to do, so what problem does this solve for the tinhats?

Many people (myself included) see HUGE FPS drops with OpenGL, despite the RAM savings. My game is virtually unplayable using OpenGL on a 4.6GHz Devils Canyon system with 2x 780ti cards in SLI.

Most of the gfx updates are from the KSPRC pack (Bill is a gentleman). There are some updates to the mods contained within that pack that I'm also using (smokescreen is one that comes to mind).