K-42 Part 8: Easing the load

Having to serve multiple clients through RPC puts some strain on Unity. As KSP is still using the single threaded version this is something we don't want. It will just increase the load on a single CPU core while we have others just idling around.

While this works pretty well when using one or two net clients that only need a limited amount of information, it has the potential of cause much more lag when adding more net clients.

I have decided to move all communication with multiple K-42 clients away from kRPC into the communication daemon that i currently just use for serial communication. It also has the additional advantage of being able to build a communication protocol between clients if needed.



















So right now I'm in the process of learning how to do network communication in Python and in order to do that in real time, I also have to figure out how to use threading in a reliable way, and to do that I really need to learn how to do object oriented programming.

Ok, I'm not all out in the blue here. I've done some concurrent programming in both Modula2 and Java and as I've worked with Java I got a grip on object oriented programming. BUT! That was twenty years ago.

And no, it's not like riding a bike.

Finding a purpose

I'm still deep into the process of deciding what this blog should really be about and the consequences of moving from the previous small community blog at the KSP forum to a public blog on the Blogger platform.

One such consequence is that I can display a little more of what I do as I'm not feeling any need to restrict my topics to be related only to this single computer game anymore. I'm also not satisfied with the name of my blog so I've changed it. The current name may stick or be changed to something else depending on what direction my posts take during the next couple of months.

We'll see where the journey ends.
Thank you for reading, whoever you are.

K-42 Part 7: Back on track

My tests with kRPC went well. The game is rock steady for the first time in a long time an I had finally an opportunity to really playtest the control panel for real. There were a few things on it that I found being totally unnecessary, but also a few things I really missed having.

The biggest mistake I've made was to add far to many switches. A number of them are marginally useful and only so on the most obscure of my contraptions.

For example:

• I have two switches for foldable cooling arrays. Why would I retract only some of them at any point? Either I'm in the atmosphere and they are all retracted or I'm in vacuum and it will not matter if they stick out all over the place.
• I have two battery switches. If I need to connect emergency power it should suffice with a single set of batteries. If I need more emergency power it can be added to that single set of batteries.
• I also have two switches for air intakes. Might come in handy if I want to keep the air resistance as small as possible at low altitudes, but a spaceplane launch is just as doable with only one set of extra air intakes. Actually I could do it almost as easy with a single set of air intakes that I keep open all the time.
• There is support for dual rockets AND aero engine, with dual modes for all of them. I have previosly built ships with electrical propeller engines, a dual mode engine for launch, and an atomic engine for interplanetary travel, but how practical is such a contraption and why on Kerbin should I use dedicated switches for it. I should leave those aberrations for the action group switches instead of adding extra dedicated switches that may never be used.

All in all I should be able to remove at least one fifth of the switches and still not lose any practical functionality that I will really miss.

What I wanted on the other hand was better displays. The three 16x2 displays are a bit too limited. I can display most of the information I need to launch into orbit and land, but it is a bit crude to work with and the limited amount of information still leaves the pilot doing guesswork and flying by the seat of his or her pants. That's not the way to do space travel.

So I made a really crude proof of concept in Python for a resource monitor on an old HP Mini 5101 running Linux so I could keep an eye on fuel and electricity in a better way. There was quite a few glitches in the GUI of kRPC when changing from localhost to my local network, but it worked. The current alarm module just indicate warning levels with no way to see how fast stuff is running out. I know that those things can be had using Telemachus, but I don't want the display to look like a physical display on a screen, I want my screen to actually be the physical display.