dewin

I'm having no luck trying to get krpc-clientgen to build client libraries for my extension to kRPC. After bringing in all of the kOS and KRPC DLLs as dependencies, I get getting some variety of this error: (venv) D:\git\KIPC\KSP\test>D:\git\kipc\python\venv\Lib\site-packages\krpctools\bin\ServiceDefinitions.Exe KIPC .\Assembly-CSharp.dll .\Assembly-CSharp-firstpass.dll .\KSPAssets.dll .\KSPCore.dll .\KSPUtil.dll .\kOS.dll .\kOS.Safe.dll .\ICSharpCode.SharpZipLib.dll .\KIPCPlugin.dll Failed to load assembly '.\kOS.dll'. Could 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) 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. After fiddling around some, I managed to get this (more promising) error: Unhandled Exception: KRPC.Service.ServiceException: System.String[] is not a valid Procedure parameter type, in KIPC.ResolveVessels at KRPC.Service.Scanner.ParameterSignature..ctor(String fullProcedureName, ProcedureParameter parameter) at KRPC.Service.Scanner.ProcedureSignature.<ProcedureSignature>m__0(ProcedureParameter x) at System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext() at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection) at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source) at KRPC.Service.Scanner.ProcedureSignature..ctor(String serviceName, String procedureName, String documentation, IProcedureHandler handler, GameScene gameScene, String[] attributes) at KRPC.Service.Scanner.ServiceSignature.AddProcedure(MethodInfo method) at KRPC.Service.Scanner.Scanner.GetServices() at ServiceDefinitions.MainClass.Main(String[] args) which I then fixed, and am back to either my original error or it simply not finding the service. Any idea on might be able to fix this?

I had only mentioned it since poking at RoverDude's repository suggested that particular part of the project hadn't been updated in ~4-6 months and the changelogs suggested he changed to stock's implementation of buoyancy -- so it was possibly an oversight that it was included with the release. Easy enough to test though.

Did the release include FloaterTools? I'm on mobile so can't inspect it, but I suspect it's leftover from a previous version and you didn't delete the old folder first, given this changelog item: Conversion to stock buoyancy model for floaties

@hvacengi I think preventing the terminal lockout but keeping the nag message would probably be enough, though a developer build would work as well (and kOS is really easy to build). I was using baregrep/baretail/debug window most of the time anyways, and I'd like to assume that a mod developer is going to be looking at the log regardless.

@hvacengi It occured to me last night that there's one particular situation where this approach will fail: the case of a interoperability DLL that is designed to add capabilities to mod A if mod B is present. That said, before I learned 1.0.0 had the communication system, mine was one of those: KIPC depended on kOS and KIPC-KRPC depended on KIPC and KRPC... and I don't recall seeing nag messages for the latter (though that might have been because I was using KSPAssemblyDependency rather than just letting it fail to load) Maybe having the nags as an option and mentioning that in the documentation for addon developers might be a good way to go? (And then not disabling the terminal, unless that was removed)

Oh hey, I missed the Release Candidate in the middle of putting together my own release notes. I guess my dev build doesn't require someone to compile their own kOS build after all.

Super-early dev build is now available in the first post. If you ignore the bold text and complain that it doesn't work, you're in the wrong forum

I knew about the protocol buffers bit, and the big thing was that the structure of the data isn't necessarily known ahead of time. I think JSON shall suffice for now though.

I think he means something like: Mechjeb.dll would have Mechjeb as it is now, and Mechjeb-KRPC.dll would depend on both mods and would have annotated stubs that call the actual Mechjeb functions. I was originally doing that with KIPCPlugin and KIPCPlugin-KRPC.

That was what I ultimately resorted to as well, but kOS ended up adding a feature set that meant there was no reason to run my mod without KRPC so I went back to a single implementation. The design notes are actually way out of date. I've opted to just use JSON as a serialization mechanism and a normal message queue to more or less mirror kOS's new (not yet released) communications mechanism. Re: a dev build: It'd be nice to add to a future release, but don't fret making a build just for me: If I really want to do it I can always (temporarily) abuse reflection, and I don't want to end up in a situation where people need dev builds of other mods to try the (eventual) dev build of mine Oh, the other question I should have asked is: Is there a good mechanism to send arbitrary mixed-type data via KRPC? Right now I've resorted to JSON (much easier to use than my former idea of getArgumentTypes -> getIntArg, GetStringArg, etc.) or BSON if I can figure out how to make JsonFx do that correctly, but keeping things closer to native types for efficiency is always nice.

So, I'm working on a mod that aims to add a bridge between kRPC and kOS together for a variety of reasons. My forum thread is already outdated but has some information on the "Why", but I wanted to mention some of my headaches involving kRPC's API. One of the big hangups early on (before I ended up just splitting my mod into two assemblies -- and then after some changes it's back to one) was trying to figure out how to "optionally" use kRPC -- the current way of using attributes is simple but doesn't work so well if I'm using reflection. It would have been handy if there was an additional way to register with kRPC that could be done after startup. (It's no longer a concern for my project, but thought I might mention it). Right now, though, my main interest is finding out about connected clients: I haven't found a (non-private) mechanism to find all of the currently connected clients. Likewise, being able to register for the client events (OnClient{Disconnected,Connected}) would be handy. The kOS side of the bridge will allow targeting messages at individual vessels or kOS processors. I'd like to be able to mirror that on the kRPC side (with a message queue per connected client) if I can, otherwise it'll be a single queue on the kRPC side.

No Kerbal left behind. (This has cost me a looot of time, I'm the master of having just baaaarely enough dV to get back from the Mun and needing to reload several times to pull it off) No Kerbal left hungry. No nukes in atmosphere. No space junk in a planetary SOI (Sun SOI is fine) unless it is on a reentry or collision trajectory. This includes fairings and other parts that don't create 'real' debris. Satellites must have a plan for disposal, see "no space junk" Equal flight time between male and female Kerbals of a given role when the roster allows it. It doesn't have to be fun as long as it's interesting. It doesn't have to be interesting as long as it's fun. Building a RemoteTech network isn't fun, but is interesting. Building a RemoteTech network for the 10th time is neither fun nor interesting. Building a RemoteTech network for the 11th time but using fully automated craft with kOS or kRPC reapplies the "interesting" descriptor.

Over the last couple days I've been rewriting the serialization code (and implementing the deserialization code) to be a bit more modular and generally less terrible. I've also learned that the upcoming probably-tomorrow kOS release includes a inter-processor/inter-vessel communication bit, so I'm scrapping a giant portion of my plugin and rewriting it to solely be interoperability between kOS and kRPC... so all of the documentation that's listed here is most likely now wrong. On the bright side, this should drastically reduce development time.

Nope! I was using descriptive variables, not quite actual kOS code, and completely meant it as "replace this value with your current (or desired) true anomaly, this value with your argument of periapsis, etc.) You may want to use ship:obt:trueanomaly and ship:obt:inclination for consistency, or just use obt:* in all 3 cases (the 'ship:' is optional). Also, two months ago I didn't know any of the math either. I'm particularly proud of the latitude-at-anomaly function though -- other orbital formulae I found or derived from well-known published equations/etc somewhere, but I managed to figure out latitude entirely on my own. It's deprecated and undocumented, but some of my stuff is here -- mostly focused on orbital math. (lib_obt has the newest versions after i dropped the "create my own representation of an orbit" bits) https://github.com/dewiniaid/ksp-kos-scripts/commits/master

Since KSP doesn't have axial tilt, latitude is (IIRC): ARCSIN(position:y / position:mag) where position is your relative position to the planet. (If the magnitude of your position somehow is 0, latitude is technically undefined and you have bigger problems.) Latitude for a given true anomaly value is: ARCSIN(SIN(trueanomaly + argumentofperiapsis) * SIN(inclination)) True anomaly at periapsis is 0, at apoapsis is 180. Thus, you can do ARCSIN(SIN(180 + argumentofperiapsis) * SIN(inclination)) to get latitude at apoapsis without even needing to use POSITIONAT.

Heh, looking through my mod probably won't find much at this point anyways as it's not really at a functional level yet It'll be interesting to look at your inter-(processor,vessel) communication bits though; it might change how I approach the kRPC bridge -- particularly if I can just treat kRPC clients as a 'virtual' vessel of sorts rather than everything else that I'm doing. Some key differences I'm seeing poking at the github docs: I'm using a different mechanism for serialization than kOS's inbuilt one, so there are different restrictions on what constitutes a valid message. (Notable: Mine uses something like {"type": "vessel", "data": "vesselguid"} as its mechanism for representing everything except primitives, and can properly handle things like a particular list being referenced in multiple places (or referencing itself). The output is generally more compact than kOS's format) Parts are serializable in my implementation. I don't implement actual message queues to keep things simple and avoid 'leaked' messages in the case of a kRPC client never checking for them. Instead, a given processor has at most one inbound and one outbound message and mechanisms for atomically setting either field. A given processor can both "send" (setting its outbound message) and "send to" (setting another processor's inbound message), the two are separate queues. The kRPC side has no inbound/outbound message -- it communicates by examining the outbound field of other processors or setting their inbound fields. RT is ignored completely, but this is true for kRPC in general. In-game-wise, this can be explained as kRPC being additional processing power on the same vessel -- though one could totally "cheat" at remotetech with this (kOS from one ship -> kRPC -> kOS to ship far away/out of communications range with no latency). Now that I think about it more, I might just stash my current code somewhere and start from sort-of-scratch using the kOS API, focusing solely on the kRPC bridge (which was my original intent). I knew that inter-vessel/processor communication was on the kOS roadmap but had no idea it was going to be in this release. Oh, one convenience feature I'm seeing missing from the current kOS implementation: My implementation had a notion of a message ID or count of received/sent messages or whatnot -- mainly so that messages can be processed in the background(ish) by doing something like: ON something:messagerxcount { // changes every time we receive a new message. handleMessage(); } The only way I see to do that in the current implementation is to do ON messagequeue:length, but there's a lot of complexities in that particular case. (Also, a count of "packets" tx/rx would be neat anyways). Though now I almost wonder if a future version of kOS should have a proper event system. As I understand ON, it's examining an output every update and firing when it changes -- as opposed to a more passive "sleep until I'm awoken, event X wakes me up" system.

One of the new kOS features is proper support for external addons, in that other addons can now add structures that you can access from your kOS scripts. This means that rather than waiting for kOS to provide support for a mod, it is now possible for a mod to provide support for kOS (or a third mod that supports both). I'm actually working on a mod that takes advantage of this, with the primary goal of talking between kOS and KRPC. (Though it will probably include communication between kOS Processors as a freebie, and that portion doesn't require KRPC).

That'll teach me to not read the entire post before replying. Yeah. It's just plain wrong

The indicated time was UTC-5, not UTC. That said, if the actual time zone is Eastern Daylight Time (Eastern Standard Time is UTC-5), the US times are correct as listed and the other timezones are possibly off. If EDT isn't the origin time zone, then we'll have to wait for @Steven Madingto correct us

IIRC, KSP for whatever reason calculates ISP assuming g=9.82, rather than 9.81

I opted to do JSON serialization anyways with some customization; the greater part of the last couple days has been trying to get a JSON library to actually work with KSP. But now, I've got this: PRINT "--Running kIPC Test Script--". PRINT "Testing basic type serialization.". FOR value IN LIST(True, False, 42, 1.234567890987654321, 1e-17, 1e+17, "A String") { PRINT value + " => " + addons:kipc:serialize(value). } PRINT "Testing reference type serialization.". FOR value IN LIST(ship, core:part, body) { PRINT value + " => " + addons:kipc:serialize(value). } PRINT "Testing collections.". LOCAL s IS STACK(). s:push(1). s:push(2). s:push(3). s:push(4). FOR value IN LIST( LIST(1,2,3), s, QUEUE(1,2,3,4,5), LEXICON("only_strings", 1, "more data", 2), LEXICON("mixed", 1, 2, 3), LEXICON(9,8,7,6), LIST(LIST(1,2,3),LEXICON("foo", "bar")) ) { PRINT addons:kipc:serialize(value). } PRINT "Testing references in collections.". LOCAL foo IS LIST("foolist"). LOCAL bar IS LIST("barlist", foo). PRINT addons:kipc:serialize(LIST(foo, bar)). PRINT addons:kipc:serialize(LIST(bar, foo)). PRINT "Possibly crashing momentarily...". WAIT 5. foo:add(bar). PRINT addons:kipc:serialize(LIST(foo, bar)). PRINT addons:kipc:serialize(LIST(bar, foo)). Which produces this: --Running kIPC Test Script-- Testing basic type serialization. True => true False => false 42 => 42 1.23456789098765 => 1.2345678909876543 1E-17 => 1E-17 1E+17 => 1E+17 A String => "A String" Testing reference type serialization. SHIP("Test Rocket") => {"type":"vessel","data":"b422057f-e7de-4c1e-806f-6907e19f6e9a"} PART(kOSMachine1m,uid=4294806512) => {"type":"part","data":187191025} BODY("Kerbin") => {"type":"body","data":1} Testing collections. {"type":"list","data":[1,2,3]} {"type":"stack","data":[1,2,3,4]} {"type":"queue","data":[1,2,3,4,5]} {"type":"dict","data":{"only_strings":1,"more data":2},"keys":[],"values":[],"sensitive":false} {"type":"dict","data":{"mixed":1},"keys":[2],"values":[3],"sensitive":false} {"type":"dict","data":{},"keys":[9,7],"values":[8,6],"sensitive":false} {"type":"list","data":[{"type":"list","data":[1,2,3]},{"type":"dict","data":{"foo":"bar"},"keys":[],"values":[],"sensitive":false}]} Testing references in collections. {"type":"list","data":[{"type":"list","data":["foolist"],"ref":2},{"type":"list","data":["barlist",{"type":"reference","data":2}]}]} {"type":"list","data":[{"type":"list","data":["barlist",{"type":"list","data":["foolist"],"ref":3}]},{"type":"reference","data":3}]} Possibly crashing momentarily... {"type":"list","data":[{"type":"list","data":["foolist",{"type":"list","data":["barlist",{"type":"reference","data":2}],"ref":3}],"ref":2},{"type":"reference","data":3}]} {"type":"list","data":[{"type":"list","data":["barlist",{"type":"list","data":["foolist",{"type":"reference","data":2}],"ref":3}],"ref":2},{"type":"reference","data":3}]} Program ended. Notable here is: All of the more complicated types include enough metadata to reconstruct them, and... a list that contains itself can be properly represented without breaking the game due to recursion. (Fun fact: PRINTing that same list instantly crashes KSP).

@Steven Mading I'd be happy to do a build to save developer time. The mod I'm currently developing can't release until the next kOS release happens, anyways.

So I finally started playing with the kOS mod a couple of months ago, and started writing a comprehensive maneuver planning library for it. This hit a brick wall pretty quickly when I tried to implement an interplanetary transfer planner in it using a Kerboscript port of Alexmoon's Transfer Window Planner and encountered processing times of... about 15 minutes. Then I decided it was finally time to play with kRPC. Should be easy enough, I write Python professionally anyways. But then it occurred to me: I have a ton of existing kOS code that already works and I'd spend some time just rewriting it. kOS has some advantages over kRPC when it comes to craft control -- namely latency. I've started writing my first-ever KSP plugin to try to implement a bridge between the two. The timing couldn't be better either -- I discovered that kOS's external API support is so new, it's not even in a released version of kOS yet. So I've compiled that build of kOS myself from source (which hopefully won't be a requirement by the time I release, I hear kOS 1.0.0 is right around the corner). Note: The below developer build will NOT work without (not-yet-released) kOS 1.0.0. It should work with the latest release candidate in the kOS thread. Now includes client libraries (with thanks to @djungelorm for assistance) A beta build is available at https://github.com/dewiniaid/ksp-kipc/releases/ API documentation for this release can be located at https://github.com/dewiniaid/ksp-kipc/blob/v0.2.0-beta/doc/index.md Licensed GPLv3. Old history is spoilered below.

Heh, I use telnet (PuTTY) instead. From the draft documentation for my mod (spoilered for brevity):

I haven't downloaded this (and probably won't -- while I like it, it's not my style), but... If the part isn't named "ID-1-0-T Indicator System" or similar, I'll be disappointed. Other options could be PIKNIK ("Problem In Kerbal, Not In Craft/Capsule") or PEBKAC ("Problem Exists Between Kerbal And Capsule").