stibbons

Erk, sorry, that's probably my fault. I've been maintaining a cross-platform KSPSerialIO fork for a while that runs well on my Linux gaming machine and I occasionally test on MacOS. But between this project and a lot of other things, just haven't had the time to update that for the latest version. Should hopefully get it done soon. But welcome! I'm glad you like how it's going so far. Let me know how you go with the stage code. I've checked it on my Mac Air, but more eyes are good for figuring out how I can make it easier to use. Surface and orbital velocity, as well as vertical velocity, are definitely on the list, almost certainly in the next release. I'm including current and max power levels as well, but didn't have any plans to include charge rate. If that's something readily available through the KSP or ARP APIs then I'd gladly include it. A little less certain about having to write the code to calculate it myself, but I'll see what I can do.

Yay, finally a little headway on that one. Sorry. I split the Arduino code out of that repository a little while ago, and it shouldn't be available from that link at all. And I haven't been uploading zip files of releases at all, so unless you know git it's probably been a right pain to figure out, sorry. My long term plan for the arduino library is to have it added to the Arduino Library Manager, so you can just install it through the IDE. But until then, the library can be downloaded from https://bitbucket.org/pjhardy/kerbalsimpit-arduino/downloads/ . I've just uploaded a new zip file for the current master. This evening I've also started adding more telemetry to the plugin. It's now sending apoapsis and periapsis, and I've started work on integrating Alternate Resource Panel to send fuel and power levels. I'd like to add a couple more types after that to make sure that the current method of multiplexing telemetry is scalable, and then I'll think seriously about promoting a 1.0 release.

Hey hey. I've started playing around with the ARPWrapper, because I'd like to include resource levels from Alternate Resource Panel in my plugin. So after reading the API access docs I've copied the ARPWrapper file in to my code base, changed the namespace and included it. My Start method looks very similar to the basic check documented, just counting the VesselResources object like this: public void Start() { ARPWrapper.InitKSPARPWrapper(); // Some more initialisation code here if (ARPWrapper.APIReady) { Debug.Log(String.Format("ARPWrapperTest: {0} resources found", ARPWrapper.KSPARP.VesselResources.Count)); } else { Debug.Log("ARPWrapperTest: AlternateResourcePanel not found. Resource providers WILL NOT WORK."); } } Whenever I check VesselResources in my Start method like this, though, it always comes back as an empty list. I'm not too familiar with how ARP logs, but the way I read the relevant section of my KSP.log, ARP does seem to have finished initialising all of the relevant objects by the time my code comes to check. The full log of this code running looks like: [LOG 02:19:10.186] 5/4/2017 2:19:10 AM,KerbalSimPit-ARPWrapper,Attempting to Grab KSPARP Types... [LOG 02:19:10.198] 5/4/2017 2:19:10 AM,KerbalSimPit-ARPWrapper,Got Assembly Types, grabbing Instance [LOG 02:19:10.198] 5/4/2017 2:19:10 AM,KerbalSimPit-ARPWrapper,Got Instance, Creating Wrapper Objects [LOG 02:19:10.199] 5/4/2017 2:19:10 AM,KerbalSimPit-ARPWrapper,Getting APIReady Object [LOG 02:19:10.199] 5/4/2017 2:19:10 AM,KerbalSimPit-ARPWrapper,Success: True [LOG 02:19:10.199] 5/4/2017 2:19:10 AM,KerbalSimPit-ARPWrapper,Getting Vessel Resources Object [LOG 02:19:10.199] 5/4/2017 2:19:10 AM,KerbalSimPit-ARPWrapper,Success: True [LOG 02:19:10.199] 5/4/2017 2:19:10 AM,KerbalSimPit-ARPWrapper,Getting Last Stage Resources Object [LOG 02:19:10.199] 5/4/2017 2:19:10 AM,KerbalSimPit-ARPWrapper,Success: True [LOG 02:19:10.199] 5/4/2017 2:19:10 AM,KerbalSimPit-ARPWrapper,Getting State Change Event [LOG 02:19:10.200] 5/4/2017 2:19:10 AM,KerbalSimPit-ARPWrapper,Getting Acknowledged Event [LOG 02:19:10.200] 5/4/2017 2:19:10 AM,KerbalSimPit-ARPWrapper,Getting Acknowledge Method [LOG 02:19:10.203] ARPWrapperTest: 0 resources found Of course, I've tried doing the same thing in my Update method, and by then the VesselResources object seems to contain the right information - I can get a count, and iterating it returns all of the expected resources for my vessel. So, is this a bug? I don't think it's a huge problem for my code, because I should be able to obtain the resource IDs I want, and using them as keys in VesselResources and LastStageResources every Update doesn't sound excessive. But it certainly wasn't expected, and the API docs explicitly use this as an example that should work. Oh, and one other minor thing, the API docs still link to https://kspalternateresourcepanel.codeplex.com for code samples - that should probably be updated to point to the equivalent github URLs.

Version 0.7 is up now. This release is still trying to get bidirectional serial handling right for all platforms. I've switched back to the original serial library, and written a new serial polling thread that is used on Windows instead of the old reading code. This setup seems to be working for me everywhere I've tried it. And reading data this way also means that it works on a lot more hardware - Arduino boards that didn't work with the event-driven code in Windows previously are now doing the right thing with the polling code. Unless there's any more problems with the serial handling, I'm looking forward to getting back and fleshing out the list of available telemetry providers in the next release.

OK, I've made a little headway in to understanding what's happening here. My plugin attempts to read from the serial port's underlying Stream object using the BeginRead and EndRead methods. This happens in a separate thread. But when the main thread writes the altitude packet out to the port, this triggers the EndRead. There's nothing to read and my slightly sloppy code reuses the last contents of the read buffer, which was the packet that subscribes to the altitude channel. Hence the weird logs. This only happens on Windows, though. I only ever see expected behaviour on Linux and OS X. I have a fairly hacky workaround in place that seems to be OK on my setup, except for the fact that it frequently causes my entire Windows 10 OS to bluescreen and reboot when KSP exits (I'm pretty proud of that, actually ). So looking for other options, and I strongly suspect I'll resort to a thread doing frequent serial polling.

Correct. Port 0 is just the first port you've listed in your config file, and channel 4 is the altitude handler. I got a little bit lazy with my debug logging and didn't bother trying to resolve those to more sensible names.

Ugh. This is really odd. But it's also not just you. I booted up my Windows machine for the first time in a while, tried the altitude demo on a Pro Mini, and I'm getting the same thing. Sorry. Looks like there might be a regression in how the plugin receives data on Windows. I'll keep working on it.

I can assure you that the second one currently doesn't handle rotational control at all (give me a few weeks ). And the first currently only does relative control. kRPC includes an autopilot that can move the vessel to a given pitch, roll and heading. It seems like an easy job to write a service that reads that info from your Arduino over serial and controls the kRPC autopilot.

I've been doing a lot more cleanup of the Arduino library. For messages that include multiple variables, I'm now including a struct describing the packet, and a method to parse it. To decode the altitude packet, you can now just do this // The altitudeMessage struct contains sea level and surface altitude altitudeMessage myAltitude; // Convert the received message to an altitude struct myAltitude = parseAltitude(msg); // Display the surface altitude on an LCD lcd.print(myAltitude.surface); All of the constants related to message types have been renamed to *_MESSAGE, and all of the examples now name their functions messageHandler. And there's some other minor cosmetic changes to the interfaces designed to more closely fit in with the Arduino style guide. This is all prep work for including more telemetry handlers, and getting the library ready for a 1.0 release.

Just pushed some changes to the arduino library: Fixes a really terrible piece of code that was working fine when compiled with the teensy toolchain, but was causing packet receiving to fail on AVR boards. All of the demo code now runs properly on my Arduino Mega. Stream objects are now passed to the initialiser by reference instead of a pointer. That is, you now initialise the library like this: KerbalSimPit mySimPit(Serial); Just a small quality of life hack to improve readability and bring the library closer to Arduino style guidelines. All of the demos have been updated to use this. Oh, and I dropped the altitude in the altitude trigger demo down to 500m, so you don't have to wait around for ages. Those changes have been pushed up now, and I'd strongly recommend updating if you're using a Uno or a Mega. Sorry. Still working on adding a couple more telemetry handlers to the plugin. Then I'll tidy up the arduino code a little more before opening a pull request to add it to the Arduino Library Manager, to make it much easier to install. (also, can you tell that I'm at the end of my second four-day weekend in a row? Easter and ANZAC day were great for getting some solid hacking done )

v0.6 prerelease is live. This version adds support for the standard action groups. There are three new methods (activateAction, deactivateAction, toggleAction), and constants for STAGE_ACTION, GEAR_ACTION, LIGHT_ACTION, RCS_ACTION, SAS_ACTION, BRAKES_ACTION, ABORT_ACTION. Activate the brakes by calling mySimPit.activateAction(BRAKES_ACTION); Actions can be combined by ORing them together, so the states of several can be changed at once. To turn off both RCS and SAS, call mySimPit.deactivateAction(RCS_ACTION | SAS_ACTION); The toggle command, as with custom action groups, flips the state of the given action group without needing to know the current state. Finally, I've rejigged the way the stage handler works again. At the end of the day, the stage action is the same as the others, just with some special bits tacked on. To activate the next stage, call mySimPit.activateAction(STAGE_ACTION); If you do happen to be adding other actions to the Stage action group, it's worthwhile knowing that deactivating STAGE_ACTION does indeed work, and won't activate the next stage. Currently working on writing up proper API docs for the Arduino library, and the next prerelease will help bed down how I'm sending telemetry out of the game, with a few more telemetry providers.

I know right. They're frequently happy, but it's hard to catch them being as open about it as your average dog.

This is Eli, named after the legendary actor Eli Wallach. He's 10 years old this month, and the biggest cat I've ever met, tipping the scales at nearly 8.5kg. Whenever I'm somewhere and see another cat, I have to remind myself that they're not tiny, I just share a house with a mammoth. But he's also incredibly timid. I know somebody's about to knock on the door because he's dashed out to the bedroom to to hide under my bed. For some reason, he really really likes sleeping on pizza boxes. I keep a few old boxes around for him, much to the consternation of... pretty much anybody who visits.

So the test code I was using (literally the existing stage demo with simpit call changed) does the long way byte dings = 2; mySimPit.activateCAG(dings); I don't have my hardware here to test it either, but there's no reason you can't just do mySimPit.activateCAG(2); You shouldn't even need an explicit cast to a byte, it'll be taken care of for you. Ow. Did that blow the whole chip? You'll sometimes find that overdriving will burn out that one pin, but the rest of the board will keep working. Either way, letting the magic smoke out is never fun.

Just uploaded a 0.5 prerelease. The plugin now supports a "toggle CAG" packet, so you can just toggle the current custom action group state without needing to know what it is - sending a toggleCAG packet is basically the equivalent of hitting the keyboard key for the action group. The arduino library has these functions for working with action groups: KerbalSimPit::activateCAG(byte actionGroupID); KerbalSimPit::deactivateCAG(byte actionGroupID); KerbalSimPit::toggleCAG(byte actionGroupID); Note that these now only accept a single ID, so to toggle action group 4 you just need to call mySimPit.toggleCAG(4); . If you need to work with multiple AGs at once, your only real option right now is to send a custom payload. I'll be sticking to this pattern moving forward - the helper functions only operate on a single element at a time where it makes sense, but multiple elements still supported by calling send directly. Top of the to-do list now is the regular action groups.

You know you can buy addressable LEDs in regular PTH housings as well, right? I've been using a bunch of these Adafruit ones in my build, but cheaper varieties are undoubtedly available.

Lots of small changes to the Arduino library, and I've uploaded a new 0.4 prerelease of the plugin. The CKAN will index it shortly. I've changed some core functionality in the way the library is used. First of all, the serial object you're planning on using needs to be passed in when you declare your KerbalSimPit object, for most people this means calling it like this: // KerbalSimPit object KerbalSimPit mySimPit(&Serial); And in your init() method, set up your serial speed as usual, and call mySimPit.init() without any arguments. This allows use of any serial device your hardware supports (Serial1 on a Mega, for example). In theory, SoftwareSerial connections are also supported, but I haven't yet tested this setup. All of the example sketches have been updated to work with the library, have a look through those for more detail. The 0.4 plugin release is a small update that just fixes the staging functionality. Can confirm that the current arduino demo and plugin now actually really does work properly for staging events. My plan at the moment is to do some proper testing of the action group functionality, and hopefully sort that out in the next day or two. Following that, I'll be looking at applying the last little bits of polish to the Arduino library before tagging a real release and getting it included in the Arduino Library Manager. And then I'll be in a good position to start expanding the game functionality

Apparently I'm not explaining myself very well, which could also be why you seem to have taken offense by me pointing out where the problem is. Apologies. As the guru has much more eloquently described, it's an issue with the release, that is affecting everything that tries to automatically index that release, and there isn't a great deal the CKAN indexer can do to correct it. The NetKAN spec does allow version-specific overrides to correct things like the supported KSP version, but that won't work in this instance as the prerelease is also identifying as exactly the same version as the stable release. I'm really not sure if there's anything that can be done externally, but I'd love to be corrected by somebody who knows the NetKAN spec better than I. So, the only option is to correct the BDArmoryContinued .version file. And for that, I would direct you to PR #169. But even after making those changes, a new release would be required.

I have nothing to do with either CKAN or BDAC. Precisely what are you expecting me to do about a BDAC release that claims to be compatible with a KSP version it segfaults? Are you having this same conversation with the AVC maintainers? Because it's also affected.

This release contains a .version file that declares KSP_VERSION and KSP_VERSION_MAX to be 1.2.2. The CKAN will list pre-releases if you've declared them to be stable and for a mismatched version of the game.

Oh, I messed up, forgot that you need to be sending the size as well. You want to be calling it as mySimPit.send(CAGACTIVATE_PACKET, ActionGroupID, 1); // Or, to be thorough, mySimPit.send(CAGACTIVATE_PACKET, ActionGroupID, sizeof(ActionGroupID)) I wrote a long explanation of how I'm using push buttons to toggle actions in my KSPSerialIO controller here. Like you say, it's a little bit more code and a couple more variables to track state, but if you're doing it all with bitwise math, then the extra variables only come down to a few ints. Heh, the standard action groups (brake, lights, abort, etc) were next on my list anyway, so yeah they'll be coming next after I've gotten the current providers a little more solid. Of course! The plugin source code lives at https://bitbucket.org/pjhardy/kerbalsimpit , and there's a growing body of documentation for it at https://bitbucket.org/pjhardy/kerbalsimpit/wiki/Home . The arduino library code is at https://bitbucket.org/pjhardy/kerbalsimpit-arduino . And finally I track what I'm working on and what I want to work on next on a trello board at https://trello.com/b/t6YUftuS/kerbalsimpit-progress

Oh, I nearly forgot about this: For the action groups, the payload should be the number of the action group to trigger. This can be either one byte, or an array of bytes to activate several at the same time. eg, for custom action group 4, you want to call byte ActionGroupID = 4; mySimPit.send(CAGACTIVATE_PACKET, ActionGroupID); It's important to make sure that if you're only sending one, it is sent as a single byte, either a byte or a char or an int_8t or similar. Trying to send 4 as an int above will mean two bytes are sent, which will be interpreted as activating action groups 0 and 4. If you want to activate 4, 8, and 12 at the same time, then something like this should work: byte ActionGroupArray[] = { 4, 8, 12 }; mySimPit.send(CAGACTIVATE_PACKET, ActionGroupArray); As for how activate and deactivate are treated by the game, my understanding is that a boolean state is maintained for every custom action group, just like it is for the action groups like brakes, lights, etc. Every time you hit the 4 key on your keyboard, the game flips the boolean state of the action group. The activate and deactivate methods I'm using just make those explicit. If you send multiple activate packets for action group 4, then the first will act as if 4 was pressed on the keyboard but the others won't have any effect. But sending an activate and then deactivate packet for group 4 will behave as if the 4 key was pressed twice. This makes it easy to work with flip switches - you can poll the switch every 100ms and send an activate/deactivate packet every time. But if you're using push buttons then you'll have to track the last sent packet so that the opposite one is sent on the next press. That said, it would also be fairly simple to add a toggle packet that ignores state, just flips it. I'd be happy to add that to my todo list. In addition, I plan on making action group status a channel that can be subscribed to, so that when a new vessel loads a control panel can find out which action groups are already active. Ugh, I'm setting some time aside to write up real API docs for the arduino library too.

Definitely not! Apologies for the delayed response, between work and a brief holiday last weekend I haven't had much time for working on this project recently. But I really do appreciate somebody else running it now to help make sure it's easy to use and robust enough. I did spend some time on this a couple of nights ago, and pushed a few changes to the Arduino library. That fixes the compile error with the new stage code, but I still haven't properly tested it. Will give it some time to properly test the staging functionality this coming weekend though. I've pushed some changes to the Arduino library that fix the compile error, and some dumb bugs I'd left in the demo sketches. I've also tweaked the handshaking again - all of the demos now turn on pin 13 as soon as the arduino starts, and turns it off when handshaking is complete. Hopefully a little easier to tell what's going on. Definitely not, although the only extensive testing I've done of both sending and receiving at once is in the HelloWorld sketch. I hadn't yet tried writing any code to combine the altitude and staging stuff, and I strongly suspect the stage code is pretty broken, sorry. This bit of your log is really weird. The "subscribing to channel" message should only be logged when the plugin gets a subscribe packet - that is, when you call SimPit.registerChannel(), and you're only doing that in init. I uploaded your code to my spare Mega board, although unfortunately I don't have any other hardware to properly test what you're doing - it'll have to wait until I'm back in front of my workbench this weekend. But I'm definitely not seeing the same weird logs. *sigh* Probably not. That exception looks like the changes I made in the plugin to support the stageEvent() shortcut aren't going as expected. The entire staging stuff was a bit of a hack and kind of rushed. I'll sit down with some real hardware over the weekend and make sure it's properly working. Again, I really appreciate your time testing this stuff.

[citation needed]

The MiniAVC plugin does a plain HTTP GET on the URL defined in the .version file for the plugin. That doesn't send much information, but it's still not a great thing if the user has opted out. It's also worth noting that the MiniAVC plugin will still do local version checking regardless of the remote setting. It shouldn't know if there's a mod update available, but it will know, and warn you, if the KSP version doesn't match what the plugin's .version file indicates it's compatible with. In addition, the AVC documentation states that if the full AVC plugin is installed, the MiniAVC plugin will disable itself. I'm not 100% sure because I've never used it, but suspect that means the full AVC plugin will go ahead and do remote version checks regardless of what you told the MiniAVC plugin it can do when KSP started up. But that would need testing to confirm. All that said, I've never used the full AVC plugin, always instruct MiniAVC to not do remote checks, and have never noticed it doing remote checking. If you suspect it is, the best place to start is to look in the MiniAVC.log file in the root of your KSP install. Search for lines containing "remote version" or "UpdateAvailable". Even if "UpdateAvailable" is false, it means MiniAVC has performed a remote check. Before filing a bug, though, it's probably worth checking that plugin's MiniAVC configuration, in MiniAVC.xml in the plugin directory, to make sure the AllowCheck parameter is indeed set to false.