Dunbaratu

Depends on the original program. if you have a long variable name and use it again and again, it can be crunched a lot. if you have short names, or if you don't indent much, or you do have long names but don't repeat them much, you don't see much help.

This is my official request to rename my forum account to "Dunbaratu". Reason: I made my account in these forums long before I started doing things for the kOS mod including a youtube channel, twitch channel, guthub account, and discord server. For those other places I decided to go with a pseudonym so as not to directly "dox" myself (I mean, yes, you can do some digging around and figure it out but I didn't want it to be easy low-hanging fruit for zero effort). My chosen pseudonym for all of these other places has consistently been the name "dunbaratu", and that is the name people are more likely to search for when trying to find me for Kerbal-related reasons. Ironically although "dunbaratu" began as a reason to avoid doxxing, now I want to use it for the opposite reason - to make it *easier* for people to find me by using the same username across platforms.

kOS v1.3.1.0 official announcement (See First Post in this thread for links to download it.) There's a lot of small changes over the last year that have added up to a big release. This release supports KSP 1.10 and KSP 1.11. It has no specific KSP 1.11 changes but it has been tested and it does work with KSP 1.11. (NOTE ABOUT KSP 1.11 - If you want to put a kOS part into one of the new cargo inventory slots that came with KSP 1.11, you can do so but remember to FIRST attach it to the vessel in the VAB/SPH so you can adjust the disk space and boot file settings, then detach it from the vessel and drag it into the cargo slot - that way it has the settings you gave it. If you just drag it directly into the cargo slot from the parts bin then it only has the default values.) The most important changes are probably in steering and control. Cooked steering shouldn't waste as much RCS as it used to, and if you are using raw control you now have the ability to set the player's trim settings for yaw, pitch, and roll so you can steer using those and not completely lock the player out of control. There is also a panic button for telling kOS to suppress all of its controls if the player needs to take over the controls regardless of what the script is doing. As always, recompile KSM files with this release. Especially as there was an important KSM bugfix. BREAKING CHANGES TimeSpan used to mean a fixed stamp in time (the name was not really accurate). Now there are two types, TimeStamp and TimeSpan, and the one that USED to be called TimeSpan is now called TimeStamp, with TimeSpan now being a new type that didn't exist before. This could affect scripts if you ever did a check for :istype("TimeSpan") (because of the rename) but shouldn't affect anything else. Even more than usual it's important to recompile any KSM files. A major bug in how KSM files were written was discovered that this release fixes. There's a chance your existing KSM files may already be wrong. If you have any bug reports about a KSM file not working right, please try testing again with this release by recreating the KSM file. There's a small chance you might have had the bug this release fixes. (Look for "KSM" in the bug section below.) If you are using the output of SteeringManager:WRITECSVFILES, be warned that output now has a new column in the second-to-last position, the MinOutput column. That means the MaxOutput column has shifted one position to the right. This should only affect people who are analyzing that data with external software. In order to support Kerbal Alarm Clock version 3.0.0.2 or higher it was necessary to break compatibiltiy with versions of Kerbal Alarm Clock that are older than that. The API wrapper changed enough that backward compatibility is too messy to maintain. The :LIST suffix of VOLUME said in the documentation that it returns a LIST when in reality it always returned a LEXICON. If you relied on this and wanted the lexicon not the list, you need to now use the new suffix :LEXICON because the old suffix :LIST has been changed to match the documentation and be a real actual LIST now. Temperature tolerance for the kOS parts was way too high, making them effective heat shields when they shouldn't be. If you had been taking advantage of this before that might not work anymore. CREATEORBIT() used to take mean anomaly at epoch as a value in radians, which didn't match how everything else in kOS works. It is now expecting it in degrees as described in BUG FIXES below. If you ever happend to have a string literal with a backslash followed by a quote mark (\") that has now become a special escaped quote char and is no longer literally a backslash and quote mark. NEW FEATURES Maneuver Nodes can now be constructed with either ETA time or with UT time, and you can read their time either as UT (:TIME) or as ETA (:ETA). They also can take in the new Timestamp or TimeSpan types instead of just a Scalar number of seconds if you like. pull request There's a new button, "Reread Boot Folder", on the kOS toolbar window when you're in the VAB or the SPH. This button lets you tell kOS to re-read the boot directory when you've just added a new file to it, so you don't have to leave the VAB and come back for it to show up in the list of boot files. pull request The old TimeSpan type has been renamed to TimeStamp and a new TimeSpan type has been made in its place. This is to fit the design pattern where a "stamp" is a fixed point in time (a date and a time of day) and a "span" is a time offset. The main difference in Kerbal is whether you count years and days starting at 1 or at 0. pull request Suffixes :PARTSTAGGED, :PARTSNAMED, and :PARTSDUBBED can now be used with parts instead of with entire vessels. Doing so searches just the sub-branch of the ship starting from that part, instead of the whole ship. pull reqeust Added a new Suffix to RCS parts, :DEADBAND that lets you finally override the game's enforced 5% deadband on RCS controls. It turns out the deadband isn't in the controls, but rather it's in the RCS Parts themselves and doesn't apply to other torque sources like reaction wheels. That's why you notice it when translating (where only RCS works) and not when rotating (where reaction wheels do something and take up the slack left by the RCS thrusters not responding). pull request Big overhaul to SteeringManager's internals: There's been some important refactoring in SteeringManager that should reduce the control vibrations and consequently the RCS fuel wastage especially in Realism Overhaul (which relies more on RCS than stock does). Also, there's some user-settable epsilon values - if you want to change the tuning you can adjust SteeringManger:ROTATIONEPSILONMIN and SteeringManager:ROTATIPONEPSILONMAX. Dynamic Epsilon logic to reduce control jitter: pull request 2810 pull request 2813 The stock KSP's available torque calculations are random wrong values for RCS parts. kOS now replaces that with its own calculation instead: pull request 2820 The random number generator now can be fed a seed. pull request PIDLoop is now a serializable structure so you can save your PID's settings and bring them back from a file. Also PIDloop's CSV output now has a Minoutput column. pull request Enlarged max allowed terminal font size to 48, to benefit people with tiny pixels (i.e. 4k monitors). pull request Uses the changes to Kerbal Alarm Clock's API that started with Kerbal Alarm Clock v3.0.0.2. (This does break compatibility with older versions of Kerbal Alarm Clock, though.) pull reqeust On-Screen warning when SAS is fighting kOS: The message appears when both SAS and lock stering have been active for a few seconds and goes away when one or the other is turned off. pull request 2780 pull request 2783 Emergency Suppress Autopilot: You can now click an emergency toggle button on the kOS toolbar dialog window that will temporarily suppress all of kOS's locked steering so you have manual control. If you use this, the script will still keep running and think it's moving the controls, but the steering manager will ignore the script's commands until you turn the suppression toggle off. This can also be bound to an action group for the kOS PartModule if you want a fast hotkey for it. pull request Part suffixes that allow you to traverse the symmetrical sets of parts. (i.e. if you place 4 fins in radial symmetry, and have a reference to one of the fins, you can find the other 3 fins that it is symmetrical with.)in the same symmetry set) pull request The player's own TRIM controls are now settable by script. (Example use case: You want an autopilot to control an airplane by moving the trim but not the main controls so the player is still free to push the main control stick at any time). pull request ETA:NEXTNODE now an alias for NEXTNODE:ETA pull request Trajectories Addon updated to support Trajectories v2.4 changes. (Thanks PiezPiedPy) pull request Kuniverse:launchcraftwithcrewfrom() (Thanks JonnyOThan) pull request New suffixes for the special case where a Vessel is really an asteroid. (Thanks JonnyOThan) pull request Ability to read the stock game's Delta-V readouts for the vessel. (Thanks ThunderousEcho) pull request New subtype for Part - the RCS part type, with information about how its nozzles are aimed, what fuel it uses, the ISP, max thrust, etc. (Thanks RCrockford) pull request 2678 pull request 2809 Can now use \" in string literals for embedded quote marks. Also can prepend the string with @ to turn this off and keep it literal. (thanks thexa4) pull request New Engine value suffix :CONSUMEDRESOURCES, and new Type ConsumedResource it returns. These give more information about fuels the engine uses. Mostly relevant when RealFuels mod is installed so every engine is a bit different. (Thanks RCrockford) pull request Can CreateOrbit() from position and velocity (before it only worked with Keplerian parameters). (Thanks ThunderousEcho) pull request BUG FIXES Fixed: Kerbal Alarm Clock alarms had no ToString() so when you printed them you saw nothing. Now they show the alarm info. pull request Fixed: The suffix Widget:HASPARENT was documented but didn't actually exist. It exists now. pull request Fixed: Primitives like Scalars, Strings, and Booleans previously were not serializable with WRITEJSON() on their own as bare variables. They could only be written when inside containers like LIST() or LEXICON(). Now they can be written directly. pull request Fixed: KSM files would corrupt one of the kRISC instruction operands (leading to any number of random results when running the program) if the size of the operand pack happened to be just barely over 2^8, 2^16, or 2^24 bytes. (When calculating how many bytes addresses need to be to access the enire operand pack, its count of the size of the pack was off by 3. This could make the last operand in the pack get garbled when it loaded into memory from some random other part of the file instead of where it was supposed to come from.) (Thanks to newcomb-luke for discovering the problem and the cause) pull request Fixed how positions of packed vessels were off by one physics frame from the positions of everything else. This is apparently how things are reported b the KSP API and this had to be adjusted for. (Thanks marianoapp) pull request Fix Vecdraw labels no longer showing up in flight view pull request 2799 pull request 2804 Remove strange blank setting on the difficulty options screen. pull request OPENPATH() now returns false on file not found rather than bombing out with an exception. pull request RangeValue now allows use of bigger ranges and for ranges that increment by fractional amounts. (Before, it couldn't do floating point and couldn't do anything bigger than 2^31.) pull request Fix raw control :NEUTRALIZE never having quite done what it said it did right. pull request EVA Kerbals no longer have duplicate KOSNameTags when you have the Breaking Ground DLC installed. (The problem came from how KSP mashes two kerbal templates together into one kerbal to put the DLC science features into an EVA Kerbal.) pull request VOLUME:LIST now actually returns a list like it says in the documentation. Use VOLUME:LEXICON to get the lexicon you used to get from VOLUME:LIST. pull request UNSET now fails silently on non-existant variables as the documentation claims it should, instead of crashing with a nullref error. pull request Fixed a mistake that made it possible to process lines of input out of order if they flood into the terminal very fast. It was noticed in JonnyOThan's TwichPlaysKSP, which pastes entire scripts of input into the interpreter in one big chunk. pull request ADDONS:KAC:ALARM[n]:NOTES now returns the right thing. (It used to just return the same thing as :NAME. (Thanks JonnyOThan) pull request The ConnectionManager dialog box at the start of a career was repositioned to where it is unlikely to appear secretly hidden behind other mod's dialog boxes. (Other mods putting their) dialogs in front of kOS's and not blocking clickthroughs made some users accidentally pick a ConnectionManager and dismiss the dialog before they ever saw it.) pull request UI sound effects from kOS (error beep, SKID sounds) no longer have an origin point in 3-D space inside the part. They are now "ambient". This is to get sound mods to stop dampening the volume the same way they'd dampen sounds from engine parts, etc. pull request Parts no longer have excessive temperature tolerance. (Thanks robopitek) pull request CREATEORBIT() now takes mean anomaly at epoch as degrees. It was in radians before which didn't match how other things worked. (Thanks vzynev) pull request Better fuel stability (ullage in RealFuels) calculation. (thanks RCrockford) pull request Documentation fixes. Too numerous to mention each. You can click each of the links below to see them all: pull request 2675 pull request 2680 pull request 2707 pull request 2712 pull request 2724 pull request 2751 pull request 2772 pull request 2775 pull request 2776 pull request 2777 pull request 2784 pull request 2788 pull request 2791 pull request 2800 pull request 2819 pull request 2833 kOS can now handle KSP's technique of having multiple KSPfields of the same name that resolve the name clash by only having one visible at a time. KSP started doing this on a few fields about a year ago and caused bugs like "authority limiter" not working. (#2666) pull request kOS no longer allows ModuleManager configs to give it negative mass. (Antimatter summons the Kraken.) pull reqeust ETA:APOAPSIS no longer returns Infinity on hyperbolic orbits (While infinity is a correct answer, kOS scripts would crash when they get infinity on the stack. So now it says zero instead). pull request

There is a new kOS 1.3.1.0 that fixes this on the Github page. I won't put it on Curse or SpaceDock until it's been on Github for a day or two, just to be sure people have tried it and not complained about a major problem before I do that. (When I do that, I'll also update the first post of this thread and make it official. But until then you can try it and report any problems.)

The "soft" release yesterday has a bug related to using TimeSpan in a few places where it should be using TimeStamp. Expect another update today or tomorrow.

For the sake of modders, one thing I hope KSP changes about the UI/UX is to have a much stronger wall of separation between what is UI code and what is API code. So the UI's only job is to talk to the API that really enforces the rules, rather than the UI code itself doing it. I've run across frustrations in the past modding for KSP 1 where I've had to re-implement KSP's main rules again in my own code (which is an awful and not future-proofed at all way to do it) because when you talk to the API directly and don't click on UI windows, you are skipping parts of the rules that are done by the UI. Like fuel transfers. Those little windows that pop up with the "in" and "out" buttons control rules about whether you can transfer fuel between tanks and how fast the transfer is allowed to flow. So if I try to have a mod that triggers the fuel transfer a different way, not through the main UI, it lets players cheat and bypass the rules which isn't the intent. Another example is that it refuses to update the KSPFields that describe Breaking Ground's robot part servo positions (i.e "this hinge is at 45 degrees") if the UI window that would display them to a user is not open. If you're not a player trying to read that field but instead are a mod trying to read that field, there doesn't seem to be a way to tell the system to give you an updated calculation of that field other than forcing the window open for a moment to trigger the UI code that updates it. These are a couple of example, but that's the general idea. It's sometimes hard for a modder to sneak in under the UI code to accomplish the same thing the UI code does, when some of the main game's logic is inside the UI code itself. Basically that wall I'm talking about is a design principle where you view the UI/UX code as "one of several mods". They are *one way* to talk TO the game, rather than BEING the game. Given that they say they plan to do multiplayer I have high opes that this might happen. Multiplayer probably needs the same principle in place so that the server decides what is physically doable rather than the UI code in each client being in charge of that.

What makes this bug in the new contracts dangerous to players (and worth pointing it out here) is that it has a very large negative penalty for expiration, and none of the other contracts do this thing with a duration being too short for using the next Hohmann transfer window. People won't be in the habit of expecting to have to read the duration to see if an excpetional weird transfer is needed because literally none of the other contracts before now required doing that. It's the complacency of knowing up until now the durations have always "just worked" and never been a problem that causes the danger here. Usually I don't look at the duration until after I failed my first attempt, and then I start worrying that I might not have the time for a *second* attempt with a normal transfer. I never expect there to not be enough time for the *first* attempt with a normal transfer, as is happening here. It's also the fact that this contract does not vary at all - it's 2 years, fixed, no matter what - it's not even applying any minor variation with any RNG - that makes me assume this was not intended and there's something very wrong. The system that varies the duration of contracts by various circumstances doesn't seem to be activating for these at all. They're all getting the base hardcoded duration without variation.

The difference is that when taking multiple contracts to accomplish in one mission I'm going to launch but haven't yet, as I usually do, one of them can be "send science from" along with the others. That is not true for these new ones. Which is exactly the situation here. I was going to Duna to do 3 things in one mission: Retrieve Duna Stone, Plant a Flag, and Add a solar panel to a satellite. The two normal contracts did not expire on the way there. The new satellite repair contract did (with a very large negative "fail" value that overwhelmed any gain from the other two and killed the career sending funds several hundred thousand into the red.). Had the three contracts been Retrieve Duna Stone, Plant a Flag, and Send Science From Duna, all 3 would have still been do-able when I got there.

While technically correct, literally no other contracts in the game expect the player to look at the duration to check if it might not let you do a vanilla Hohmann transfer in time. Thus my post here warning people. If you don't realize ahead of time that these contracts have buggy durations, you won't be in the habit of even looking at the duration ahead of time. It becomes "impossible" because you didn't even see that the duration is abnormal until quite a bit of time later after you've been time warping too much now to do it. If you don't like savescumming, that really blows to have the contract surprise you by turning red halfway through your transfer to the target and say "expired", with you going, "wait... whaaat?"

It's not similar. With the "send science data from..." contracts, the duration is clearly designed to let you do them with a fresh launch waiting for the next Hohmann transfer. You *can* do them faster and cheaper if you already have something there, or if you spend extra deltaV on a faster but less efficient trajectory for a new launch, but those things are not *necessary* like they are with these 1.11.0 contracts. There's clearly a major bug here. And yes it is worth warning people of this since none of the other contracts work that way and this one is an odd exception to the rule. The fact that the new contracts have much shorter durations than the rest do is something you're not likely to notice when first taking the contract. And once you see that it's terminating early it's too late since you assumed it was like *every other* contract and gave you the time to do it the normal Hohmann transfer way. (If you don't see this problem coming, your first indication that these contracts are weirdly different from the rest is *after* the duration expires and you get the red-X and go, "wait, whaaaat?")

This post is to just let the other players know about this so they don't get burned by it in their career like I did. The only way the new repair/edit vessel contracts for distant destinations like Jool or Duna are do-able is if you saw the contract get offered while you coincidentally were already there for some other reason with a crew vessel that can do the contract. The new contracts don't seem to be varying their duration depending on destination like most contracts do. They're always exactly 2 years, fixed, no matter what. This is not enough time to launch a new vessel to go there for many interplanetary transfer situations. This is not to report the bug. I already did that here: https://bugs.kerbalspaceprogram.com/issues/26958 This is just to warn other players. These contracts can sometimes have large failure penalties so that guaranteed duration fail can kill your career.

Hopefully this gets fixed in a KSP 1.11.1 patch soon. To any players playing career in KSP 1.11.0, I wanted to drop a warning in here. The new contracts that were added with KSP 1.11.0 such as repairing rovers and satellites, and adding parts to satellites, have impossibly short durations for interplanetary missions. They seem fine for around the Mun or Minmus, but not for Duna, Jool, etc. You take the contract and get blamed for "failing" at it (sending money into the red if it's big) even though you were never even given the time it takes to make one single attempt at it. The problem is that All the new contracts are exactly 2 years. Hardcoded. Period. Want to repair a satellite around the Mun? 2 years - easy. But want to repair a satellite around Duna? Still 2 years. Around Jool? Still 2 years. Whatever the game normally does to vary contract times depending on the destination body seems to be not working with these new contracts, making them impossible if you take them for a distant planet. This is the issue in the tracker: https://bugs.kerbalspaceprogram.com/issues/26958#change-158334

Was that it?

This might be an obvious thing to check you already tried but ... do you have a controller plugged in and maybe during the upgrade did the game lose the nullzone settings for it (so it now thinks an analog stick is always slightly offcenter and that's making it rotate the camera?)

There are a few issues in the bug tracker where other players have reported the same problems since KSP 1.11 came out this week. There's something wrong with how this new way of storing light color info works. Either it is not getting saved in files or it's not being loaded back from files. It also gets forgotten in craft files so if you spend time in the VAB fiddling with the light settings it's wasted time because it gets forgotten when you go from VAB to launchpad. Not sure what is wrong but anything that involves saving/loading to a file fails to preserve these settings.

Is this a bug or is it expected behavior? ClickThroughBlocker is in focus-follows-mouse mode, and I hover the mouse pointer in an area where two windows overlap. Instead of JUST the input lock of the window on top, it's activating the input lock of both the windows, including the one that's underneath. In the screenshot, both the two windows are created using ClickThruBlocker, with this specific version of the many overloaded variants of the Window call: ClickThruBlocker.GUILayoutWindow(int, Rect, GUI.WindowFunction, GUIContent); This variant is one of the ones that uses the Window's unique id integer to form the lockName (some variants use the window's title, which is why I'm mentioning which variant is being used.) In this case the two integer ids were the numbers you see in the debug window: -375264 and -376740 The screenshot didn't capture the mouse pointer, so I had to draw it on afterward in Gimp to show you where it was. If I move the mouse to the area where the windows don't overlap then I only have one or the other of the two locks active. The reason this came up is that I was trying to experiment with using InputLockManager.IsLocked() as a roundabout way to query which window ClickThroughBlocker has given focus to. But when two different windows can have their input locks active at the same time that technique won't quite work.

The bug tracker, at https://bugs.kerbalspaceprogram.com/ has started getting spambots posting "issues" which are actually ads. Some of which have stayed in there a while. Is anyone on top of this and reading the issues? I'm wondering because the spambot issues aren't being removed or closed, making me wonder if anyone working for SQUAD or Take 2 is even looking at the tracker anymore.

So if do it in the reverse order from that, such that I merge the .netkan change into the master branch a few hours *before* I've cut that release from master, will it end up making the previous release of kOS get a dependency on ClickThroughBlocker (because the newer release wasn't there yet when the Netkan bot crawled every half hour and saw the kOS.netkan change in master branch)? If so, then I have to change how I'm doing my PR for this change and split it into two PRs - one for the C# code that calls ClickThroughBlocker's API and another for the kOS.netkan dependency on ClickThroughBlocker that code caused. (Right now they're the same PR which seems sensible at first unless it would cause the scenario I described in the previous paragraph). It matters because my dependency requires a minimum ClickThroughBlocker version number to have the features LinuxGuruGamer just added a few months ago that I'm using. If the previous release of kOS ends up falsely claiming it has a hard dependency on this new version of ClickThroughBlocker, that could prevent CKAN from letting you install it on older versions of KSP that only allow older versions of ClickThroughBlocker. That's why I'm nervous about making sure I do this right.

Thanks for the quick reply. Will it be smart enough to NOT apply the new dependancy to older versions of kOS if I just continue with the .netkan file technique as it is using now? Or do I need to switch to the .ckan file in the ZIP to get that kind of version-specific dependency?

I have a question about how the CKAN bot crawler works. The kOS mod is already in CKAN, but I need to add a new dependency when I make the next release (The next release will depend on ClickThroughBlocker. It didn't need it before.) I know what edits to make to the netkan file to describe the dependency, but I don't know how to get CKAN's bot to see the change. Currently the .netkan file isn't part of the ZIP at all (it's edited "one folder up" from where the ZIP is cut from) so I assume the bot can't possibly see that information. I'm guessing that previously the mod was manually added to CKAN with a pull request but I'm trying to figure out how to make it automate the updates by having the CKAN bot see the information somewhere inside the ZIP file, like it does for the .version file. (This is a mod I inherited from others. I was not the person who originally set it up in CKAN so I don't know what steps were taken at the time.) So my question is this - if I just start using netkan.exe to convert the .netkan file into a .ckan file, and copy that .ckan file to GameData/kOS/whatevername.ckan, inside the ZIP will that automagically make the bot update kOS's CKAN info when I make a release with that ZIP next time? Or are there other manual steps I need to do first? Up until now, we *have* been getting automatic updates in CKAN from the information in the ZIP's "kOS.version" file, but this is a thing the .version file doesn't have in it (dependency on another mod).

The timewarp workaround only fixes one third of the effects the change caused. The other two effects it does not fix are: {1} One-to-Many transfers involving 3 or more tanks don't work anymore, making fuel balancing impossible; {2} It broke the use of fuel hoses to route around blockages like heat shields, meaning you now must play with that difficulty option turned off, as its rules are broken.) These are problems in *stock* gameplay, not even modded. Unlike dok_377, I don't mind that the fix didn't come out immediately. It's probably an issue with dirty cached data and those can be hard to trace without just throwing away the entire caching idea entirely. But I do want to quash this narrative that says it's low severity because of the workaround. The workaround doesn't really fix all the issues this change caused, so please don't move it to the backburner.

Ever since KSP 1.10.1 downloaded today I have gotten 6 crashes to desktop, all when trying to do the same thing (this is stock, no mods, but I do have both DLCs): The crashes only ever happened when trying to drag one of the 6 'knobs' of a maneuver node. Usually (thought not 100% of the time) that maneuver node was made while currently in orbit of Sun, on the way to Jool, and trying to make a maneuver node on the Sun orbit patch that will adjust the future Tylo approach to do a gravity-assisted capture at Jool. This is making it unplayable (as my career is currently in the middle of trying to do stuff at Jool so this Tylo assist is a common task.) and I cannot back out to KSP 1.10 (the Steam "betas" tab does not show 1.10 as an option. I can either have 1.10.1 or 1.9.2 - nothing in between those two.) This problem never happened before today's update. As part of trying to clear out whatever the bug is, after each time, I used Steam's "Verify Integrity of Local Files" and it always finds a few that need re-downloading after the crash. The file "PartDatabase.cfg" is *always* reported as needing a reload. Sometimes it wants to reload other ones too, but that one is the consistent one that always differs. I don't know if this is just a normal side effect of having played the game (maybe it always writes that file out each time the game runs) or related to the crash. Is anyone else experiencing this? Am I alone? I saved the last 4 Crash folders from Appdata/Squad/Kerbal Space Program if that would help.

It sounds like this problem, which is known but not in release yet: https://github.com/KSP-KOS/KOS/issues/2666 Do you have the ability to compile the kOS Project? If so, using the latest Develop branch would probably fix it. Otherwise I think you'll have to wait for release. With KSP 1.10 coming this week, I do plan to have a release of at least some sort within a week after it comes out - even if it's just a basic compatibility release.

Some people have made patches for ModuleManager that add the kOS PartModule to probe cores. This is fine, but if more than one mod has done this, and one of them wasn't set up right, it can install the partmodule in *addition to* some other mod that is also doing it. There is a means in ModuleManager's config files to add the condition "only if it's not already there" to the command to add a KOSProcessor. But somewhere you have a mod that's not doing that. To figure out which of your mods are adding kOS via ModuleManager, search through all files under the GameData folder that are ending in .cfg, and scan them for the magic word "KOSProcessor".

There is both a subreddit and a discord server that are all about kOS and are a better place to ask. There is also a thread on these forums, but that thread has slow response times. I'd recommend the subreddit as the best way to ask a long question (which it sounds like you have) where you need to describe things in detail, post code, and wait for an answer. The discord is better for shorter questions that can be answered fast and don't need a lot of explaining. Thread on these forums -> SubReddit -> https://www.reddit.com/r/Kos/ (A permalink invite to the Discord server, as well as links to documentation, are in a sidebar of that subreddit.)