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.

Yeah, it can take a bit to wrap your head around how C# handles delegates, particularly around the magic syntax of generics and anonymous methods. If you remove the anonymous method (the "l => testList = l" bit), you can instead do something like this: public void RefreshList(List<float> listReference) { testList = listReference; } // and change the Fire call to: testEvent.Fire(RefreshList); // passing a method that takes the same parameters as the generic Action's definition I actually prefer that method when I write code, just because I find it easier to troubleshoot/debug named methods.

The problem is that your event is storing the list in the local variable (the method's parameter), rather than the variable accessed by the other mod. In order to store the reference in the other mod's class, you must assign it from within that class, or using the classes public field. I've added comments about this to applicable sections of your code here: https://gist.github.com/hvacengi/554ecf0463ab4045af24da95f3dec091 You can make it work the way you implemented it if you move things around so that it uses a 2 event system. But using the anonymous method/Action technique that @xEvilReeperx showed reduces the number of events that need to be subscribed. I've taken the liberty of combining his example with your example, with lots of comments to try and help see how to make it work. You can see it here: https://gist.github.com/hvacengi/9a7ef88ac0b4010cabf4a2653adc1352 The most important note from my testing is that events appear to fire imediately, and are not queued up for the next physics tick. Immediately after firing the event, my list reference was updated.

Hm, I like the delegate (Action) idea. I hadn't thought about that, but it would eliminate the risk of the extra references. I would presume that there would still be a potential need for the ability to simply subscribe to events instead of polling the list for other mods, but that would be a really clean solution for kOS's needs.

Those are exactly the objects I'm concerned with. But I think that's because I'm thinking of a different architecture. I was still thinking of the dual event system. I'm not sure that the single event system will do what we are looking for it to do: Using @Diazo's pseudo code: AGX: public static List<bool> masterList; public static EventData<List<bool>> referenceMasterList; referenceMasterList.Add(handleReference); handleReference(List<bool> refList) { // by having AGX store the reference created in kOS // the reference changes each time the event is fired // which means that if you have 2 mods that fire the // event, the reference will be overwritten and only // the newest reference will actually be used. refList = masterList; //does this work? } kOS: public List<bool> kOSlistReference; referenceListEvent = GameEvents.FindEvent<EventData<List<bool>>>("referenceMasterList"); referenceListEvent.Fire(kOSlistReference); // now kOSlistReference is the reference, but no way to know the reference changed // ALTERNATIVELY: AGX: public static List<bool> masterList; public static EventData<List<bool>> referenceMasterList; public static EventData<string> requestMasterList; requestMasterList.Add(updateReference); updateReference(string requestingModName) { // requestingModName is just a parameter for the sake of having a parameter referenceMasterList.Fire(masterList); // trigger event sending out the reference to the internal master list. } kOS: public List<bool> kOSlistReference; referenceMasterList.Add(OnUpdateReference); requestMasterList.Fire(kOSlistReference); OnUpdateReference(List<bool> referenceList) { kOSListReference = referenceList; } OnDestroy() { // if we don't do this, even though all of the normal Unity events // get unsubscribed, this event will still be subscribed and will // prevent the GC from relaiming any memory not explicitly freed // as part of the GameObject's destruction requestMasterList.Remove(OnUpdateReference); }

Not necessarily. If the event is declared static, it will not get cleaned with the life cycle of the instantiating object. And you have opportunity to create circular references too. Event1 refers to AGX which refers to Event2 which refers to kOS which refers to Event1... and so on. It's my understanding that the Mono GC used by Unity is pretty simple, and just walks each object looking for references to other objects, removing any object that has no references pointing to it. I ran into this issue with some KSP events that kOS subscribed to. I found using the debugger that the event delegate was getting called well after the object itself should have been cleaned up (across scene transitions even).

Yeah, that should work so long as the value you pass through the event is a "reference type". Technically there are a few tricks that could mess that up, like cloning values passed to the events. I'm not in a spot to verify that Unity and/or KSP don't do something like that with event parameters, but I should be able to check it out tonight. The important thing to remember is that the reference is to the object itself, and not to the variable. So if you reassign the variable inside the AGX code, you should fire the event again to ensure that other mods update their reference. Well, reflection by it's very nature is complicated, and while it doesn't need to be avoided I think it makes sense to use simple alternatives if they are available. In part that's because it relies on hard coded relationships to assemblies you don't control. Another component however is performance. I really wanted to outright modify the way that kOS calls the AGX method, because currently the method delegate is instantiated every time it is called, which I understand is expensive. And in my opinion, anything that can be moved into a more common system which can be accessed using explicitly typed methods/fields is an improvement in both performance and code readability. By common I mean a class or interface defined by an assembly that you know both mods have access to, essentially anything in the base Mono/.net framework. After I finished typing out the above, I had the realization that there is one other thing we have to be careful with for events: object life cycle. If an object is subscribed to an event and never unsubscribes, I don't believe that the GC will ever clean up that object (because the event code still has a reference to the object). Which means that either the event should be cleared on scene change, or other mods need to be instructed to be careful to unsubscribe as part of the `OnDestroy` logic. That does add a bit of complication when explaining how to implement the system, but I still think it's easier than explaining how reflection works.

I'm posting this question here as well as my response to #1939 Is there any reason that the event is required to return a ConfigNode based structure? Could you instead create a base event that returns a commonly known reference type, like a list? That would allow you to create an event that serves as an "initialization" or "heartbeat" event, that simply gives out the reference to the list. public static EventData<string,ConfigNode> onAGXInitRequest; public static EventData<string,List<bool>> onAGXInitReturn; Under this structure, an object would subscribe to the onAGXInitReturn in a method that stores the reference to the list. Then it would fire the onAGXInitRequest event to signal to AGX that it needs to pass out the reference. AGX would then fire the onAGXInitReturn event, passing with it the reference to an internal list of the state of each action group. Then AGX would update the values for the actiongroup list (without creating a new list) allowing for instant action group status inspection. You could even go so far as to implement IList<bool> in your own class, allowing you to simply respond to the standard list methods without needing to change your own implementation

Yeah, I forgot the phrasing and didn't open KSP to check. "Stage View" is the correct option. No, I don't have any intention to do anything like that. That's more complicated because you need to manage when that camera controller lives/dies/becomes a ravenous zombie bent on eating my brain (maybe not that last option). There are some other mods that do things like that and I may make an addon to interact with them instead. I did forget to link the example library I built to help users manage the camera easily. So here it is (if you didn't already find it): https://github.com/hvacengi/KOS-StockCamera/blob/master/Example Scripts/libcamera.ks (I'll update the README to point at it too). In theory, that's exactly what the GUI and our methods are supposed to do. We query each engine to see if it's activated, and then ask it "what fuel tanks are you connected to?". And it should use the exact internal fuel flow logic, so it should show the exact value available to all currently active engines.

If our reading matches the stock in game GUI (with "stage only" selected) then it's the best we can do. We replicate the exact same system the UI uses, and short of writing our own more complicated system that's the best way we have to be close to correct. If it doesn't match the GUI though we need to fix it. Unfortunately we don't have any kind of a means to adjust the stage numbers, and it's my understanding that all kinds of crazy things happen to the stages if you try to re-arrange them in flight (though I've never tested it myself). I don't have a good solution, but I'll try to keep it in mind when I look at testing the stage resource info.

KOS-StockCamera A kOS addon for manipulating the camera from inside scripts. Initial public release. See README.md for documentation. Download: https://github.com/hvacengi/KOS-StockCamera/releases