[KSP 1.10.0] Kerbal Simpit: A KSP serial mod for hardware controllers (1.4.1)

[monstah]

12 hours ago, Gizzum said:

i had managed to get the switch to work as you discribed but was thinking if there was a point in the game where you go to a ship that has rcs on and your switch is in the off position it would instantly turn it off.

We do get a message sent to the Arduino at the time the scene changes to flight, already, so you could have your code enforce the ship to match the cockpit state at that moment. Be careful with your landing gear!

Otherwise, they will just be out of sync, no big deal.

6 hours ago, stibbons said:

Even though I will be adding channels so a controller can be notified of a scene change, and the current action group state when the flight scene starts

Great! I'd like to be able to ask the state of the vessel at any time, like an Echo message.

[stibbons]

16 hours ago, Gizzum said:

So how do you go about getting the action group status out of the game.  Is it the same procedure as the telemetry?

The plugin does not yet support this. I expect I'll have time to work on it this weekend though.

11 hours ago, monstah said:

I'd like to be able to ask the state of the vessel at any time, like an Echo message.

Be able to request an immediate status update from a channel, whether or not the device is subscribed to it? That's an interesting idea, although offhand I'm not sure if there's a simple way to implement it. I've added it to my backlog here and will think it over.

[stibbons]

Bits and pieces of progress.

• I did get the plugin sending action group status over the weekend. Sends a status packet when the flight scene starts, and then only when the action groups actually change.
• I've added messages for velocity (surface, orbital and vertical) and all of the stock resources.

I'm pretty happy with how it's looking and will package up a new prerelease very soon. But I really, really want to make sure the existing plugin doco is up to date, and write a little more about the Arduino library and its API first. Hopefully in the next couple of days.

[stibbons]

API documentation for the Arduino library now exists. Still some polish to be applied, but it seems to be working well.

[Gizzum]

Thats awesome Stibbons... keep up the good work!!!!

[stibbons]

Note that readthedocs is tracking HEAD, which is a fair way ahead of what's been released. There's a fair chunk of stuff documented that doesn't work yet. That will stabilise after the next prerelease. 

[Benji]

@stibbons, really great progress.

I wasn't at home for a while now, trying to catch up... is it already available in the arduino libraries?

 

A question about fuels, real fuels to be exact. (Asking, because you already have custom-ACG supported.)

I'm playing RSS/RO most of the time. You think you can get information about fuel levels from real fuels? Perhaps generalising (just looking at the "first/main" fuel) and just naming it fuel level.

Because even when an engine needs a mixture of different fuels, they get burnt at the same (percentage-wise) rate. Not considering boiloff. Thinking about it, if the "main" fuel is the one that boils of, the percentage of the fuel level is (going down) accurately,

[stibbons]

4 minutes ago, Benji said:

I wasn't at home for a while now, trying to catch up... is it already available in the arduino libraries?

Not yet. I wanted the API docs online first, they're now almost at a point I'm happy to get it added.

5 minutes ago, Benji said:

I'm playing RSS/RO most of the time. You think you can get information about fuel levels from real fuels? Perhaps generalising (just looking at the "first/main" fuel) and just naming it fuel level.

So, all of the bits are in place for arbitrary resources. I'm interfacing with the Alternate Resource Panel mod to actually get resources out of the game, and it definitely supports and exports any resources present on the vessel, including Real Fuels.

I'm not sure if I want to add Real Fuels resource support to the core plugin, though. The sheer number of resources it adds doesn't really work well with the current resource sending scheme (although lumping all of the resources together in to a single channel and including the resource ID in the payload could help with that). And, like you say, iterating through all of the resources in the last stage and just sending them all as a single "fuel" resource is probably satisfactory to most players.

Right now I'm leaning towards Real Fuel support as a separate mod that depends on this one. Luckily implementing new data providers is actually a really simple process.

[stibbons]

Prerelease version 0.8 is live:

• The plugin is now reporting resource levels. A resource message contains maximum and current resource levels. There are channels for total vessel and (where appropriate) active stage resource levels for all stock resources. Rather than attempt to calculate resource levels internally, this plugin integrates with Alternate Resource Panel, and the CKAN entry now lists ARP as a recommended mod.
• The plugin reports apsides (apoapsis and periapsis).
• The plugin reports regular Action Groups. Subscribed devices receive an Action Groups packet when the flight scene loads, and whenever the status of an action group changes.
• A lot of internal reorganisation and refactoring, both in the plugin itself and my CI system that builds and deploys it.

0.8 should be listed on CKAN now. I've also uploaded a new 0.8 release of the Arduino library to https://bitbucket.org/pjhardy/kerbalsimpit-arduino/downloads/ . For documentation regarding writing Arduino sketches, refer to http://kerbalsimpit-arduino.readthedocs.io/en/latest/index.html

[stibbons]

Doings are a-happening.

Plugin prerelease version 0.9 is uploaded now:

• Documentation for how to configure the plugin is now at https://bitbucket.org/pjhardy/kerbalsimpit/wiki/PluginConfiguration.md . The plugin now takes it upon itself to include a "Documentation" parameter in the config file, which is hardcoded to be the URL for the plugin config.
• And there's even more docs about the plugin at https://bitbucket.org/pjhardy/kerbalsimpit/wiki/Home , obvs.
• The plugin now includes an example config file, in GameData/KerbalSimPit/PluginData/Settings.cfg.sample . I'm happy to keep updating the sample config file, but this distribution will never overwrite the live Settings.cfg file.
• The refresh rate for data providers from the game is now configurable. The refresh rate is currently global - there's room for future optimisations around per-connection refresh rates, and omitting data providers that no connection wishes to receive from.
  For now, see the RefreshRate configuration option.
• A couple of extra data providers have been added.
  • An Apsides Time provider gives time to the next apoapsis and periapsis.
  • A provider for Target information. When the active vessel has a target set, this provider can send a message with target distance and relative velocity.

This plugin is available for download from my prerelease CKAN repository now. Barring major issues this version will be tagged 1.0, and it'll be added to the regular CKAN repository as a stable release. Future releases will (finally!) focus on data providers in and out of the game.

To go with this plugin release, I've uploaded a new release of the KerbalSimPit Arduino library:

• Version 1.0 of the Arduino library is available from https://bitbucket.org/pjhardy/kerbalsimpit-arduino/downloads/
• Includes support for all of the inbound and outbound data packets currently implemented.
• Full documentation, including a quick start guide, examples and full API reference, is at http://kerbalsimpit-arduino.readthedocs.io/en/latest/
• I've opened a pull request to include this version of the library in the Arduino Library Manager. Hopefully soon you won't need to download this library manually, just install it through the Arduino IDE.

 

[stibbons]

Small status update: The Arduino library for this plugin is now listed in the Arduino Library Manager, making it (hopefully) a lot simpler to install the library and start coding. In the Arduino IDE, go to Sketch -> Include Library -> Manage Libraries... and search for Kerbal. Select the library and hit install. Job's done.

If I get time this week, I have open tasks to add data providers to send a little more info to devices - will probably do something about @Benji's request for a generic "fuel-like resources in the last stage" provider. But at this point I'm more interested in putting the final polish on this one and calling it a real release. I swear I'll get on with that immediately afterwards though.  

[stibbons]

0.10 prerelease is available. Nothing major, just making sure it builds in KSP 1.3.0.

• Rebuilt for KSP 1.3.
• Strict versioning in the CKAN metadata is turned back on. Now that KSP is out of prerelease I'd rather not continue to support 1.2.2.

I haven't actually done any testing on this build yet (still at work). But given I've been tracking the prerelease for a while I'm fairly confident it should be fine. Will give it some time over the weekend, and push out a 1.0 early next week.

[stibbons]

Idle thought while waiting for pull requests to be merged.

I'd like the next batch of telemetry additions to include a packet containing the name of the body whose sphere of influence we're currently in. This would be one of those infrequently-sent packets, so I think it's completely appropriate to include the full name - ie, there's no reason I can't just sent "Laythe" or "Mun", or because doing it this way gives modded body support for free, "Sarnus" etc.

But supporting localised body names almost certainly means the receiving device has to support various wide character sets. And given the receiving device is intended to be an Arduino or similar class of microcontroller, the odds of it actually having decent character set support and being able to display those characters on an LCD seems... remote to me (although I'm from an English-speaking country and have no idea how far wrong I am there).

In addition, my brief experimentation using other language packs leads me to believe that body names aren't fully localised anyway (the Japanese pack displays some Japanese text followed by the traditional name in brackets, for eg).

With all these and the current limited packet size in mind, I'm inclined to forgo localisation support for body names, and just stick to plain ASCII.

Does that sound reasonable?

[stibbons]

The serial code is quite stable now. The core message passing is working well (although I have future plans to optimise sending data out of the game). The providers that have been implemented are doing their thing. So I've gone ahead and uploaded a 1.0 release.

Kerbal Simpit 1.0 is available through CKAN now. The accompanying Arduino library that helps talk to the plugin can be installed through the Library Manager in the Arduino IDE (search for "Kerbal Sim Pit"). It comes with a few example sketches demonstrating the basics, and getting started and API documentation is available at http://kerbalsimpit-arduino.readthedocs.io/en/stable/

Huge thanks again to the people who spent some of their time trying out this plugin and giving me valuable feedback over the last few months, @Benji, @monstah and @Gizzum. Your help and patience dealing with my occasionally dumb mistakes are much appreciated.

For those, and anybody else who installed this plugin, I strongly recommend removing my prerelease repository from your CKAN client config; go to Settings -> CKAN Settings, select the Kerbal Simpit repository and delete it.

There's still a lot of work to be done on this plugin (1.0 means stable and useful, not finished). But for now I'm going to go try out 1.3.

[Benji]

Hui. Juhu. I know what I'll be doing tonight.

[stibbons]

Kerbal Simpit 1.1 is online and will be available soon:

• No longer throw thousands of nullref errors when Alternate Resource Panel is not installed.
• Added a packet containing the name of the current Sphere of Influence the active vessel is in. Only sent when the flight scene loads or the SoI changes (although I'm thinking about adding a schedule that sends these sorts of packets regularly but much less frequently, say every 5ish seconds).

I haven't even updated the arduino library for the SoI packet yet, that will probably happen on my lunch break in a few hours. But thought that bug fix was worth pushing out.

5 hours ago, Benji said:

Hui. Juhu. I know what I'll be doing tonight.

 

Edited May 31, 2017 by stibbons

[Benji]

I was away for a while, had to work, but now I'm back, full of motivation and I love the additions you implemented.

 

I thought and decided to keep my "cockpit" digital. Buttons that toggle SAS, RCS, etc instead of switches. All works fine and smooth. And since the PC has buttons and no switches I'm used to toggle the actions in KSP.

I use a "simple" membrane keypad, so I ran into "noise" and looked into some debounce examples.

But instead of doing things like in the examples(, they really do look complicated at first), I'm doing this:

  if (!digitalRead(button_sas) && (millis() - debounce_sas) > debounce_delay)
  {
    cmd_sas = true;
    debounce_sas = millis();
  }

  if (!digitalRead(button_rcs) && (millis() - debounce_rcs) > debounce_delay)
  {
    cmd_rcs = true;
    debounce_rcs = millis();
  }

It works and is easier to read and write. Why don't others do it this way? Do you know a reason, will my setup explode running this code for a while?

 

 

Now, a suggestion. I use a volt-meter to display the altitude above the surface. At first I wondered why the needle doesn't go down to zero. Than I realized that my testrocket is about 20m tall. So, there is this mod (I got used to use), "Landing Height Display" by Diazo. It displays the radar altitude between the bottom of the rocket and the surface. Could you add this information to the altitudeMessage (, probably best without requiring the Diazo-Mod)?  (OR providing information (height, weight, etc) about the rocket, so I can calculate this myself.)

 

 

I'm looking forward to send prograde and anti-normal sas commands (I prepared it today (Finecontrol too)).

 

Keep up the great work.

Edited June 13, 2017 by Benji

[Benji]

On 29.5.2017 at 1:07 PM, stibbons said:

With all these and the current limited packet size in mind, I'm inclined to forgo localisation support for body names, and just stick to plain ASCII.

Does that sound reasonable?

 

I admit Japanese and Chinese are special. And I like how the kerbal moon uses our wonderful "german" ü. But personally I would play KSP in english, even if there were a german localization.

Yeah, stick with ASCII.

[Benji]

While testing a volt-meter to display electrical information, I paused the game a few times and at one time after unpausing the game, the needle didn't move.

After pausing and unpausing another two times, the needle jumped to the right spot and moved again. Verbose logging is set to true, but there's no info in the log on what went wrong:

...
[LOG 20:25:02.403] Game Paused!
[LOG 20:25:04.218] [UIMasterController]: ShowUI
[LOG 20:25:04.219] Game Unpaused!
[LOG 20:25:06.536] [UIMasterController]: ShowUI
[LOG 20:25:06.537] Game Paused!
[LOG 20:25:07.869] [UIMasterController]: ShowUI
[LOG 20:25:07.870] Game Unpaused!
...

 

Edited June 13, 2017 by Benji

[Benji]

On 18.5.2017 at 4:04 PM, stibbons said:

Prerelease version 0.8 is live:

• The plugin is now reporting resource levels. A resource message contains maximum and current resource levels. There are channels for total vessel and (where appropriate) active stage resource levels for all stock resources. Rather than attempt to calculate resource levels internally, this plugin integrates with Alternate Resource Panel, and the CKAN entry now lists ARP as a recommended mod.
• The plugin reports apsides (apoapsis and periapsis).
• The plugin reports regular Action Groups. Subscribed devices receive an Action Groups packet when the flight scene loads, and whenever the status of an action group changes.
• A lot of internal reorganisation and refactoring, both in the plugin itself and my CI system that builds and deploys it.

0.8 should be listed on CKAN now. I've also uploaded a new 0.8 release of the Arduino library to https://bitbucket.org/pjhardy/kerbalsimpit-arduino/downloads/ . For documentation regarding writing Arduino sketches, refer to http://kerbalsimpit-arduino.readthedocs.io/en/latest/index.html

I managed to register to the ACTIONSTATUS_MESSAGE data stream. But I can't put my head around on how to check this (one?) byte that reports if SAS is on or off.

 

Btw. I'm proud I understood how to use the resourceMessage-s and all the other messages, but this one gives me headaches...

[stibbons]

5 hours ago, Benji said:

I managed to register to the ACTIONSTATUS_MESSAGE data stream. But I can't put my head around on how to check this (one?) byte that reports if SAS is on or off.

 

Btw. I'm proud I understood how to use the resourceMessage-s and all the other messages, but this one gives me headaches...

Hehe, nice work.

Apologies, I should have provided some more useful information, and probably helper functions, about how to get information out of the Action Status messages. I'll make sure that's properly documented in the next release.

You're right, it's one byte. Each bit of the byte corresponds to one of the action groups. You can use bit math to check the status of an individual action group, by using a bitwise AND (the Arduino tutorial talks about using an AND to mask out individual bits - this is exactly what we're doing here). I'm at work, so haven't tested this code, but something like the following would be how you can check the status of the landing gear:

void messageHandler(byte messageType, byte msg[], byte msgSize) {
  switch(messageType) {
  case ACTIONSTATUS_MESSAGE:
    byte actions = msg[0]; // actions now contains the action group message
    if (actions & GEAR_ACTION) {
      // The landing gear action group is active (gear is down)
    }
    break;
  }
}

 

7 hours ago, Benji said:

Now, a suggestion. I use a volt-meter to display the altitude above the surface. At first I wondered why the needle doesn't go down to zero. Than I realized that my testrocket is about 20m tall. So, there is this mod (I got used to use), "Landing Height Display" by Diazo. It displays the radar altitude between the bottom of the rocket and the surface. Could you add this information to the altitudeMessage (, probably best without requiring the Diazo-Mod)?  (OR providing information (height, weight, etc) about the rocket, so I can calculate this myself.)

Interesting! I don't think I'd heard of that mod yet. It looks useful, and a quick glance at the source for it shows it would be fairly easy to integrate. But it's starting to tie in to the next thing on my "too hard to think about right now" pile. It feels like something I'd like to make optional. But almost none of the framework for configuring individual channels is in place yet. I'll add it to the backlog as something to think about, but it'll be a few weeks before anything concrete happens with it, sorry.

[Benji]

7 hours ago, stibbons said:

Apologies, I should have provided some more useful information, and probably helper functions, about how to get information out of the Action Status messages. I'll make sure that's properly documented in the next release.

You're right, it's one byte. Each bit of the byte corresponds to one of the action groups. You can use bit math to check the status of an individual action group, by using a bitwise AND (the Arduino tutorial talks about using an AND to mask out individual bits - this is exactly what we're doing here). I'm at work, so haven't tested this code, but something like the following would be how you can check the status of the landing gear:

void messageHandler(byte messageType, byte msg[], byte msgSize) {
  switch(messageType) {
  case ACTIONSTATUS_MESSAGE:
    byte actions = msg[0]; // actions now contains the action group message
    if (actions & GEAR_ACTION) {
      // The landing gear action group is active (gear is down)
    }
    break;
  }
}

 

I found the information at the end of KerbalSimpitMessageTypes.h but the damn LED didn't react to the SAS being switched on.

Another try this morning. Now I see why it didn't work before. I suspect the mod sends the byte a bit different than described in KerbalSimpitMessageTypes.h . Turning on the (Actiongroup) Light sends 16.

So, I hooked up some LEDs to check the stati of the actiongroups.

LED at ... reacts to Actiongroup (KSP)... which seems to send

SAS_ACTION ... Light ... 16

RCS_ACTION ... Alwas off ... ?

LIGHT_ACTION ... Always on ... ?

GEAR_ACTION ... Stage ... 1

BRAKES_ACTION ... Always off ... ?

STAGE_ACTION ... Brakes, Abort ... 1 or 3 or 5 or 9 or ...

ABORT_ACTION ... Always off ... ?

 

EDIT: I thought maybe there are just some mixed up numbers and I can submit a commit, so I checked Actions.cs and KerbalSimPit.cs

But everything seems fine.

Edited June 14, 2017 by Benji
quick sourcecode check

[Benji]

Is this correct? You are giving these bytes  the integer values you want to assign.

   public static class ActionGroupBits
    {
        // This is the same order given in
        // https://kerbalspaceprogram.com/api/_base_action_8cs.html
        public static byte StageBit = 1;
        public static byte GearBit = 2;
        public static byte LightBit = 4;
        public static byte RCSBit = 8;
        public static byte SASBit = 16;
        public static byte BrakesBit = 32;
        public static byte AbortBit = 64;
    }

Shouldn't it be like, < public static byte LightBit = 2; > This would send the integer value of 4, i think...

Isn't it like for aborting your sending the 64th bit as 1 ?

Perhaps I'm totally mistaken.

[Benji]

For a real test, I hooked up a lcd to show the integer values:

Light -> 16

Gear -> 4

Brakes -> 1

Stage -> 2

Abort -> 1

SAS -> Nothing

RCS -> Nothing

 

It's strange.

[stibbons]

Oh, dang. No idea where those numbers are coming from. Will bump debugging that to the top of my todo list.

Apologies for being quiet the last couple of weeks, real life has been getting in the way.

On 2017-6-18 at 3:05 AM, Benji said:

Shouldn't it be like, < public static byte LightBit = 2; > This would send the integer value of 4, i think...

Isn't it like for aborting your sending the 64th bit as 1 ?

Nope. Those numbers are the literal bit mask, not an offset for the 1. Perhaps it makes more sense if you see them written as

public static class ActionGroupBits
{
    // This is the same order given in
    // https://kerbalspaceprogram.com/api/_base_action_8cs.html
    public static byte StageBit =  0b00000001;
    public static byte GearBit =   0b00000010;
    public static byte LightBit =  0b00000100;
    public static byte RCSBit =    0b00001000;
    public static byte SASBit =    0b00010000;
    public static byte BrakesBit = 0b00100000;
    public static byte AbortBit =  0b01000000;
}

The idea is that the sending end can OR together the appropriate constants to form a data packet containing the active action groups, and the receiving end can AND a constant with the data packet to find out if that action group is set.

EDIT: But, of course, instead of the sending end ORing things together, it's trying to do bitshift shenanigans. I must have been really tired when I wrote that, sorry.  Will have a fix out ASAP.

Edited June 20, 2017 by stibbons