stibbons

I'm using all four of those and they play together very well on my rig (Intel i5-4690K, 16GB RAM, Nvidia GTX970). You might also want to look at Distant Object Enhancement to improve the way the night sky looks.

@Hupf is mostly right. But the most recent release of the CKAN client includes some functionality in the GUI to extend which KSP versions to deem compatible with the current one. It doesn't seem to be very well documented in the wiki yet though. Make sure you're running the most recent release, version 1.22.1, from https://github.com/KSP-CKAN/CKAN/releases . Then you can go to the Settings menu and select "Compatible KSP versions". From that dialogue, you can elect to also install mods that are marked as compatible with KSP 1.2.1 and 1.2 as well as the current 1.2.2, for example. Note that a mod can opt out of that, and specify that it definitely should only be installed on a specific version. And, obviously, if you install a mod in a potentially incompatible version and everything breaks, you get to keep both pieces.

Hey, engage away if you like. I would just suggest not using a false equivalence next time.

If you feel like this is significantly impacting your business, then you should get in touch with your TAM. Quote the appropriate part of the SLA that's being violated, and I'm sure they'll be happy to credit your account as per the agreed-upon penalty clause.

That may depend on where you're planning on buying it from. All I know is Steam, and the answer for that is "no, not until you actually send the gift".

I have my stick permanently mapped to use the left-right axis for yaw as well, but that's probably because I spend almost all of my time flying rockets. The Advanced Fly By Wire mod lets you set up joystick presets and switch between them in flight. Seems like the best (mod) option to easily switch between good setups for spaceplanes and rockets.

These boards took a little longer to arrive than usual, but they look fantastic. Really love OSHPark PCBs. Totally gratuitous shot of the unassembled board, because they look so pretty. Populating the board quickly hit a snag - I'd laid out the PCB without measuring the enclosed IDC headers I wanted to use, just kind of guessed on their size. Turned out I severely underestimated how big the enclosure is. Almost all of the labels are obscured, and where connectors are next to each other I had to actually cut off the side walls with a craft knife to make them fit. The cable connectors sit snug next to each other as well, but it works. Here's the new board, alongside the old prototype it'll be replacing. The old board still works, but I'm surprised it was as reliable as it's been over the last couple of years (good grief have I really been working on this for that long?!) This evening I finally installed the new board in my controller. I wrote a test sketch that sets up the inputs, and just continuously polls them and dumps their current state in a human-readable string to the serial connection. That let me test that all of the connections are sound, without fully powering the board. That's a very big deal because the throttle connector handles 12V for the motorised slider, and can easily fry the arduino if I hook it up wrong. I had to flip one of the 16 pin connectors (OK, I really cut a new slot out of one side, and dodgily glued the removed material in to the original slot). But apart from that, everything looks like it's working really, really well. Over the course of this week I'll finish up the I2C connection to the other boards, and then work on updating the real controller code to work with this new arrangement. Finally, getting back to why I put so much effort in to aligning all of the digital inputs in the same logical ports, here's the loop function from my test sketch. I've got 30 digital inputs, and this piece of code shows how I poll all of them using port manipulation void loop() { uint8_t c = PINC; uint8_t b = PINB; uint8_t l = PINL; uint8_t a = PINA; snprintf(buffer, 64, "Pin registers: PINC %d | PINB %d | PINL %d | PINA %d", c, b, l, a); Serial.println(buffer); } This is literally an order of magnitude faster than the approach I have to take right now, individually extracting each pin reading from a multiplexer.

My answer: And here's my reasoning:

You want to read the Arduino documentation on ints. And you're right. On the Uno and other ATMega-based boards, an int is 16 bits, while on the Due an int is 32 bits. The solution is to use the int16_t data type instead of int. And when unsigned int is used, it should be replaced by uint16_t. Pretty straightforward, just modify the ControlPacket definition in your sketch like this uint16_t ControlGroup; int16_t Pitch; and so on. The plugin logs to the usual KSP logs - KSP.log in the game directory.

Sorry, I thought you were trying to answer OP's question.

For new purchases no, you can't. Refer to the FAQ:

You're using a meter that measures current. The "analogue" pins on the Arduino board output a variable voltage. My electrical engineering uni courses were too long ago to suggest a better way of fixing it than "buy a volt meter".

Only partially correct. Parts can be purchased in R&D, or ad-hoc in the VAB or SPH. Parts that have been researched but not purchased yet appear in the VAB like this, and can be purchased: (that's the most trivial example I could think of, with a stock moderate difficulty game, accepting and completing the first two contracts, researching a couple of nodes in R&D but not purchasing any parts) That said, this was a stock 1.2.2 career game, installed via Steam - everything seems to be working the way I'd expect. If @TV4Fun is actually having problems with 1.2.2 I'd suggest they file a more detailed report in the appropriate forum.

It's not likely that changes in KSP 1.2 / 1.2.1 had any effect on the serial comms. But if the Arduino IDE has updated recently it may include newer 16U2 serial drivers that play nicely with our serial library? It would be interesting to check it with an Uno or similar.

Yay I can finally stop beetling around pulling tarballs from a branch. Thanks for all your hard work @cybutek and @Padishar.

The refresh setting in the config file sets time between packets in seconds. I set that to 0.08,but I suspect the default these days is a little higher than that.

Quite a few people do. I'm using the Logitech Extreme 3D Pro stick, which is still a great, cheap option to flight control that I find works really well with the game, both in Windows and Linux. If you search around the forum you'll find people successfully using different HOTAS setups as well, but I think the Unity engine starts to have trouble with more advanced joysticks.

I am running running stuff on a 32 bit teensy (with a Cortex-M4, as opposed to the Due's M3), but the source for the data packets in that sketch shows I'm not doing anything special with the struct packing. It's worth pointing out that my teensy doesn't plug in to a serial connection, though. It's having VesselData packets sent to it over I2C from another microcontroller. The bottleneck is just that an 8 bit microcontroller is being used to do software 3D transforms. Eyeballing @boostme's code shows tells me that they're using integer math, which makes their code run much faster than mine - I was nowhere near 10fps on my Uno. But the same code runs at upwards of 40fps when I use a Teensy 3.2 to do the drawing. Considering I have the game sending data at 12.5fps it's a very suitable arrangement.

I'm not using analogue sticks though, they're basic 8-way digital joysticks. They have a separate analogue pot to set the "intensity" of movement, but it's still a digital on/off. It's a pretty good mechanism for driving rovers, and things like docking and other fine maneuvers, but I use my full-size Logitech stick for everything else.

It's... sitting by idle. All of my time on this project lately has been spent on working on plugin code, although over the weekend I put a fair amount of time in to working on a new enclosure with pretty terrible results. But I'm envisioning the 3.6 will be a very simple drop-in replacement for the 3.2 that's running it now. It's all already 3.3V logic (although I think I need to add a level shifter for the I2C bus). The code is all done in Arduino, and should be a trivial rebuild and upload. Once that's done and I've got an idea of performance I'll look at redesigning the navball model and adding more vertices.

For what it's worth, my security settings were considerably stricter than this before upgrading, and I've not had problems with Sierra on either of my Macs.

I do publishes binary releases for that port on spacedock, but have been very slack and haven't updated for 1.2.1 or the most recent plugin release.

The spacedock thread The problem right now is that at least one of the mods currently included here is distributed under an All Rights Reserved clause. Redistribution, especially in a package that claims to be MIT-licensed as the spacedock entry for this pack does, is only allowed with the express permission of the author. This really does need to be fixed immediately.

I know that stock KSP only enumerates joysticks once, at startup, so hotplugging them while the game is running is off the cards. Never tried Advanced Fly By Wire, but it looks like it bypasses the Unity joystick stuff entirely. Definitely worth trying the hotplug thing there.

Oh man, I really need to get myself a pocket hole jig.