Bearfight

Installing with CKAN Express or the Advanced instructions will still provide you with a slightly borked install. As the dev notes suggest, this truly is an IQ test and only the few will end up with a clean ksp.log. I've noticed a pattern on these forums, where people asking for help will be told "it's not my mod because you have ADDON BINDER errors - and you need to resolve those first. At this point most people will likely give up - because those errors are common due to the poor source maintenance state of a few very common and otherwise great mods. So, with that in mind: I've been able to eliminate every "ADDON BINDER: Cannot resolve assembly" error in my RP-1 log by directory sorting. The alternative would be to pull the source for each offending mod, add these dependencies to AssemblyInfo.cs and recompile - like the mod maintainers should have done A THOUSAND YEARS AGO - and I'm not doing their work for them. That information is out there - it's basic mod maintenance at this point. Any maintainer not doing it simply isn't paying attention. These are the files to prefix (the license and readme files don't NEED to be prefixed, I just did it for consistency). You may not have all these files if you didn't go beyond the express install. That's fine, just rename the ones you have. Also, since we aren't using RemoteTech, in favor of RealAntennas, lets disable Contract Configurator's RT assembly. One less log error to look at. Now, you should be able to present your KSP.log file and ask for help without encountering the "not my problem" gatekeeper right away. In other news, I'm on to tackle this RealAntennas NRE. Not encouraging when the very first thing your mod does is throw an exception, before the main menu has even loaded. Unless someone can tell me otherwise, it seems to be serious - as it involves the VesselModule and OnDestroy behavior. [LOG 17:37:43.769] VesselModules: Found VesselModule of type RACommNetVessel with order 999 [EXC 17:37:43.774] NullReferenceException: Object reference not set to an instance of an object RealAntennas.RACommNetVessel.OnDestroy () (at <bcc06e73d2f64d0e87ff02a1c80277a3>:0) UnityEngine.Object:DestroyImmediate(Object) <>c:<CompileModules>b__4_0(Type) LoadedAssembly:TypeOperation(Action`1) LoadedAssembyList:TypeOperation(Action`1) VesselModuleManager:CompileModules() <LoadObjects>d__88:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) <CreateDatabase>d__69:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) GameDatabase:StartLoad() <LoadSystems>d__11:MoveNext() UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) LoadingScreen:Start()

Quick update to my last post - I fired up git and vs - looked into the PID module's code and learned that I have much more to learn. No quick fixes coming from PID controller source code tweaks, of course. Now that I'm a bit more educated - just enough to be dangerous I think - I don't have much trouble tuning out an oscillation. Still, I wanted to know more so I looked into the Atmosphere Autopilot (AA) source & docs and learned about its modular "autopilots" concept. Fly-By-Wire, Cruise, Controller and Mouse Director are the three "autopilots" provided out of the box with AA but it's designed; intended I think actually- to take on additional modules. My ultimate goal would be to port Kramax's waypoint-based ILS functions into an Atmosphere Autopilot module. If I understand the concepts correctly, that should give us the best of all worlds. The realtime waypoint-based ILS nav data of Kramax being acted on by the variable, self-tuning, flight controller suite that underpins AA. No idea what that would take, logistically, just yet - more learning ahead. Having a clear goal makes learning things easier - or at least more fun, IMHO.

Scalar is the first thing to fiddle with if an oscillation is occuring due to aggressive control inputs - think of it like moderation. I've been building various vehicles in Stormworks over the last couple years, which utilizes PIDs heavily in more advanced builds. I've gotten okay at fiddling with the values. Armed with this knowledge - I was delighted to find PIDs everywhere, including KSP! KRAMAX and Atmosphere Autopilot are the two prime examples I am familiar with. When I dig into the PID values in KRAMAX, some are a little aggressive by default. I tend to reduce the integral and differential on the outer loop down close to zero, if not zero, and it often tunes out pesky oscillations. I will agree that Atmosphere Autopilot is a much better program in terms of "set it and forget it" flying - in most cases it tunes itself - rather brilliantly. I almost never leave a runway before tapping "P". As a current keyboard pilot - its the best way to simulate a steady, analog stick rotation, so the plane leaves the runway poised and not flapping around from keyboard or SAS control. My current solution for ILS flights - use BOTH. When flying long airliner routes: I have AA Fly-By-Wire active, I use KRAMAX for ILS and most of the time I have warp set to 4x. AA seems to be able to moderate the KRAMAX inputs, in most cases. (For the autopilots to work well at warp, I use BetterTimeWarp to enable hyper warp and lossless physics warp - and set the CPU value to 1. Most modern gaming PCs can ignore the warning about CPU lag, it was written when even the best processors on the market would have choked. I am running an i9-10900K and have zero lag issues when using lossless physics warp, in or out of atmosphere.) I will say this... KRAMAX seems to have a tendency to oscillate along the pitch axis more so than yaw or roll. I have no logged data to back this up - its purely subjective right now. I planned on spending the day messing with my airliners (I'm on a Kerbinside GAP Remastered Kick ). Perhaps I'll do some logging and map the interactions between KRAMAX and AA FBW. I notice that a good PID setting for KRAMAX at 1x warp may become an oscillation at 4x warp too - I'll see if I can get any data on that as well. No promises but maybe I can shine a light somewhere helpful.

I'm having the same problem. Seems like the hidden button identifiers are getting doubled up at times. I haven't had the energy to put together the logs and open an issue on github yet. I like to try and poke around myself a bit first, considering lgg has so many mods to support. It's a very similar problem to an issue that's still open from 2017. I'll try and drive into it this week.

I can vouch that, on Windows at least, a very modded KSP needs a very large, unrestricted pagefile - or two. I realized at some point that a lot of my KSP crashes were, in fact, low virtual memory conditions. I set both of my pagefiles back to "system managed" and haven't had a memory-related crash since. (As a systems admin it was always just second nature for me to limit how much drive space the OS can steal on a moment's notice but - KSP is NOT OKAY with that! ) For spec reference, I have 24GB RAM - and HAD two 4-8GB virtual memory files spread out across a NVMe and another, standard SSD. That was fine - until my modlist approached the 200 mark. No other program that I run consumes as much virtual memory. Maybe an outlier, like myself, who manually manages their pagefile will see this and have a light bulb moment. Computers are complicated. Life is hard.

No worries, friend. Was just reporting and thanking... not rushing. Hopefully my fix makes one less thing you need to worry about. Be well!

Bump to second removing the effect for walking Kerbals. I also experienced the landing screech sound playing over and over after my rover got a little air on a jump. The rover hopped into the air just a bit when climbing the runway apron at KSC. The sound played, then kept playing as I drove forward. Coming to a complete stop and starting forward again made the sound stop. It was a few sessions ago so, no log unfortunately. If it happens again I'll grab the log. Thanks for your work on the mod. Edit: TL;DR - I was able to fix the Kerbal EVA sparks issue. Solution follows. Pull request sent. I decided to do a little digging when I noticed that you already had an exemption for KerbalEVA in the settings file. That prompted me to search my ModuleManager.ConfigCache file to see if those settings were being applied. Over the course of that expedition, I found the following. There are four KerbalEVA "parts" with incorrect CollisionFX module parameters: GameData/SquadExpansion/Serenity/Parts/Prebuilt/KerbalEVA.cfg GameData/SquadExpansion/Serenity/Parts/Prebuilt/KerbalEVAfemale.cfg GameData/SquadExpansion/Serenity/Parts/Prebuilt/KerbalEVAfemaleVintage.cfg GameData/SquadExpansion/Serenity/Parts/Prebuilt/KerbalEVAVintage.cfg The code in question is: MODULE { name = CollisionFX scrapeSparks = true collisionSound = CollisionFXReUpdated/Sounds/Bang1 scrapeSound = CollisionFXReUpdated/Sounds/GroundSkid sparkSound = CollisionFXReUpdated/Sounds/SparkSqueal } It should be: MODULE { name = CollisionFX scrapeSparks = false collisionSound = CollisionFXReUpdated/Sounds/Oof } I also noted that the other parts using the KerbalEVA module had no CollisionFX module parameters at all. So, in an attempt to correct both situations, I added the following code to GameData\CollisionFXReUpdated\ModuleManager_CollisionFX.cfg: @PART[*]:HAS[@MODULE[KerbalEVA]] { MODULE { name = CollisionFX scrapeSparks = false collisionSound = CollisionFXReUpdated/Sounds/Oof } } It works. I no longer have firey Kerbalian moon boots. I tested using the same save I've been playing with all week. It definitely included fire boots prior to this change and it definitely does not, after. The GitHub repo for this isn't exactly a repo... just a zip file containing both the source and built files. I did not want to set up a repo so the best I could do was to fork it, fix the source and prebuilt files in the zip, and then upload the fixed zip compilation. I put in a pull request to the official repo. Recommend setting up a proper GitHub when possible to make collaboration easier and changes more transparent. Until the pull is tested and approved, anyone wishing to try the new, no fire boots version can simply modify their ModuleManager_CollisionFX.cfg file per the code above or download an UNOFFICIAL copy of the mod from my fork at the link below. CollisionFX-ReUpdated UNOFFICIAL (Fix For Kerbal EVA Sparks) P.S. It's worth noting I still do not hear the "Oof" sound when a Kerbal collides with something. I'm not really missing it so, I'll leave that fix for another intrepid community member. Cheers!

Thanks for the frames! I just switched from Astronomer's after using it religiously for years. Nice work. Wanted to send a PM but, I haven't posted enough times lol... I think you mean to say "ultimate visual pack". An ultimatum would be like telling us we have to use your visual pack, "or else". It's a great visual pack; there's no need to make threats! Thanks for your work, looking forward the future releases.

Note to the moderator: I'm unsure if this is the proper forum. I looked around and it seemed best suited for this category. If you feel it belongs elsewhere, please move it with my blessing. Once the post is approved and has found it's proper home, feel free to remove all text with strikethrough. Or I'll edit later myself... whichever is more appropriate. Thanks for your work! My first post! Glad to be here. I've been a KSP player on-and-off since Early-Access. Amazing, how far it has come! I love the mods available... so much so that I often install too many or take a risk on outdated builds. Then, kablooey! KSP does something crazy or dies. That's when I need to figure out which mods are working properly, which one's can be patched by yours truly, which ones should get a bug report and which ones to remove entirely. I hope my method can help others quickly do the same. GL/HF/DIY! WHAT IS THIS FOR? This may be helpful if you are a DIY-minded soul and your game is crashing or acting strange and you want to try and identify which mod is causing it. For the proactive among us, this is even better for making sure all your mods' assemblies, classes, etc are properly loading and interacting with KSP... before you run into some unforeseen, mod-related "thing" 30 minutes into a mission. WHY NOT JUST LOOK AT THE CONSOLE? Of course, the quickest way to check for errors when they occur is to Alt-F12 into the console and read the latest entries. That doesn't always give you the full picture, though (and it certainly won't work is KSP has crashed). For that, you need to open up the infamous ksp.log file, located in your KSP base folder, to look for errors, warnings and surrounding information. Ksp.log is a standard-ish Unity log file; full of cryptic data that can nail down a point of failure such as a troublesome mod or a corrupt game file. WHY IS THIS BETTER THAN LOOKING AT KSP.LOG THE NORMAL WAY? Parsing a lengthy, black and white text file is not easy for most folks. So, I offer this quick tutorial on using AnalysePlugin to get at the relevent bits. A process i use at work as a devops engineer, analyzing all kinds of logs, to great effect. Like many application log files, within ksp.log you'll find irrelevant, deprecated entries and crucial data all are mixed up into one hot mess. Mining the log for the relevant bits can help you identify a troubled mod and get back to playing your game now, rather than guessing at which mod to remove or waiting hours or days for someone on the forum to analyse your ksp.log for you. This method helps you get to the relevant information within ksp.log quickly. With a little practice, this will also help you make more effective bug reports to mod developers here and on github. You'll be able to help them help you by pointing out relevant log entries, to assist them in debugging your issue (along with uploading a full ksp.log file as an attachment, of course!). OK, I'M SOLD! HOW DO I SET THIS UP? Download and install Notepad++ (NPP). If you already have it, great. (optional step: forget your default text editor ever existed ) https://notepad-plus-plus.org/download Once you have NPP installed, open 'er up and go to the "Plugins" drop-down menu, directly to the left of the "Window" menu, at the top of the application. You should see an entry in the Plugins drop-down called "Plugin Manager". If it's there, move to step 3. If not, get it here: https://github.com/bruderstein/nppPluginManager, install plugin manager and restart NPP. From the Plugins menu, open Plugin Manager and make sure it can access the Internet, so it can update the repository. After the repo has been downloaded, check the "Available" tab for "AnalysePlugin". This plugin will allow us to use a simple set of parameters to highlight and group the errors and warnings in ksp.log, making the job of finding problems much easier on the eyes and brain. Check the box next to AnalysePlugin and click Install. Restart Notepad++. Now, open your ksp.log file in Notepad++. From the Plugins menu, open AnalysePlugin. The screen will split into three parts. The top left is still the raw ksp.log file you just opened. At top right, the AnalysePlugin interface. The bottom is currently empty; this is where our errors and warnings will show. But first, we need to tell the plugin what to look for. How? Meet me at step 5! Welcome to step 5, thanks for coming. Now, you could tell the plugin what to look for manually...OR... load a pre-defined set of parameters instead! Let's not re-invent the wheel today; that would be very Kerbal-ish. So, here's a free wheel, pre-invented: a super-simple definition file for AnalysePlugin to find warnings and errors. It's something I plan to expand on by exempting deprecated Unity warnings and known irrelevancies... but this basic xml file suits our purposes for the moment. Grab "analyse_ksp_log.xml" from my OneDrive, here: https://1drv.ms/u/s!AtC9nbX8Ht1DmslnhdzUgFKSD9IiIg and save it. Save it to your KSP folder, Notepad++ folder or anywhere you like... just be able to get to it for the next step. Go back to Notepad++ and look at the AnalysePlugin panel. Under "Visualization" you'll see a group of nine buttons, three down and three across. The top-right button says "Load"; click it. A file open window appears. Navigate to wherever you saved analyse_ksp_log.xml. Select it and confirm. Now you should see a few entries in the AnalysePlugin's search grid, where once it was empty. Head back to the same group of nine buttons - at bottom-right, click on "Search". Eureka! The bottom panel should now be filled with grey and red lines. Our gold in the mine, so to speak. Grey/Yellow indicates a Warning, Red/White is an error. The plugin has also bookmarked each line in the raw ksp.log. Nice. (You can make the text in the bottom panel bigger or smaller with Ctrl+MouseWheel Up/Down - this works in the top panel also.) NOW WHAT? When you click on an error or warning in the bottom panel, the top panel will scroll to that entry in the log, so you can look at all the information surrounding it and get an idea of what happened. This is insanely useful for figuring out what's actually going on in regard to a particular log entry. Errors and warnings are a start but, often there will be critical information related to a problem in the surrounding entries. DOES KSP NEED TO BE SHUT DOWN? Nope! This process is great for troubleshooting in real-time. You can perform some actions in the game, switch to Notepad++, hit search on the plugin and see if there were any errors generated by your actions. For best results in real-time, open the KSP console, select debugging on the left-side menu and place a check in the box next to "Immediately Flush Log File To Disk". Remember to turn this off when you are done as it may affect performance if KSP is constantly logging direct to disk. SO. MUCH. GREY. AND. RED! Keep in mind, not every warning or error is a problem that needs solving. For instance, if you have a mod with wheel parts like Airplane Plus you may see wheelcollider warnings that are erroneous and can be ignored. Some KSP errors are strictly Unity boilerplate stuff and can be disregarded. For example, you may see a false-positive anti-aliasing error that is deprecated by Unity but, has not yet been removed. Some mods include assemblies or configs to work with other mods... mods you may not have... those might throw a dependency warning or other error when they do not find the other mod, which is fine. Remember, even with this method, there is still some work to be done on your part to learn what is of concern and what can be disregarded. Google is your friend. Duck Duck Go is family I WANT MORE INFO ON THE BOTTOM PANEL! If you want to see "LOG" level entries in the bottom panel along with the ERR and WRN entries: go to AnalysePlugin, in the grid, place a X in the box on the top row, next to "[LOG". Be advised that LOG WRN and ERR are not the only prefixes in ksp.log. The bottom panel is not the full picture of what's going on. Treat it like an index. HOW ELSE CAN I USE NOTEPAD++ WITH KSP? A user-defined language file for Notepad++ by forum-member genericeventhandler is useful in conjunction with this process, if you decide to take the next step and dive into some of your mod's .cfg files. It makes those easier to read by properly coloring comments, delimiters and common keywords. He explains how to use it in his post, linked below. If you have any Notepad++ related issues, Plugin Manager issues, etc... please go through those support channels before posting here. This post assumes that if you want to analyse your own ksp.log file you are also good to install applications and manage plugins. My OneDrive will be active forever if I have anything to do with it... and I do... but, if the OneDrive link to analyse_ksp_log.xml is not working, do let me know. Here's a dropbox mirror, just in case: https://www.dropbox.com/s/sa460qo72jstxwf/analyse_ksp_log.xml?dl=0 I'm an infrequent visitor but, I have turned on notifications, in case anyone needs a clarification. I'm not a ksp.log analyzing service... there are plenty of folks on the forum who can help you with that. This is a self-help post. Happy analyzing!