Schema/KRPC.cs(844,62): error CS0103: The name `ServicesList' does not exist in the current context

Workaround: manually rename it to Services_List

Documented here: https://github.com/djungelorm/krpc/wiki/SpaceCenter-Service#properties-6

C:\Apps\Python27\python.exe 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]
>>> import krpc
>>> ksp = krpc.connect(name='Launch to orbit')
>>> space_center = ksp.space_center
>>> vessel = space_center.active_vessel
>>> resources = vessel.resources
>>> print resources
<krpc.types.Resources object at 0x029C3A30>
>>> print resources.resource_names
Traceback (most recent call last):
  File "<console>", line 1, in <module>
AttributeError: 'Resources' object has no attribute 'resource_names'

Need to extend the node API to better support passing vectors.

Also Node.Vector only returns vectors in the maneuver reference frame. Should support other frames of reference.

For example, setting a maneuver node's burn direction to a given vector in a given reference frame.

Should be able to give more than just 0 or 1 parameter to an RPC

A problem with RPCs is that to wait until something happens, you have to actively poll for it. The inclusion of an events publish/subscribe system improve this - although this a feature for the far future and is quite a distraction for the core aims of this project.

The surface's velocity is not included when converting orbital vectors to the surface reference frame.

Add support for tuples

Add basic services:

• Simple autopiloting commands - e.g. execute manoever node, set heading
• Querying all sorts of vessel data such as resources, parts, atmospheric flight data...
• Manoever node editing commands
• Provide read/write access to object properties in the public KSP API (i.e. FlightGlobals etc.)

MonoDevelop gets an internal error ('unix transport error') in KRPC.Utils.Reflection.GetTypesWith

The following assertion fails in native code:
Assertion at class.c:5594, condition !mono_loader_get_last_error ()`

See 777e20c for temporary fix.

Translate, for example, SetHeading to set_heading in the client.

Change address and port from the UI

Design:

• Address is a text field with an adjacent check box for "any"
• Port is a text field for an integer
• Validate each keypress in the text fields so invalid characters don't appear
• Might need a workaround for Linux where text-input causes stage activation etc.

After stopping the server the main window doesn't resize to fit it's contents.

Add a checkbox to disable asking if new connections should be allowed.

Might be useful to provide this:
http://msdn.microsoft.com/en-us/library/hyb3xww8%28v=vs.90%29.aspx

Add proxy object support. Classes annotated with [KRPCClass] are made available to clients via a unique uint64 identifier.

Design:

• Methods in a class are annotated with [KRPCMethod] and they appear as a remote procedure call named ClassName_MethodName with an attribute Class.Method(MethodName) so that clients know its a class method (and not a procedure that happens to be called the same thing). These procedures take a uint64 object identifier as the first parameter, followed by the methods parameters.
• Properties in a class are annotated with [KRPCProperty] and appear as RPCs named ClassName_get_PropertyName and ClassName_set_PropertyName, with attributes Class.Property.Get(PropertyName) and Class.Property.Set(PropertyName) respectively. These procedures take a uint64 object identifier as the first parameter (followed by another parameter for the setter).
• Instances of a class can be passed as parameter values and return values. The type of the parameter / return type is uint64 (the unique id of the object) but the procedure has an attribute indicating what class the identifier refers to (e.g. ReturnType.Class(ClassName) or ParameterType(1).Class(ClassName))
  Could also provide helper classes in the to make implementing them in the server easier. E.g. a generic way of storing state.
• You can mix and match the above as you like, e.g. have a property whose type is a class.
• Construction of objects must happen in a some other procedure call that returns an instance of the object. You can't call a class' constructor directly. (Change this?)
• Destruction of objects is handled by the service code, NOT the server code. Whenever an object is passed to a client, a reference is kept to it in the ObjectStore class so that a client doesn't find that the instance magically vanishes. However, service code has the option of calling ObjectStore.RemoveInstance to allow instances to be garbage collected (and the service will need to make sure that calling this makes sense - i.e. that the client isn't expecting the object to exist)

Including visibility and position.

Visible should reset to true if Toolbar API plugin isn't installed - otherwise you won't be able to open the window.

Need to check that shutdown behaviour works properly.

E.g. exiting flight mode, crashing the vessel, ...

Allow services authors to define an RPC as a public static function that takes parameters of non-protobuffer types, and have requests automatically decoded to fit them.

Would need to attribute the RPC with the type of the request protocol buffer, e.g. KRPCProcedure[input=MessageType]

Currently any schemas must be put in the python client install directory as: krpc/schema/MySchema.py

Need to auto-generate these from the server, or similar.

"according to the description, you support only action groups 1 to 9. It would be nice to have support for all ten numeric action groups, as well as for the special action groups like gear or abort. (maybe map the latter to indices > 10 with an enum?)"

"the names on the wiki are out of date with the current release, still showing "Flight().VerticalSpeed" when it's actually "flight().vertical_speed""

A tool that takes an assembly for a service, and constructs a list of all procedures etc. to go in the wiki. Should make documentation easier and less error prone.

Need API for driving rovers.

On branch feature/wheel-controls

Allow overloading of procedures.

Why don't .Net 3.5 binaries work when loading KSP? Using the .NET Compact Framework 3.5 binaries appears to work... No idea why.

Should be able to pass null/None values between client and server.

For example, setting the heading for basic autopiloting to nothing from a python client:
Control.Heading = None

Remove Geometry.Vector3. Use tuples instead. This makes interfacing kRPC client code with libraries like numpy far less painful.

Should be in Pascals, not kilo-Pascals.

... in case people want to use it over the internet (but do so at your own risk!)

A service that lets you create windows and display info. Essentially exposing Unity's GUI commands as RPCs.

This is a bug with stock KSP. Is their a temporary workaround?

http://bugs.kerbalspaceprogram.com/issues/1230

On windows, the close button icon doesn't appear. The button is blank.

Scan the local network interfaces for their IP addresses, and populate a dropdown menu in the UI to set the server IP.

You should also be able to manually specify the IP address via a text field (for example, if scanning the interfaces doesn't find them all for some reason).

Add API for examining the parts of a vessel.

Implementation on branch feature/parts

Need a button next to each connection that can forcibly terminate it.

Report errors when starting the server in the UI

The server should pass C# documentation applied to kRPC procedures through to the client (e.g. to set the docstring for a procedure)

Can't be done by reflection - as the C# compiler strips out comments.
Could generate an XML doc file from the code and distribute that with the DLL.

Need support for passing collections of objects as parameters and return values.

Procedures on the server can have parameter/return values of type IList<T> or IDictionary<K,V>. The server then converts these collections to/form protocol buffer messages of type KRPC.List and KRPC.Dictionary to be passed on the wire. Additional type information required by the client to encode/decode these protobuf messages to native types (e.g. python list or dict) are retrieved from the server via the GetServices RPC (using procedure attributes).

Other notes:

• Need support for nested collections
• Restrict the type for keys to dictionaries to a sensible subset of kRPC types
• Needs to handle memory management for collections of instances of kRPCClass classes

Add properties to the services API so that the getter and/or setter for a field can be exposed through the RPC.

http://forum.kerbalspaceprogram.com/threads/69313-WIP-kRPC-A-language-agnostic-Remote-Procedure-Call-server-for-KSP?p=986127&viewfull=1#post986127

On windows, server does not clean up resources immediately when stop server is clicked. The address/port remains in use until some time later after which the server can be started again.

The following would add to the realism of the mod as a "mission control" mod:

• Limiting the number of RPCs executed per second (i.e. the computational power of the vessel)
• Rate limiting the bytes sent to/from the server (the communication bandwidth)
• Signal delay (communication latency)

And parameters for these last two could integrate with RemoteTech.

Simple types (e.g. string, float, int...) should be converted to protocol buffer objects automatically, so that client code doesn't have to include lots of boilder plate code to create the protobuf objects.

Display a confirmation box when start server is clicked and the server is configured to listen on anything other than the loopback device.

Allow enumeration types, both those defined in C# and in .proto files

Add a window that shows client activity. Should be useful for debugging scripts.

Design:

• Tabbed window, with one tab per client.
• When clients disconnet their tab remains, but can then be closed.
• Each entry in the log is a one line description of the RPC with a +/- to show/hide more details of the input/output data
• Highlight RPCs that caused errors
• Timestamp the logs