Tarheel1999

If what you are trying to accomplish is for mymod not to run certain patches in the presence of mod2 you would use a NEEDS. Something like NEEDS[!mod2]. If you don't want mod2 to overwrite your patches it would be AFTER[mod2]. Otherwise, I'm not sure what you are looking for.

I use Throttle Controlled Avionics because balancing and keeping that balance for a VTOL that ferries resources is no longer enjoyable to me. Flying them is challenging enough. FYI you can also adjust the thrust of your engines to make up for any weight difference. Edit - I also use TAC to keep the fuel/resources balanced.

stock KSP bug. See the stickied post in Addon Releases - Stock Bug Fixes.

You can adjust the amount of monoprop or add additional parts to the front or back to balance it out. Sometimes all you need is a pair of strategically placed RTGs to balance the ship. RCSBuildAid is your friend.

i think that is highly unlikely. If KSP really isn't generating a outputlog, your install is borked and should be fixed with a new clean install. More than likely you are looking in the wrong place. From the stickied post in the Support thread: When KSP crashes it will general a folder with files with details surrounding the crash. Usually a window will pop up ingame asking you to send this information to the developers, along with the name of the folder. You can find this folder in the KSP install directory. If KSP doesn't crash, start KSP and cause the problem. Quit KSP and find the output_log.txt (not the KSP.log) at the location below: Windows: KSP_win\KSP_Data\output_log.txt -OR- KSP_win64\KSP_x64_DATA\output_log.txt (depending on which used) - In case you installed KSP into a Windows protected directory (C:\Users, C:\Program Files or C:\Windows\ and their subfolders) the output log file may be stored in the folder called C:\Users\[username]\Appdata, this folder is usually hidden so you should enable the view hidden folders option (more information). Note that for the demo you should find the output_log.txt file located in the KSP_Data folder. - Steam users should right click KSP in Steam, click on Properties, then in the Properties box, click Local Files, then Browse Local Files. Mac OSX: Open Console, on the left side of the window there is a menu that says 'files'. Scroll down the list and find the Unity drop down, under Unity there will be Player.log Aka Files>~/Library/Logs>Unity>Player.log Linux: The log is written to /home/user/.config/unity3d/Squad/Kerbal Space Program/Player.log You can upload these files to any file sharing site (such as Dropbox, Mediafire or File2web). These sites will give you a link you can include in your posts to share your files. The output and crash logs are useful because they help us understand exactly what you were doing when the issue happened by providing a "play-by-play reenactment" (in text form) of your KSP session. Anything out of the ordinary will often show up in the log files, and it gives us a good idea of where to start looking for solutions.

You don't need to screen cap it, it's in your outputlog.txt. Search for nullnef and you'll find it. I'm running Dev 405, ATM, Exception detector, and regularly check my logs and I don't get the exception you are talking about. For Sarbian or other posters to help you need to post your outputlog.

Accurate. This change prevents the small track from throwing exceptions. - - - Updated - - - All of that is completely irrelevant if you were already riding the ragged edge. Looking at your logs you are running some RAM expensive mods. And it looks like you are loading both Squads and Ven's Models. Monitor your RAM usage during load with the Taskmanager or Sarbian's mod GCMonitor.

Impossible to say with the information you've provided. Memory is always a problem with KSP (due to memory leaks and the 3.5Gb limit) unless you are using Linux. You should look in the support thread for both how to request support and to answer some of your basic questions. Bottom line, you've either hit your memory cap or installed something incorrectly.

Yes, TAC-LS adds a part test module to most crewed parts. You can prevent those contracts from coming up deleting the appropriate MM patch from TAC-LS. I think the name of the config is similar to "AddPartTest". However, I'm not sure the MM patch has anything to do with the imbalanced nature of the contracts. I think that might just be stock wackiness.

Yes MKS provides the ability to both create and transfer spare parts with custom code. But I was not referring to MKS but to other mods that use NO_FLOW resources.

UPDATE - I resolved the exceptions by deleting the folders and re downloading from your Github. I initially downloaded the updates from KerbalStuff and merged the folders with my existing ones. I don't know if the problem was caused by the KerbalStuff download or merging the folders. However it looks like your config files may have changed. If so it would explain why the dll did not auto-generate a new config file if one using the old format still existed. Malah - Just installed the current version and its throwing the following exception every time the editor loads (VAB or SPH). It looks like the exception, or cause of it, is preventing the Toolbar icons from loading in the Stock Toolbar or Blizzy's toolbar. (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) ArgumentException: The requested value 'left shift' was not found. at System.Enum.Parse (System.Type enumType, System.String value, Boolean ignoreCase) [0x00000] in <filename unknown>:0 at System.Enum.Parse (System.Type enumType, System.String value) [0x00000] in <filename unknown>:0 at ConfigNode.ParseEnum (System.Type enumType, System.String vectorString) [0x00000] in <filename unknown>:0 at ConfigNode.ReadValue (System.Type fieldType, System.String value) [0x00000] in <filename unknown>:0 at ConfigNode.ReadObject (System.Object obj, .ConfigNode node) [0x00000] in <filename unknown>:0 at ConfigNode.LoadObjectFromConfig (System.Object obj, .ConfigNode node, Int32 pass, Boolean removeAfterUse) [0x00000] in <filename unknown>:0 at ConfigNode.LoadObjectFromConfig (System.Object obj, .ConfigNode node) [0x00000] in <filename unknown>:0 at QuickScroll.QSettings.Load () [0x00000] in <filename unknown>:0 at QuickScroll.QuickScroll.Start () [0x00000] in <filename unknown>:0 (Filename: Line: -1) - - - Updated - - - QuickContracts appears to be throwing a similar exception on scene changes. This was thrown on loading, entering the VAB, and exiting the VAB. ArgumentException: The requested value 'x' was not found. at System.Enum.Parse (System.Type enumType, System.String value, Boolean ignoreCase) [0x00000] in <filename unknown>:0 at System.Enum.Parse (System.Type enumType, System.String value) [0x00000] in <filename unknown>:0 at ConfigNode.ParseEnum (System.Type enumType, System.String vectorString) [0x00000] in <filename unknown>:0 at ConfigNode.ReadValue (System.Type fieldType, System.String value) [0x00000] in <filename unknown>:0 at ConfigNode.ReadObject (System.Object obj, .ConfigNode node) [0x00000] in <filename unknown>:0 at ConfigNode.LoadObjectFromConfig (System.Object obj, .ConfigNode node, Int32 pass, Boolean removeAfterUse) [0x00000] in <filename unknown>:0 at ConfigNode.LoadObjectFromConfig (System.Object obj, .ConfigNode node) [0x00000] in <filename unknown>:0 at QuickContracts.QSettings.Load () [0x00000] in <filename unknown>:0 at QuickContracts.QuickContracts.Start () [0x00000] in <filename unknown>:0 (Filename: Line: -1)

Was just about to report this. The config edit did fix the Small Track from throwing exceptions. Thanks! FYI, it appears you dropped the TrackSmall part config in WheelSmall rather than TrackSmall. So the part config for TrackSmall should still need to be updated.

Enriched Uranium is a NO_FLOW resource like Spare Parts. EPL charges you Rocket Parts for the mass of NO_FLOW resources. To do otherwise may create incompatibilities with mods that use NO_FLOW resources but do not have any mechanism for transferring NO_FLOW resources. For example, I have not used DangIt but I think you are stuck with the amount of spare parts you launch with. Even were that not true, I imagine there are or will be mods that NO_FLOW is equivalent to no transfer. FWIW, in my opinion it is not worth excluding players of mods with NO_FLOW resources without a means of transferring those resources from using EPL to build crafts to cater to a certain play style or to prevent any potential exploitation of this functionality.

Very cool. Thanks. Before you push the release could you take a look at the pad drop down in the GUI. When I have multiple pads (survey stations usually) and use the drop down to select a pad it throws an exception and the drop down doesn't collapse properly. I'll post an output log with the error as soon as I get a chance.

Okay I was able to reproduce with a very simple build. In the SPH start with a girder and add a MK1 lander can to the front. Re-root to the lander can. When I built the re-rooted craft on the runway with an origin stake placed directly in front of my survey station. The craft loaded to the North and West about 25 - 40 meters away from the stake at a 45 degree angle about 10 meters in the air. When I built a separate craft with the original root as the lander can but otherwise identical it spawned right on top of the origin stake in the correct orientation.* So this is either a re-root issue or a re-root plus SPH issue. *I've noticed that for EPL the door in the SPH is North (Z+) as opposed to being East as one might expect based on how crafts load on the runway.

When I get a chance (probably this weekend) I'll reduce the craft to basics and see if I can reproduce it. For now here is what the rover consisted of: A girder, a USI AES pod on the front, two cubics on the side of the girder with KF tracks attached, an RTG connected inside the girder, a KAS mount and container on top and a USI cats paw (.625 ARM claw) tilted on the back. I started the build with the girder but rerouted to the AES pod during the build. I used the rotation tool on the mini arm Claw during the build but reset the rotation using the space bar and tilted it manually. TLDR - The original root was the girder, the rerooted part was the AES pod (in the same orientation as the girder), I used the rotation tool during the build but reset the part using the space bar. I'll see if I can reproduce the problem with a fresh build and report back.

Sorted out my EPL problem. Ended up being a conflict with KSP's select root feature. Should have known, when in doubt consider stock wackiness first. Not sure what 's causing the exceptions with the small tracks though.

I tried with 3 stakes and no change. I also tried a bunch of things without luck until I decided to build a simple test craft with KF wheels. That worked. Then it occured to me that I used KSP's select root while building the rover. I rebuilt the rover and it spawned fine. So it was properly a mixture of EPL frame calculations and general KSP nuttiness. Here are some pics of my new Survey Stake rover. It has a KAS Container so I don't have to wonder around the base looking for stakes or pipes and a mini-claw to attach to the base to minimize base jumping and allow to me to tranfer a kerbal directly to the cab. In the first image, the rover is falling from the skies while I figure out the problem. Sorry for the dreaded night images.

Will do next time I load up KSP.

I'm having problems building rovers with Kerbal Foundries wheels/tracks on the Mun. When I finalize the build the vessel spawns at a 45 degree angle 10-20 meters in the air far from the survey stake. I used a single bounds stake set to X+. I tested the same stake with a vessel containing stock wheels and it spawned as expected. I tried using two origin stakes,;two origin stakes and a X+ bounds; one origin stake with a X+ bounds; and X+ bounds with a Y- Bounds. I also tried attaching a launch clamp to the vessel with similar results. I've tested several vessels with KF wheels/tracks and they all spawn in the same location/height. I tested building on Kerbin and the vessel spawned in the expected location at the expected height. Here's the log from an unsuccessful build. The explosions are from a heavy rover dropping on the base and causing things to go boom. https://www.dropbox.com/s/g1q6vhzm9q7sfvl/KF%20No%20Exceptions%20EPL%20Explosion.txt?dl=0. I'm not sure there is a fix for this but am posting in case I missed something in the log.

Here you go. https://www.dropbox.com/s/hcjpyowlvrgread/KF%20Exceptions.txt?dl=0 Your post made me a little paranoid so I did some additional testing. A girder and the small track is all that I need to produce the exception I excerpted in my earlier post. I tried several of the other tracks and wheels and was unable to produce the exception with just a girder and KF part. In the linked output log I did three different things. 1) I launched a girder and small track on the runway and reproduced the exception. 2) I loaded the service vehicle on the runway which has two small tracks attached and reproduced the error. 3) I loaded my Mun Base and built the service vehicle with EPL. It spawned in the air and dropped on my base. I also did more testing building vessels with KF wheels/tracks with EPL. There is definitely an incompatibility between the two (or another installed mod I guess) but I'm no longer sure there is a link between the exceptions thrown by the small track and the weird spawning. As noted above the exceptions seem limited to the small track and I also had problems with vessels built with KF wheels. I was, however, able to build a vessel on Kerbin with KF parts using EPL without incident. My best guess is that when building vessels on the Mun something (KSP, EPL, etc) gets very confused about the ground location or vessel bounding box when using KF wheels/tracks. This might go to the core of how KF works (repulsors and all) and am not looking for a fix. As a control, I built a rover using stock wheels on the Mun and was successful. TLDR Small tracks are consistently throwing exceptions on load however those exceptions are unlikely causing the EPL/KF weirdness I'm experiencing. For completeness sake here's a log following a EPL build on the Mun of a vessel with KF wheels. https://www.dropbox.com/s/g1q6vhzm9q7sfvl/KF%20No%20Exceptions%20EPL%20Explosion.txt?dl=0 Thanks again for creating a truly great mod.

That's how I understood it (the view where you select buildings).

That probably means you have TWO parts capable of building crafts. In my game, I have a base with both a USI Honey Badger command module and a MKS Colony Control Center. Both have the ability to act as EPL survey stations. In my EPL GUI, I have two pads listed to represent each survey station. It sounds like your Pad 0 is a survey station and Pad 1 is a launch pad or something similar. have you tried clicking on the drop drown menu to select pad1? - - - Updated - - - Survey stations can't be renamed right?

No problem. Will post one later today. That snippet is actually what happens every time I launch a vehicle to the runway with KF wheels or tracks.

lo-fi thanks for creating an awesome mod. I've had lots of fun designing and driving rovers recently. Which is saying something as I've generally avoided rovers in my year+ of playing KSP as I really dislike the stock wheels. Now, I know you've taken a step back from developing this mod for various reasons which I completely understand but (and you knew this was coming) I have a hopefully small request. As has been commented in this thread before, Kerbal Foundries will throw the odd exception from time to time when you load a vehicle with KF wheels or tracks. You know... NullReferenceException: Object reference not set to an instance of an object at KerbalFoundries.KFWheel+<TrackedWheel>d__3.MoveNext () [0x00000] in <filename unknown>:0 UnityEngine.MonoBehaviour:StartCoroutine(String, Object) UnityEngine.MonoBehaviour:StartCoroutine(String) KerbalFoundries.KFWheel:OnStart(StartState) Part:ModulesOnStart() :MoveNext() Now tooling around Kerbin this doesn't cause any problems. So no harm no foul. But the exceptions bork Extraplanetary Launchpads when you try and build an awesome tracked maintenance vehicle to service your Mun base. You see when you use EPL to build a craft with Kerbal Foundries wheels or tracks the vessel spawns in the air usually above something that likes to go boom when a heavy vehicle drops on it. Now granted the results of this are quite fun to watch as bits and pieces of your base go flying everywhere and never the same place twice. That said I would really like to use the maintenance vehicle and flying it to the Mun is so passe. So with the full understanding that these things are expected in a beta and if it's not a huge bother, I and my kerbals in the parts that like to go boom would greatly appreciate it if Kerbal Foundries could catch the exception before it is thrown. Obviously, I'll understand and still love your mod if this is actually a heavy lift or your're otherwise unable to address this. If you're wondering I've tried multiple rovers with both wheels and tracks and the same thing happens. I've also tried building the vehicles with only the wheels/tracks removed and they spawn on the ground in the expected location. Which is why I think the exceptions are what are causing the vehicle to spawn in the air. BTW, I'm using the dll from 1.8e. Thanks for the mod and taking the time to read this rambling request.