[1.8.x to 1.12.x] kRPC: Remote Procedure Call Server (v0.5.1, 2nd March 2023)

[djungelorm]

Would be good to check if the setup script is broken. Although it's more likely to be an issue with your python installation, as the only thing the setup script does is pass install_requires to setuptools. How did you install protobuf 3.0.0-alpha-1?

I just tried installing krpc (on Linux) via pip and manually using setup.py with protobuf 3.0.0a1 on my system and it automatically updated it to 3.0.0b3. Maybe your python packages are a bit broken?

[artwhaley]

Protobuf was installed when I installed the old krpc python client...  I used pip following the old instructions.  

I just attempted to install via pip and it stalled at the os.link error.

C:\Python27>pip install krpc
Collecting krpc
  Using cached krpc-0.2.0.zip
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "c:\users\art\appdata\local\temp\pip-build-8bek4b\krpc\setup.py", line 7, in <module>
        del os.link
    AttributeError: link

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in c:\users\art\appdata\local\temp\pip-build-8bek4b\krpc

C:\Python27>

Would you like me to uninstall and reinstall python and try fresh? 

 

Edited January 26, 2016 by artwhaley

[djungelorm]

I've fixed the os.link bug and added a new release on pip (version 0.2.0.post1)

I've tested installing it on my windows system and it now works. It also successfully downloaded the correct protobuf dependencies.

If installing that doesn't work, then yes it might be worth trying reinstalling python.

Edited January 26, 2016 by djungelorm

[artwhaley]

That worked perfectly!   "pip install krpc" uninstalled the protobuf alpha and grabbed the beta and everything is fine!  Sorry for the hassle!

 

Art

[djungelorm]

Sweet!

It's no hassle at all. Good to get feedback! There are so many languages and tools involved in this project it's quite a fun challenge to get everything working across different systems!

[djungelorm]

On 1/26/2016 at 4:22 AM, Antipaten said:

A small rocket is around 30 parts and a large is around 100. I get short "red lag" even without clients connected and no phys acceleration. Without the mod i can use 2x phys acceleration with green figures for the same (low part count) ship.

Hopefully this will sort itself out when KSP 1.1 is released and we get the multihreading Unity5. Single threading is a real P.I.T.A as it is virtually impossible to throw better hardware on performance problems. I just wondered if anyone had encountered it and knew if I've done something silly in the settings. They are pretty much vanilla except for starting the server automatically and auto accepting clients. I didn't notice the lag until I really tried running the game for real using my control panel. The panel emulates joysticks for input to the game and only uses kRPC for reading fuel levels, acceleration, atmospheric density and mach number from the game every 200 ms.

I'm having trouble reproducing your issue I tried flying the stock Dynawing (108 parts) whilst a python script was connected to the server calling KRPC.GetStatus once every 200ms. The framerate indicator was always green and it averaged ~57 fps (according to the debug menu). I only had the kRPC mod installed and used the default server settings. I saw the same framerates when running kRPC with no clients connected and also without kRPC installed.

Do you have any mods other than kRPC installed? And could you send me your 100 part rocket and python script that's causing issues so that I can try and reproduce the problem?

Edited January 28, 2016 by djungelorm
typo

[artwhaley]

Noobish question of the day - 

The next thing I'm trying to figure out...  is how to get a kRPCService I've created to be accessible from the c# client library?  I've linked my dll as a resource for the project, just as I have with KRPC and the SpaceCenter dll, but my service is not accessible from my Connection object?  It's accessible from the Python library just where I'd expect it.  Is there something I need to do namespace wise, maybe?  

[djungelorm]

Not a noobish question at all!

Getting services to be accessible from the python and lua clients is easy, as these clients interrogate the server to see what services are available and automatically create all the services classes and methods. The C# and C++ clients are different. C#/C++ code needs to be generated from the service.dll and compiled and linked into your C#/C++ project along with the client library.

All the tools needed to do this are in the main repo - but they are all tightly bound up in the Bazel build system at the moment. I'll see what I can do in terms of providing an easy-to-use code generator.

For now, if you like you could send me your service.dll and I can generate the required C# code for you?

[artwhaley]

Well, then I better test it thoroughly with Python before I bother you with that!  Who knows, you may have a code generator before I think my code's worth having you deal with by hand.  Thanks as always!

[Kerbart]

The 0.2.0 version doesn't load on my KSP. Here's what I see in the log (it's Greek to me though)

[LOG 08:04:06.321] Load(Assembly): kRPC/Google.Protobuf
[LOG 08:04:06.322] AssemblyLoader: Loading assembly at C:\Users\Bart\Documents\Kerbal Space Program (modded)\GameData\kRPC\Google.Protobuf.dll
[LOG 08:04:06.329] Load(Assembly): kRPC/KRPC
[LOG 08:04:06.329] AssemblyLoader: Loading assembly at C:\Users\Bart\Documents\Kerbal Space Program (modded)\GameData\kRPC\KRPC.dll
[ERR 08:04:06.332] Failed to load assembly C:\Users\Bart\Documents\Kerbal Space Program (modded)\GameData\kRPC\KRPC.dll:
System.UnauthorizedAccessException: Access to the path "C:\Users\Bart\Documents\Kerbal Space Program (modded)\GameData\kRPC\KRPC.dll" is denied.
  at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in <filename unknown>:0 
  at System.IO.FileStream..ctor (System.String path, FileMode mode) [0x00000] in <filename unknown>:0 
  at AssemblyLoader.LoadExternalAssembly (System.String file) [0x00000] in <filename unknown>:0 

I have no clue what would cause access to the file to be denied; especially since the protobuf dll loads just fine.

EDIT:

Removed kRPC from the Gamedata folder, copied it back in. Removed all "read-only" flags just for good measure.

Better but now I have the dreaded Protobuf problems...

EDIT AGAIN:
After downloading the Protobuf 3.0 b2 wheel file and "manually" installing it with pip, things work fine!

Edited January 28, 2016 by Kerbart

[djungelorm]

Yep you found a bug. Looks like the permissions in the zip file are set to read only. Will fix that in the next release.

Why ksp can't load a read only DLL I have no idea - surely it doesn't want to modify it!?! 

[Kerbart]

2 minutes ago, djungelorm said:

Yep you found a bug. Looks like the permissions in the zip file are set to read only. Will fix that in the next release.

Why ksp can't load a read only DLL I have no idea - surely it doesn't want to modify it!?! 

Might be worth reporting to Squad. I agree that the DLL being read–only should not be an issue. Not sure why it caught my eye but I'm glad I have kRPC back in working order!

[troyfawkes]

AutoPilot PID question!

I'm struggling with the autopilot at the moment. The default values cause my crafts to flip around like lunatics when looking to point at a vector. I've been fiddling with the values as well to try to find something reasonable, and it's just not going super well. I was wondering if anyone had any PID values that work for them?

It's kind of silly that my biggest issue isn't calculating an orbit, but rather stopping insane auto corrections on just pointing the right way :'(

[Kerbart]

Hey @troyfawkes, I think it's better to post that question in the new thread about using kRPC, so this thread can stay focused on development issues. It's a fairly new thread, so as far as I'm concerned you're forgiven for posting it here... for now.

Edited January 29, 2016 by Kerbart

[Antipaten]

On 1/28/2016 at 5:46 AM, djungelorm said:

I'm having trouble reproducing your issue I tried flying the stock Dynawing (108 parts) whilst a python script was connected to the server calling KRPC.GetStatus once every 200ms. The framerate indicator was always green and it averaged ~57 fps (according to the debug menu). I only had the kRPC mod installed and used the default server settings. I saw the same framerates when running kRPC with no clients connected and also without kRPC installed.

Do you have any mods other than kRPC installed? And could you send me your 100 part rocket and python script that's causing issues so that I can try and reproduce the problem?

I have a few mods but I uninstalled all the graphics intense ones and lowered the graphics settings. The save contains quite a few satellites and stuff but I mainly asked because there was a marked difference between when kRPC was installed and when it was not and wanted to know if it was a common problem.

I will run a more systematic testing on a clean KSP installation with the latest version of kRPC before I'm ready to cry bug for real. :-)

[artwhaley]

@Antipaten , I'm sorry to not have a better answer for you on everything - I just really haven't noticed much performance hit at all and so don't have a clue where to start on figuring out why you do. Those are reasonable ship sizes...  I wouldn't think the other craft in the save file would affect you with kRPC and more than without...  If you can narrow it down to a conflicting mod or two, I'm happy to try to duplicate it, then start looking at the code to see if I can help find the offensive routines!  The game's framerate is probably a good number to record during your tests, so you can quantify the amount of slowdown you're seeing as you remove mods?   What OS are you on?  

If you haven't upgraded to the 2.0 version of krpc, you might want to do that before trouble shooting...  I don't think anything that will greatly affect processor load has changed, but most of us doing troubleshooting with you will be on the new version so you may want to be upgraded, and who knows - it might just magically work better with the new version and new protbuf.  I don't know if the downloads are fixed yet - so if you have trouble with the new version and python, the secret seems to be installing the python library via pip rather than the setup.py file so that protobuf gets updated too.  Though djungleorm may well have updated the downloads too, so you might be able to ignore me on that one.  

 

[Antipaten]

10 hours ago, artwhaley said:

@Antipaten , I'm sorry to not have a better answer for you on everything - I just really haven't noticed much performance hit at all and so don't have a clue where to start on figuring out why you do. Those are reasonable ship sizes...  I wouldn't think the other craft in the save file would affect you with kRPC and more than without...  If you can narrow it down to a conflicting mod or two, I'm happy to try to duplicate it, then start looking at the code to see if I can help find the offensive routines!  The game's framerate is probably a good number to record during your tests, so you can quantify the amount of slowdown you're seeing as you remove mods?   What OS are you on?  

If you haven't upgraded to the 2.0 version of krpc, you might want to do that before trouble shooting...  I don't think anything that will greatly affect processor load has changed, but most of us doing troubleshooting with you will be on the new version so you may want to be upgraded, and who knows - it might just magically work better with the new version and new protbuf.  I don't know if the downloads are fixed yet - so if you have trouble with the new version and python, the secret seems to be installing the python library via pip rather than the setup.py file so that protobuf gets updated too.  Though djungleorm may well have updated the downloads too, so you might be able to ignore me on that one.  

 

Thanks a lot. I will try the new release on a clean install and see if it works and if it does, I'll add my other mods i priority order. It may take a while though as I'm taking a break from KSP and my simpit at the moment, playing some Path of Exile while recovering from a couple of months of soft and hardware debugging. :-)

[Kobymaru]

Hi! In the python client, when I try to read, conn.space_center.active_vessel.orbit.speed, the value always stays the same, even if in KSP the speed changes.

Is this a bug or did I misunderstand something?

 

Edit:

Both of these work, however:

 

vessel.flight(vessel.orbit.body.non_rotating_reference_frame).speed
np.linalg.norm(vessel.flight(vessel.orbit.body.non_rotating_reference_frame).velocity)

Edited January 31, 2016 by Kobymaru

[djungelorm]

8 hours ago, Kobymaru said:

Hi! In the python client, when I try to read, conn.space_center.active_vessel.orbit.speed, the value always stays the same, even if in KSP the speed changes.

Is this a bug or did I misunderstand something?

 

Edit:

Both of these work, however:

 

vessel.flight(vessel.orbit.body.non_rotating_reference_frame).speed
np.linalg.norm(vessel.flight(vessel.orbit.body.non_rotating_reference_frame).velocity)

It should match what's shown in the navball (in orbit mode), so sounds like a bug. Will investigate.

[djungelorm]

8 hours ago, Kobymaru said:

Hi! In the python client, when I try to read, conn.space_center.active_vessel.orbit.speed, the value always stays the same, even if in KSP the speed changes.

Is this a bug or did I misunderstand something?

For me, it always returns 0. They must have changed something in KSP since I implemented it... The code was using Orbit.orbitalSpeed. Changing it to use Orbit.vel.magnitude (as suggested on the community API docs) appears to fix the issue. Here's a link to KRPC.SpaceCenter.dll with the fix applied:

https://github.com/djungelorm/krpc/files/111770/KRPC.SpaceCenter.dll.zip

Let me know if that works for you.

[Kobymaru]

10 hours ago, djungelorm said:

Let me know if that works for you.

Thanks, it works now!

[djungelorm]

Version 0.2.1 has been released!

Here is a summary of the changes:

• Added streams support to the C# client. Details here: http://djungelorm.github.io/krpc/docs/csharp/client.html#streaming-data-from-the-server
• Added functions to get the surface/bedrock altitude/position vector at a given latitude/longitude on any celestial body: http://djungelorm.github.io/krpc/docs/python/api/space-center/celestial-body.html#SpaceCenter.CelestialBody.surface_height
• Fixed vessel.orbit_speed always returning 0
• krpc-clientgen: a tool for generating service stub code needed by 'static' clients (currently the C++ and C# clients). Useful if you want to write your own services (@artwhaley!) Details here: http://djungelorm.github.io/krpc/docs/extending.html#generating-service-code-for-static-clients
• The C++ client no longer requires boost. It uses the standalone ASIO library for networking instead.

Edited February 11, 2016 by djungelorm

[artwhaley]

Awesome!    You're really cranking out the greatness lately!  Keep it up and shout if you think of things you can use help with!  

[djungelorm]

49 minutes ago, artwhaley said:

Awesome!    You're really cranking out the greatness lately!  Keep it up and shout if you think of things you can use help with!  

Thanks! Feel free to tackle any of the issues on the github issue tracker I'm currently working on adding streams support to the C++ client, and a Java client.

If you (or anyone else!) have any experience with autopilot PIDs, that is something that needs work. I had a go at using the autopilot code from mechjeb (a long long time ago...) but could not get my head around it. Their code is a bit of a mess and quite hard to understand. So I ended up rolling my own. It works OK, but needs manual tuning of the PID parameters. It would be good if we could add some auto-tuning to it - somehow based on available torque and moment of inertia of the vessel I guess? The code is here: https://github.com/djungelorm/krpc/blob/master/service/SpaceCenter/src/Services/AutoPilot.cs and here: https://github.com/djungelorm/krpc/tree/master/service/SpaceCenter/src/Utils

And let me know if you have any questions/issues with krpc-clientgen!

Edited February 11, 2016 by djungelorm

[artwhaley]

I'll try out the clientgen feature as soon as I can!  

 

I...  HAVE fiddled a tiny bit with PID parameters in the real world - I used to play with ardupilot for turning RC planes into autonomous drones.  But I wasn't coding then, just playing with parameters.  I feel like you're right...  some combination of the reactionwheel torque, mass and moment of inertia would be a start in orbit... possibly modified by the control authority of the control surfaces (surface area * throwdistance * atmosphericDensity)?  First question after just glancing at the code...  do you feel like it would be worth all the effort to add separate PID values... or at least a scalar of some sort, for pitch, yaw, and roll?   On spacecraft it's common to have more roll authority than pitch or yaw, because you're dealing with a shorter moment of inertia...    and on atmospheric craft it feels like it's frequently one axis that is overcontrolled?  But...that adds quite a bit of complexity, both to the code and for the user to figure out how to manage it?  

 

The nice thing about building any auto-tuning mechanism is that I should be able to expose any additional data required to krpc, then write most of the algorithm externally in python and fiddle with it without a thousand recompiles of the plugin and restarts of KSP, then move the algorithm into the plugin after I get it working! 

 

I also looked at the core heat additions in 1.0.5 after seeing that on the issue tracker.  I... didn't see much that I thought would be of interest to most players?  The CoreHeat module at the moment just seems to be used for resource converters...  and mostly to handle their thermal efficiency.  Do you think it would be better to include this as it's own class in /parts/ so you can definitely grab it for every part that has it, even though it's a strange 'part type' to grab a list of...  or add a couple of ways to try to access the useful bits of this module in the resource converter and resource harvester classes?  Do you think anyone actually wants these values?  If so, do you have a preference on implementation?