hvacengi

Do they all cite KSPAPIExtentions being the issue there? Cause that dll should no longer be valid for KSP 1.1.x, the functionality was moved into KSP proper. That one should be OK to delete the dll. I'm aware that the nag messages make the cpu inoperable. That was intentional design, with unexpected side effects if there are conflicts with out of date mods (or with working mods that give an error anyways as shown above). We will be evaluating how to handle these errors.

I don't know that I'd bother RoverDude with that. It looks like KSP is able to load the dll, I'm not really sure why kOS is not. The dll appears to handle the part module to let the inflatables float in water, so there's a chance that simply deleting the dll won't have a significant effect on your own gameplay, but I should figure out what is causing the error.

I think I'd be inclined to essentially lock the nag message portion to the DEBUG build, and instruct addon developers that they should only use the DEBUG build to test their addon. There is also an option to make the nag messages appear once and only once per KSP load, in which case a user may be annoyed by the error the first time but it would still allow them to use kOS by simply cycling the power. I've also experimented with making a kOS specific debugging window that would allow us to display the messages to the user without necessarily breaking execution. But either of the first two options shouldn't cause any delay in release, so I'd lean that way for the time being.

As part of the new addon code, kOS scans all mod dlls for addon components. The nag messages there mean that kOS was unable to load the dll due to errors. When I enabled the feature, I wanted to make sure that addon authors were able to see when their mods mailed to load. In my testing, I did not see any "current release" mods that caused the nag messages to appear. What version of "SrvPack" are you using, and does it officially support KSP 1.1.3? If it turns out to be an issue that "working" mods cause these nag messages, we may need another way to alert users to addon loading errors. We may need to modify the alert anyways even if the errors are only with mods that don't load properly, to avoid issues surrounding a KSP update, or a mod that "mostly" work with the current version.

Release Candidate v1.0.0-pre-1 Download may be found here: https://github.com/KSP-KOS/KOS/releases/tag/v1.0.0-pre-1 This version will not be available on Curse, Spacedock, or CKAN. Please be sure to report any issues you find on the github issue tracker. Documentation of pending changes may be found here. WARNING: This is a testing released based on the current develop branch. The release definitely contains bugs that have not yet been fixed, and may have bugs we are not yet aware of. There is a small risk of loosing data both in game and in the script archive. Please make sure to backup your save file and script files before installing

Inter-processor and inter-vessel communication is included as part of this next release. I'm sorry that I haven't had any opportunity yet to look at your mod and see if I have any useful comments or pointers, but I do mean to do that soon. I also have a sample addon prepared that I intend to make available so that other modders can see the recommended workflow. I just need to add a simple reflection interface so that people won't have to dig through the really complicated IR or RT addons to understand how to use reflection to access an api. Most of those items are not specific to v1.0.0. While we're happy to discuss them, the new features will be the main focus of the stream. If we don't have few enough questions that we can kind of pick a direction, we'll definitely keep that list in mind though. If we don't get to it, Stephen tries to stream regularly so ping us with a reminder and I'm sure that he can find a way to fit it into one of his other streams. I'm scheduled for 5PM (17:00) EDT (UTC-4, local time for me), 4PM (16:00) CDT (UTC-5, local to Stephen), 9PM (21:00) UTC. Feel free to extrapolate the other time zones from that. I'll ping him in chat to update it.

Odd, your post some how crossed mine... even though I refreshed before posting. Anyways, I'll respond to your comments, but my above post still applies. This is a result of the use of Generics. Essentially C# does some fancy things to dynamically create the type definition for the dictionary based on the Type data that was passed to it. So our code accesses a `Dictionary<string, int>` which the compiler then defines as `System.Collections.Generic.Dictionary`2` Actually, I added some debugging statements and this is not the section of code that throws the error. The applicable code is here: https://github.com/KSP-KOS/KOS/blob/develop/src/kOS.Safe/Compilation/ProgramBuilder.cs#L235 You'll notice that the code section you cited is actually protected by checking for an empty string before using it as a key, and it checks the dictionary to make sure it contains the key before attempting to use it. The line I cited has no such protection, and can only be triggered in very rare circumstances (like using `unlock all.` with functions). I almost added a better error message here about 6 months back, but got busy working on other things including fixing another bug that was causing this same message. Since this if condition isn't the problem, an else won't fix it. More importantly, an if statement does not always need an else. In our particular instance, we have an implicit else: "if this condition is true, continue to the next loop." which will skip the section of code that follows "throw an error". Because "continue" skips the rest of the loop, it's the same as saying "if this condition is true, continue to the next loop, else throw an error". And there are plenty of practical times where no else condition is required at all. "create a new variable x equal to 1, if the current time is after noon, set x equal to 2" is perfectly valid. I wanted to take a moment to point this out specifically because kOS tends to attract, and focus on, new programmers. I don't want to have a bunch of people now think that they absolutely need an else for every if. I'm gonna find a whole lot of user scripts that read `if true { doSomething(). } else { doNothing() }`. I appreciate that you were walking through our code, and thought you found the error, but speaking in general absolutes can often be taken out of context and confuse others.

Well, I found the problem. I don't know why it's true, but `unlock all` doesn't appear to do anything, but it screws up function declaration. It literally compiles as a `NOP` opcode, which is essentially "don't do anything, just move to the next instruction". I'm pretty sure it was supposed to go away at the same time as `unset all`. That being said, it is still documented as working. If you simply exit the program, there is no need to make this call anyways, since all flight controls automatically unlock upon returning to the terminal. Basically, remove the one reference to `unlock all.` from inside the `stop` function, and you should compile. Oh, and never use it again! We'll have to update the docs, and kill it once and for all.

I'm not the one who implemented our use of KSP control locks, but that's how kOS attempts to lock out passing characters to another mod. We set the input lock to everything except targeting: InputLockManager.SetControlLock(ControlTypes.All & ~ControlTypes.TARGETING, "kOSTerminal"); So if Camera Focus Changer simply looks for a defined lock (anything except Target) before registering the input, it should fix kOS (or any other mod that uses the stock lock system) key presses from passing through to your mod: if (!InputLockManager.IsLocked(ControlTypes.ALL_SHIP_CONTROLS)) { if (Input.GetKeyDown(actionKey)) { // the rest of your code } } While your at it, if you could add a hook somewhere so that kOS could call a method like "CenterCameraOnPart(Part part)" then we could interact directly with your mod too!

Well... they were new in v0.19.0 but I'm revising where exactly in the documentation `hasnode` is because it wasn't shown on the maneuver node page itself (just the bound variables page).

While we haven't been able to do it for everything, we try very hard to offer a way to predict an error condition where it's within our control. That's why we have added things like `hassuffix`, `hasevent`, `hasnode`, and `hastarget`. When you find one that we don't currently make available, take a look through the github issues and create a new one if it's not already on our radar. The goal is to make it so a user never is forced to encounter an error that they can't predict. There are a lot of things that are limited to the active vessel, so I have a number of functions that simply open with `if ship = kuniverse:activevessel`.

The way I envision it is that config:safe would still control the way kOS responds to these values, but that the scalar would have additional suffixes: set config:safe to false. set x to 1 / 0. // does not throw an error print x:isvalid. // prints false print x:isinfinity. // prints true print x:isnan. // prints false That way existing functionality isn't really changed, but disabling safe mode is actually useful. Right now, if you disable safe mode you just kind of have to hope you don't set a KSP variable to an bad value, which isn't really a good alternative.

It doesn't sound like it's an issue from the thrust suffix anyways, so no need to make it on our account. I should have also added the qualification that I could create the issue as well, my first choice is just to have the person who found the issue be attached to it so that you can get updates and we can ask you additional questions if needed. So far it has been a conscious decision to not include a form of "null", the rationale being that "null" can often complicate scripts for people just learning how to program. Null checks wouldn't really help here anyways. What I do want to include is a way to determine if a scalar is "Valid". Right now, kOS is set to a safety mode by default where it will not allow "NaN", or +/-"Infinity". This is because KSP has had issues with crashing if you do things like setting the throttle to Infinity or NaN. Since there currently isn't a way to test the validity yourself, you can't really turn off that config setting without risking the crash. If you could check `number:isvalid` before using it, that would allow you to use these values for something useful. The same issue from above applies though, this is a substantially more complicated issue for beginning programmers. The line you showed looks to me like it's essentially a quadratic solver. In my own landing script I found that some component of the equation can force the square root calculation negative. I'm not sure if it's an issue with floating point precision, or an issue with some components being out of sequence with the physics frames. But I simply wrapped it in a `max` function return (-b + sqrt(max(b ^ 2 - 4 * a * c, 0))) / (2 * a). [...] return (-b - sqrt(max(b ^ 2 - 4 * a * c, 0))) / (2 * a). See the instructions for finding your log file. From a quick glance at your script, it can't be the same exact error message since it appears you now have defined "arrived". Whatever variable it is that kOS says it doesn't recognize, search for that name in your script and make sure it is being set before you try to access it. We will release as soon as possible, but we are in the middle of wrapping up a rather large update already and are planning on releasing the fix for KSP 1.1.3 at the same time.

Could you please post an issue for us on github so that we can make sure it's on our checklist for the next release?

Without having the error log I can't comment directly. But that message is usually shown when you have naming conflicts between functions and variables, or you haven't declared a function. My best guess is that you have an issue due to calling `arrived(goal)` and `arrived(point)` while I don't see any definition for a function or delegate named `arrived`.

Huh... yeah. Maybe I need to increase my ADHD med dosage. Working on the update, I have 2 things on my docket before getting to the IR pull request, but we're working towards a release since we've added a number of features that got skipped in the last two releases.

While it is not written as a built in function, printing the ascii "BEL" character will result in a "beep". I have a wrapper function written like this: function beep { print char(7). } Sorry about the delay in response. Apparently I missed the post.

Some one is working on that, but it has proven to have some complications. You can find it both at the issue and the pull request: https://github.com/KSP-KOS/KOS/issues/1596 https://github.com/KSP-KOS/KOS/pull/1628

Can you provide additional details. When you say that it doesn't drive to the "waypoint", do you mean it doesn't drive at all, it drives the wrong way, it goes in a circle, or it flys to the Mun instead (OK, so that last one isn't very likely... ). Have you tried using `print` statements to determine what the outputs of your PID's are doing? I know you said the selection code works, but have you verified using vector draws that you have the actual correct position not just a valid point? EDIT: I forgot to include my obligatory remark about lock: don't repeatedly call locks within a loop. A lock by definition will automatically update itself, and specifically within steering locks you add extra overhead because it forces additional calls to the function `toggleflybywire` (which you should not call manually btw). If you want to update your lock from within a loop you should instead lock to a variable, and then set the value of that variable from inside your loop.

kOS has a pending request to update IR to use the API for 2.0+. It will be included in the next kOS update, which we hope to do soon.

There have been discussions recently about providing a way to get this information from an inactive engine. There are potential benefits for delta-v calculations, but it presents some additional issues both in backwards compatibility and fuel flow handling. It simply hasn't been our highest of priorities.

Currently engines always report an ISP and thrust of zero if they are not currently active. I'm guessing you have not yet staged them on.

When you say you labeled the probe core, do you mean you modified it's kOS name tag? If so, you do want to use partstagged suffix instead. The partsnamed suffix relies on the internal name that KSP uses in the cfg file. But I suspect this is not the root of your issue, because kOS would have thrown an exception if you tried to access an item in an empty list. If I were to guess, the issue is with the deploy command or the hasdata suffix. Try adding some debug prints through your code to check the progress. For example, you could add the line "print "deploying science!". " before calling deploy, that way you know that you reached that part of the code. I don't know what science experiment Sounding Rockets supports on the probe core, but I can probably look at some point. But if you're blocking at that point, you never reach the code that is supposed to deploy the parachutes.

Awesome! Explicit support won't be a problem. We already have specific support for Orbital Science anyways. Thanks for keeping us posted! In the future, I will probably want to pick your brain about how to let kOS get the map data out of SCANsat, as that's been an "issue" on our road map for a while too.

The first parameter of method.Invoke is the instance variable. So if your method is static, it accepts a null instance. In your particular case (only a single MonoBehaviour loaded at any given time), you have two options: expose a static method which itself will make the call to the instance, or find the instance using MonoBehaviour.FindObjectsOfType. Either way, you really want to store the MethodInfo in a static variable on the class, so that you don't need to do a reflection walk every time that you call the method. In general, reflection itself is expensive. There are some conflicting reports on exactly which style of invocation is the least expensive, but you save a lot of time by not constantly having to call GetTypes and GetMethod. Static methods will be far easier for the reflection wrapper, because they don't need to store and refresh the instance. If you use the instance method, here is how you would set up the method invokation. // you should store these values in static variables and only initialize // them once in OnStart or in an initiazation check loop. AssemblyLoader.LoadedAssembly GF = AssemblyLoader.loadedAssemblies.SingleOrDefault(a => a.dllName == "Gameframer"); Type PublicInterfaceType = GF.assembly.GetTypes().FirstOrDefault(t => t.Name == "GFPublicInterface"); MethodInfo captureNewEventMethod = PublicInterfaceType.GetMethod("CaptureNewEvent"); // if your behavior is recreated every scene, you'll need to refresh this // reference. I'm assuming the GFPublicInterface itself is the behavior, // but if it isn't you'll have to use reflection and fields or methods on // the behavior to get the actual instance. object PublicInterfaceInstance = MonoBehaviour.FindObjectsOfType(PublicInterfaceType).FirstOrDefault(); // make an API wrapper function to reference the above method public void CaptureNewEvent(string name, string description) { if (PublicInterfaceInstance != null) { object[] parametersArray = new object[] { name, description }; method.Invoke(PublicInterfaceInstance, parametersArray); } } // you can do the same thing with fields and properties through reflection, // but for properties you will get references to the set and get methods. Honestly, you don't need to go through the trouble of writing the whole reflection wrapper just for my sake. The modifications I'm making to kOS mean I only need public methods on your classes instead of being tied to reflection. So kOS will be able to simply use your GFPublicInterface class directly. But as long as you're writing it, the reflection wrapper should make life easier for other modders. I'll look to see if I can find a simple example of another reflection API for you to look at (both RemoteTech and InfernalRobotics are great implementations, but they're way more complicated than what you need). It would be very useful if you defined the KSPAssembly attribute in your "AssemblyInfo.cs" file. That helps other mods set yours up as a dependency. For kOS it looks like this: [assembly: KSPAssembly("kOS", 0, 20)]