dewin

Didn't see it mentioned here, but I have one of these for Elite: https://www.amazon.com/Thrustmaster-T-Flight-Hotas-Flight-Stick-Pc/dp/B001CXYMFS Seems like a good introductory HOTAS. It could stand to have another hat switch and/or a couple more buttons, but for something not much more than a Xbox controller in price it's totally worth trying out if you're not sold on the idea entirely. Plus, it's not made by MadCatz, who have some pretty severe QC issues. (See: Saitek before and after MadCatz bought them.)

I'm actually toying with an extension to streams that allows them to trigger callbacks. This would eliminate needing to examine their values in a loop and instead have a function called whenever their value changes, so it would improve performance clientside as well. More about this is in this issue here and the PR that references it. (Python-only for now). I'd almost say take the dynamic one by default since the main reason for wanting generated Python code (and probably Lua/etc as well) is for documentation/inspection/code completion purposes. In fact, it may be sufficient to generate _just_ the documentation -- i.e. a series of dummy classes and methods with docstrings but no actual code.

Is it possible to generate client libraries for the dynamic languages (e.g. Python)? That would aid in things like inspecting in certain IDEs (PyCharm comes to mind) for code completion and whatnot.

Take a look at the docs regarding Reference Frames. Namely, the default reference frame for Flight is the vessel's surface reference frame. The origin of this reference frame is located at the origin of the vessel. In otherwords: from the vessel's perspective, the vessel will always have 0 velocity. From Kerbin's perspective, that might be different. And from Kerbol's perspective, that will be very, very different.

Version 0.2.0 beta is now available; links in the OP. Added client libraries for C#, C++ and Java. Added preliminary support for CKAN and KSP-AVC. This release does not include MiniAVC and does not use the internet to check for version updates, but other providers of MiniAVC/KSP-AVC might Barring any major issues, this is the same version that I'll have in the Release thread -- I'm just delaying that until kOS's final release.

This is precisely why I didn't post the recompile. Well, that and I'd have to actually grab 0.20.1 to do it. The reason I compiled kOS from source in the first place is for my own addon.

I had no trouble building kOS in VS2015, you'll just need to update the assembly references to point at the relevant files in KSP\KSP_x64_Data\Managed. And yes, the simple recompile should fix timewarp while you wait for 1.0.0. I opted to not post my build here to avoid complicating things for the developers in the middle of the 1.0.0 release, but I did consider it. (Timewarp broke because Squad added a new "optional" parameter to the function, but optional parameters in MSIL aren't actually optional at runtime -- they merely instruct the compiler what value it should put there instead.)

If not already present, it might be good to add the boundary altitudes for flying low/flying high/space low/space high as well. I have an open PR to KER that does this here, feel free to steal from it.

There's an IntelliJ kOS syntax plugin out there somewhere, among others -- see https://github.com/KSP-KOS/EditorTools

You're using . (dot) instead of : (colon). Common mistake, I do the same thing all the time. You can also just do IF NOT mod:HASDATA {

And still no-go, same "an attempt was made to load an assembly from a network location error as before: (venv) D:\git\KIPC\dlls>krpc-clientgen cpp KIPC --output-defs defs.json --ksp D:\git\KIPC\KSP KRPC.SpaceCenter.dll kOS.dll kOS.Safe.dll JsonFx.dll ICSharpCode.SharpZipLib.dll KIPCPlugin.dll Error: b"Failed to load assembly 'D:\\git\\KIPC\\dlls\\kOS.dll'.\r\nCould not load file or assembly 'kOS, Version=0.20.1.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)\r\nAn attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.\r\n" ... oh. But it seems to be giving correct output if I completely ignore all of the dependent assemblies, using. So problem solved! (still no idea why it can't load kOS though) krpc-clientgen cpp KIPC --output-defs defs.json --ksp D:\git\KIPC\KSP KIPCPlugin.dll

Will give that a go tonight. If all goes well, I'll have a proper release ready.

Do you mean krpc-clientgen? I tried that originally and went to calling servicedefs directly to to eliminate possible causes, but I've had no luck either way. Discovered that there's also a krpc-servicedefs (hmm), and same result: (venv) D:\git\KIPC>krpc-servicedefs KSP\ KSP\GameData\kOS\Plugins\kOS.dll KSP\gamedata\kos\Plugins\kOS.Safe.dll KSP\gamedata\kos\Plugins\ICSharpCode.SharpZipLib.dll KSP\GameData\KIPC\Plugins\KIPCPlugin.dll Error: b"Failed to load assembly 'KSP\\gamedata\\kos\\Plugins\\kOS.Safe.dll'.\r\nCould not load file or assembly 'kOS.Safe, Version=0.20.1.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)\r\nAn attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.\r\n"

I have. Either it doesn't find the service (if I fail to reference KOS), or it complains about the KOS DLL: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information. My passing KRPC.dll along was in efforts to try to get things to work. (But I also use KRPC.SpaceCenter); at one point I passed it every single DLL I had in gamedata.

You might also consider Scott Manley's KSP videos, including his tutorial series starting here (updated link) They're a bit dated but the idea should be the same