stibbons

Members
  • Content count

    1023
  • Joined

  • Last visited

Community Reputation

709 Excellent

About stibbons

  • Rank
    Extreme IFR

Recent Profile Visitors

4262 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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 )
  6. 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.
  7. I know right. They're frequently happy, but it's hard to catch them being as open about it as your average dog.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. 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.
  14. 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.
  15. 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.