hvacengi

v1.1.7.0 Lets get Serial Mostly fixes. The motivation for this release is to get fixes out to the public before KSP 1.7 comes. Built for KSP 1.6.1 Github download: https://github.com/KSP-KOS/KOS/releases/tag/v1.1.7.0 Spacedock download: https://spacedock.info/mod/60/kOS:%20Scriptable%20Autopilot%20System Curse download: https://kerbal.curseforge.com/projects/kos-scriptable-autopilot-system/files/2697100 BREAKING CHANGES Compatibility for the old Infernal Robotics is officially removed in favor of support for the "IR Next" mod. NEW FEATURES Support for

Try removing only the "kOS-module-manager.cfg" file inside the kOS folder. That should at least narrow down whether or not the issue is with the part module for the name tag system.

kOS doesn't make any changes to fairings other than by adding the nametag module. In my local install I have no problem setting the textures on any of the fairings (or other parts). Looking through your logs I don't see any entries for ModulePartVariants, or for our name tag module, and the only exceptions I seem to find are related to kOS script errors. If you remove kOS from the install, does it fix the fairings?

The telnet part of the mod isn't exactly in my wheelhouse, but it sounds like you're pretty well versed in the underpinnings for telnet itself so I thought there might be some benefit pointing you towards the mapper for VT1000: https://github.com/KSP-KOS/KOS/blob/develop/src/kOS/UserIO/TerminalVT100Mapper.cs You may also want to look at the telnet singleton server: https://github.com/KSP-KOS/KOS/blob/develop/src/kOS/UserIO/TelnetSingletonServer.cs I know that when @Steven Mading worked on the telnet code, he spent a lot of time looking through the standards along with some of the uno

New release: v1.1.5.2 - Basic Compatibilty for KSP 1.4.1 This release is mostly just a recompile to make kOS work with KSP 1.4.1, with the few changes that were needed to keep it working, and whatever bug fixes happened to already be implemented when when KSP 1.4.1 came out. DOWNLOADS: Github: https://github.com/KSP-KOS/KOS/releases/tag/v1.1.5.2 Curse: https://kerbal.curseforge.com/projects/kos-scriptable-autopilot-system/files/2540960 Spacedock: https://spacedock.info/mod/60/kOS: Scriptable Autopilot System

We do maintain a configuration file, but the CKAN web crawl to look for those updates is out of our control. The good news is that it appears to have updated now. Usually it takes between 12 and 24hrs for the update to hit CKAN. (I want to say CKAN does an update every 12 hours, which would align with my past experience).

v1.1.4.0 Does faster compilation break a work flow? Downloads: Github: https://github.com/KSP-KOS/KOS/releases/tag/v1.1.4.0 Curse: https://kerbal.curseforge.com/projects/kos-scriptable-autopilot-system/files/2512889 Spacedock: [pending] This release was primarily focused on speedups and smoothness of execution. We welcomed a new developer (github username @tsholmes) who contributed a lot of bottleneck analysis and code speedups. The goal was to reduce the burden kOS causes to the physics rate of the game, and consequently also a

v1.1.3.2 New KSP Version HOTFIX This version is functionally identical to v1.1.3.0, however the binaries are compiled against KSP 1.3.1 to allow it to properly load with the updated version of KSP BREAKING CHANGES: This build will not work on previous versions of KSP. NEW FEATURES: (None) BUG FIXES: (None) DOWNLOADS: https://github.com/KSP-KOS/KOS/releases/tag/v1.1.3.2

I believe the problem is that you don't have a RemoteTech enabled probe core installed. The design of RT currently requires a probe core in order to enable their functionality. It is not clearly noted in either the kOS documentation or the RemoteTech documentation. What's even more confusing is that RemoteTech will still draw all of the connection lines. You can tell that this is happening if you look at the RT status indicator under the clock in the upper left hand corner. Without a probe core it should read "N/A" (if my memory serves me). But it will say "Local Control" if you have a m

Looking at the log, the probe core looks like the most likely cause. I haven't had RT installed for a bit, so if that doesn't fix things for you I'll get it installed and give it a try tonight.

I'd be curious to know what errors you do find if you run it with the wrong KSP version. Because we're prepping for our 1.1.0 release, and because I had an extended hiatus, we haven't done a lot to prepare for the new release. But I'm sure that there will be plenty of small bugs to fix.

I've added the KSP version to my original post here, but it should have already been highlighted on the top of the changelog for the github release page. If you aren't seeing that image, please let me know and I'll make sure that we get it fixed.

Pre-release v1.0.90 kOS has released v1.0.90 ahead of the next full release (v1.1.0). We are asking users to please help us with testing new features, as well as regression testing old features. To download the pre-release, and to view the changelog, please visit https://github.com/KSP-KOS/KOS/releases/tag/v1.0.90 This release will not be made available via ckan, spacedock, or curse. You can also find the temporary documentation at http://hvacengi.github.io/KOS/

I tend to do dictionary keys based on the vessel's id (which is a GUID), but it could be an unnecessary or useless optimization. The other thing to remember here is that you can define however many parameters you want the event method to use. So you could do something like: public static EventData<GUID, Action<List<bool>>> fetchAGXActionGroupEvent = new EventData<GUID, Action<List<bool>>>("fetchAGXActionGroupEvent"); public void FetchAGXActionGroupList(GUID vesselID, Action<List<bool>> registerAction) { var agList = // whatever means

Do you have a probe core on the ship? RT doesn't know to tell us that a vessel is connected if there isn't a probe core, even though the connection lines will still work and you can control the vessel manually.