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 the "IR Next" mod. (The only infernal robotics mod was no longer being updated anyway and didn't work on KSP 1.6.1. But IR Next, although not officially released yet, does work on 1.6.1, so we switched to that. pull request More types are now serializable as messages or JSON files: Notevalue, Direction, RGBAcolor, and HSVAcolor. pull request CORE:TAG is now settable pull request KUNIVERSE:PAUSE suffix added. pull request Added a new TIME(seconds) Constructor to make a Timespan out of a Universal timestamp. pull request New LIST FONTS. feature so the user can see which font names are loaded into Unity for use in user GUIs. pull request BUG FIXES Several documentation alterations: pull request pull request kOS would throw a Nullref if a script tried to check for a CommNet connection to a vessel that has been classified as type "debris". pull request Sometimes kOS broke the Space Center, making the buildings impossible to click on. This was caused by input locks not letting go when the terminal is open while the kOS physical part gets exploded. pull request Fix to the kOS icon being broken (showing just a purple square) in Blizzy Toolbar mod. [pull request(https://github.com//pull/2454) GeoPosition was written improperly in messages or JSON files. pull request The "hue" part of HSV colors was never quite implemented properly from when it was first introduced. (It was mapping all hue numbers down into just 1/6th of the full range of hues, so greens and blues were not available.) pull request When using the message queue system while Remote Tech is installed, you could not send messages to vessels far away outside the load distance bubble (i.e. 2.5km-ish). This is fixed. pull request Vecdraws were incapable of drawing dark colors like black because they were using an additive-only shader. pull request Fix a case where cooked steering from the terminal refused to let go if a subsequent kerboscript error is typed into the same terminal. pull request If "run once" was used, and the system chose not to run the program because it was already run, it was possible for the stack to get corrupted in a way that confused defaulted parameters to programs. pull request Fixed Multimode engine bug that was introduced in v1.1.6.1. pull request Moved kOS dialog box to a new position to fix a clickthrough problem that caused you to secretly pick a kOS connectivity manager without realizing it when you click on things in the Remote Tech dialog box. pull request

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 unofficial implementations. But there's always a chance we got something wrong. If you find an issue before he is able to reply, please feel free to post it and let us know.

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 allow tech tree scaled performance by era for the kOS computer parts themselves (slow at first, faster later). BREAKING CHANGES: If you use the compiled script feature YOU MUST RECOMPILE ALL KSM FILES, USING KSM FILES COMPILED IN A PREVIOUS VERSION WILL RESULT IN AN ERROR. Files now have an implied local scope, causing the following change: Previously: If you declared a variable as local at the outermost scope of a program file (outside any curly braces), then it had the same effect as global, creating a variable that you could see from anywhere outside that program file. New behavior: Now that there is an outermost scope for a file, local actually means something in that scope. To get the old behavior you would need to explicitly call the variable global. (The variables magically created via the lazyglobal system will still be global just like they were before.) Parameters to programs now have local scope to that program file. (Previously they were sort of global and visible everywhere, which they shouldn't have been. If you relied on this behavior your script might break.) This is of particular note when working with locks and triggers as the local parameters may conflict with the global scope of these features. Functions declared at the outermost scope of a program will now keep proper closure, making them see variables local to that program file even when called from outside that file. This may hide a global variable with a more local variable of the same name, when previously the global variable would have been accessible from the function. (You probably weren't relying on this buggy behavior before, but if you were, this fix will break your script.) NEW FEATURES: File scope: Previously, kerboscript did not wrap program files in their own local scope. (Declaring a local in a file had the same effect as declaring a global there). Now each program file has its own scope (and also the parameters passed to a program file are local to that file scope). NOTE: For backward compatibility, there is one important exception to the file scope - functions declared at the outermost level by default can be globally seen in other programs. You CAN get functions that are local to the file's scope, but you have to explicitly include the local keyword in the function declaration to make that happen. pull request OPTIMIZATIONS: The regular expression syntax used to compile programs has been heavily modified to speed up file parsing using start string anchors and eliminating string copying. pull request pull request Suffix lists are no longer initialized on every call, saving both execution time and memory. pull request Various string operation optimizations for internal string lookups. pull request pull request The cpu stack was re-written to use two stacks instead of using a single stack with hidden offsets. pull request Cache type lookup data for suffix delegates. pull request Begin encoding identifiers directly in opcodes instead of pushing a string identifier prior to executing the opcode. pull request pull request General optimizations for the C# source code, including for unit tests. pull request pull request pull request pull request BUG FIXES: Functions at the outermost file scope level now have closures that can see the file scope variables properly. Previously they could not (but this did not matter since there was no file scope to matter. This bug got exposed by the other file scope changes.) pull request Fixed inability to use flight controls on a craft with local control when RemoteTech is installed, both with and without a probe core installed. pull request Fixed a crash to desktop when attempting to parse very large numbers. pull requst Fixed syntax errors in the exenode tutorial documents. The code as displayed has been tested to work correctly as of this release. pull request Parsing numbers on host computers that normally expect the , character to be used as a decimal symbol will no longer be blocked. kOS now forces the use of CultureInvariant when parsing numbers, so all locales will be required to use the . character for decimals. pull request Action Groups Extended support should once again work as the the method used to detect that the mod is installed has been repaired. pull request Attempting to delete a path that does not exist no longer throws a null reference error. pull request Documentation was added for part:hasmodule suffix. pull request

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 manned pod and a probe core installed. EDIT:MY MISTAKE: I ONLY READ LINE PART, EDITED RESPONSE BELOW: That's very strange and shouldn't happen. We explicitly ask RemoteTech about local control in our underlying code. When you lost signal, what the the RT status indicator say in the upper left hand corner? It should have read "Local Control". If it said "No Connection" or "N/A" that would be the reason. If it does correctly show local control, then there appears to be a disconnect between what RT reports in the interface and the value returned to us in the API. Please let me know what you find so I can use that information to narrow down what I need to test.

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 you want to use internally to get the list registerAction(agList). } // on whatever is requesting the list reference: public List<bool> AGXList; var testEvent = GameEvents.FindEvent<EventData<GUID, Action<List<bool>>>>("fetchAGXActionGroupEvent"); testEvent.Fire(this.vessel.id, lst => AGXList = lst); // only requests info applicable to this object

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.