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.
2015-11-25
2015-11-21
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:
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.
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.
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.
K-42 Part 6: Iterations and reiterations
This post is a repost of a blog entry from 12th November 2015 on Kerbal Space Program forum (soon to be defunct).
The K-42 project have been on the back burner for a while due to a near rage quit.
I had the whole thing up and running and all seemed well until I actually started playing the game. I experienced crashes all the time and couldn't quite figure out what caused them. Every time I tried to fly a mission, the game crashed after around 2-10 minutes of play time.
I tried to remove all mods except KSPserialIO, it still crashed. I thought it might be due to sending control packets asyncronously so I limited the send rate to be the same as the receive rate. It became a tiny bit more stable. I removed the control packets totally and implemented the whole thing as two joystick controls with 20 buttons each and only used KSPserialIO to get output from the game. Still crashing. I decreased update frequency and transmision speed and thought problem solved, but noooo, crashes came less frequent but seemed to be proportional to the total amount of packets sent by the mod.
So, as it is never too late to give up, i decided to make a tactical retreat and forget about KSPserialIO.
Next choice was Telemachus. Looked nice but I would need to build a demon that read json data and translated it into a serial byte stream. I started to look for information about using web sockets and json when I discovered a mod that could make my life much easier, kRPC.
Why parse json when you can use a Python lib to read parameters from KSP by simple functions and variables? That was exactly what kRPC was about. All I had to do was to install kRPC, a Python interpreter, a serial communication library and ... learn Python.
Four days into the process I have a working daemon transferring data from KSP to my command panel.
All there is left to do now is to test if it is stable. Please wish me luck.
The K-42 project have been on the back burner for a while due to a near rage quit.
I had the whole thing up and running and all seemed well until I actually started playing the game. I experienced crashes all the time and couldn't quite figure out what caused them. Every time I tried to fly a mission, the game crashed after around 2-10 minutes of play time.
I tried to remove all mods except KSPserialIO, it still crashed. I thought it might be due to sending control packets asyncronously so I limited the send rate to be the same as the receive rate. It became a tiny bit more stable. I removed the control packets totally and implemented the whole thing as two joystick controls with 20 buttons each and only used KSPserialIO to get output from the game. Still crashing. I decreased update frequency and transmision speed and thought problem solved, but noooo, crashes came less frequent but seemed to be proportional to the total amount of packets sent by the mod.
So, as it is never too late to give up, i decided to make a tactical retreat and forget about KSPserialIO.
Next choice was Telemachus. Looked nice but I would need to build a demon that read json data and translated it into a serial byte stream. I started to look for information about using web sockets and json when I discovered a mod that could make my life much easier, kRPC.
Why parse json when you can use a Python lib to read parameters from KSP by simple functions and variables? That was exactly what kRPC was about. All I had to do was to install kRPC, a Python interpreter, a serial communication library and ... learn Python.
Four days into the process I have a working daemon transferring data from KSP to my command panel.
All there is left to do now is to test if it is stable. Please wish me luck.
Subscribe to:
Posts (Atom)