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.

This refurbished Yashica-A was a gift from a friend. Made in 1959, shoots 120 film. I don't take it out very often, but it's in great shape and takes really lovely photos.

Obviously the only NaN speed is "plaid".

Not really. A C# assembly built using VS should run just fine with the mono runtime on both Linux and MacOS. In my experience running the ckan client the UI is occasionally a bit twitchy on Mac, but it definitely works.

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

Only vaguely related to this controller project, but for another build I've been playing with electromechanical seven-segment displays. These things have an electromagnet behind each segment - pass current through in one direction to set the segment on, in the other direction to set it off. It's the same technique as flip-disc displays. They're a lot of fun, and very energy efficient as they don't need power to hold state. But the magnets require a lot of power, and driving them has been an interesting challenge. Last weekend I finally had some success with the driver board I've been working on, and now I'm starting to wonder how to integrate some of these digits in to this build.

*sigh*

Not yet. I wanted the API docs online first, they're now almost at a point I'm happy to get it added. 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.

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.

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

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.

The client will try to autodetect the location of your KSP folder, but if it can't then yes it's normal to get an empty installation list. Have you followed the directions in the user guide?

The plugin does not yet support this. I expect I'll have time to work on it this weekend though. 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.

That's not an impossible scenario, true. Although I think this plugin is safely at the point where I could just ask "What happened when you tried it?" It's important to note that the code I've pasted above only sends a command when the switch state changes. 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, neither of those are required to avoid catastrophe. To take your landing gear example, it's very easy to get to a point where your gear switch is "up" when you switch to a vessel with gear down. Just flip the switch up at KSC and then switch to a vessel with its gear down. But when that happens, your controller won't send a gear up command to the vessel because the switch is already up. And when you flip the switch down your controller will send an activate gear command but nothing happens as the gear are already active. It's a cosmetic controller issue that I don't particularly like much, but won't cause any problems in-game.

Sounds like you need to bookmark the keybindings page of the wiki. Or, if you search the forums, you'll find a few nice printout cheat sheets for keybindings. On EVA, the R key toggles your Kerbal's jetpack. Shift and Control move up and down.

You don't actually need to check the current state of RCS in the game (which is good because I haven't yet added a message for action groups coming out of the game ). You would just need to check the state of the switch, and send an activate or deactivate packet. I'm at work so can't test this, but you should be able to take the staging demo and just modify the loop() like this: void loop() { // Read the state of the switch into a local variable. int reading = digitalRead(buttonPin); // check to see if you just pressed the button // (i.e. the input went from LOW to HIGH), and you've waited // long enough since the last press to ignore any noise: // If the switch changed, due to noise or pressing: if (reading != lastButtonState) { // reset the debouncing timer lastDebounceTime = millis(); } if ((millis() - lastDebounceTime) > debounceDelay) { // whatever the reading is at, it's been there for longer // than the debounce delay, so take it as the actual current state: // if the button state has changed: if (reading != buttonState) { buttonState = reading; if (buttonState == HIGH) { // If the switch has just gone HIGH, activate RCS mySimPit.activateAction(RCS_ACTION); } else { // If the switch has just gone LOW, deactivate RCS mySimPit.deactivateAction(RCS_ACTION); } } }

Erm, well I keep track of everything that I want to do with this project on a Trello board, but honestly it's at the point where most of those tasks are boring housekeeping around making sure it's in a clean and tidy state for a real release. I suppose the most interesting work right now is implementing more inbound and outbound data providers - the classes that pull info from KSP and send it to serial connections, and receive data from serial connections and feed commands in to KSP. Documenting those properly is... well... in a Trello card. The serial protocol doc is slightly out of date, but should give a good grounding in to how data gets between the plugin and connected devices. After that, download the plugin source and start with the classes in the KerbalSimPit/Providers directory. All providers inherit from MonoBehaviour, and the majority of them will start in the flight scene. The plugin uses many, many custom Game Events to pass data between providers and serial connections. For data going from serial to providers, there are "onSerialReceived" game events from "onSerialReceived0" up to a theoretical max of "onSerialReceived255". For data going from providers to serial devices, there's "toSerial0" up to "toSerial255". The ints in these game event names corresponds to the channel ID in the serial protocol. If a provider wants to receive data from a serial device, in its Start method it should add a callback handler to the onSerialReceived Game Event with the appropriate channel ID. Have a look at Actions.cs file for an example of doing this for the standard action groups. Note that the serial receiving, and the callback, are executed in a different thread, so you usually want the callback handler to set a flag and then action that flag in the provider class Update method. If a provider wants to send data to a serial device, it can find the appropriate "toSerial" Game Event with the appropriate channel ID, and just call that Game Event's Fire method, passing in the channel ID and any object representing the data to send. If the provider wants to, it can register a callback with the KSPit.AddToDeviceHandler() function. This callback will be called on a regular basis by the plugin (currently hardcoded to every 40ms, but will soon be user-configurable), giving the provider a way to send regular packets to interested devices. See the Telemetry.cs file for an example of doing this with altitude and apoapsis/periapsis. SNEAKY EDIT: Oh, I forgot to mention the Arduino library. It's there to automate the handshaking, provide low-level send and receive functionality, and a bunch of structs and helper functions to make higher level channel handling easier. If you want to learn your way around that, pull down the repo, familiarise yourself with the class layout in KerbalSimPit.h , and read through the other header files to hopefully get a good idea of where I want to take it. Hope that gives you enough to go on. Let me know if you have any more questions.

The official and easiest way to do this is to use virtualenv to create an isolated environment that you can install what you need in to.

I set it up as a bitfield specifically so you could do that, yes. That said, all of the standard action groups should behave as expected with multiple activation packets, except for the staging group. Currently I've tweaked that so that each activation packet will activate the next stage. That was a conscious choice - the staging demo looks much neater without having to send an explicit deactivation in between each button press. Essentially, I'm preferring one-shot packet sending. I'll try to support sending multiple commands where feasible, but for instances like this where there has to be a choice, I'll go for one packet == one command. Certainly happy to entertain changing that, and I guess I could hide the "activate/deactivate" dance behind a helper stage function in the library. But that's how it is right now. In other progress news, this evening I've gotten the resource sending happening. You can implement a basic alarm light for the stage LF with something like this void messageHandler(byte messageType, byte msg[], byte msgSize) { switch(messageType) { case LF_STAGE_MESSAGE: if (msgSize == sizeof(resourceMessage)) { resourceMessage myLF; myLF = parseResource(msg); if (myLF.total > 0 && myLF.available < 10) { digitalWrite(LED_BUILTIN, HIGH); } else { digitalWrite(LED_BUILTIN, LOW); } } break; } } I want to add a little more of the basic orbital parameters (velocity, vertical velocity, inclination, stuff like that), and finally make sure there's some real API docs for the Arduino library online. Then I'll package up a new prerelease.

Glad it's working for you. Eh, that's not really in the scope of what I'm doing, I'm deliberately only using serial interfaces. If you're interested in using a network connection, I believe the preferred method is interfacing with kRPC, although I'm not sure if anybody's using an esp8266 to talk directly with it yet. Yes, this mod implements a serial protocol for sending commands to the game, and the Arduino library you started playing with provides a bunch of functions to simplify working with the protocol. Right now the system only properly supports sending action group commands (the stage demo is an example of this), but will eventually handle throttle, attitude and translation control, and probably more. An Arduino sketch for doing that would basically scale out the current stage demo - check the state of a bunch of input pins, and if the state changes then call the appropriate library function.

You can turn auto update off. Steam will still try to update when you launch the game through Steam, but either launch it manually or just hold off for the brief period between 1.3 releasing and 1.2.2 turning up in the beta tab.

I realised that the stage example sketch should mirror as closely as possible the debounce example. Because I want to illustrate that a staging button is a really trivial (and let's be honest, super fun) application. The next arduino library release will change that and polish the example sketches a fair bit.

That's a little bit concerning. I'll check again when I'm back home (it's the start of the work day here), but I was sure I had sorted out why that was happening before. Apart from that, though, there's nothing I can see that would be causing your issue in those logs. There might be some more detail if you set "verbose" in the config file to true though. Also, which version of KSP are you using (I only test against the 1.2.9 prerelease, although most things should be OK in 1.2.2). And finally, what does your circuit look like? I just realised the comments in the Arduino sketch say to use a button connected to pin 1. This is wrong, and the button should be connected to pin 2. The pin 13 LED should light up as well whenever the button is pressed.

I've been incredibly slack, and have only just now updated my Linux/Mac fork for this release (even though it sounds like I'll have to do it again soon). Available from https://spacedock.info/mod/850/KSP Serial IO (cross platform)

Wow, it sure is nice to hear other folk are interested in something I started just to scratch a personal itch. I started thinking about how to send resource counts last night, and it's a little intimidating because the stock game has quite a few resources now (eight by my count, if you include ablator). For staged resources I'm planning on sending total and stage levels in the one packet. And other stuff like monoprop will go in a smaller packet. Something like public struct StagedResourceStruct { public float totalMax; public float totalAvailable; public float stageMax; public float stageAvailable; } public struct ResourceStruct { public float totalMax; totalAvailable; } I think I'm going to end up staggering updates for these. Right now the plugin loops through the list of providers that want to send every 40ms. Instead of sending all of the resources each loop I'll probably spread them out. That would mean you only find out how much liquid fuel is in the tank every third of a second, but it seems like a worthwhile tradeoff. Something I'll experiment with I guess.