stibbons

You can do all of that simply by checking for case 4 in your list. The outcome of all of the other cases is the same. Something like this should be all you need. if (!digitalRead(STAGELOCKPIN) && !digitalRead(STAGEPIN)) { MainControls(STAGE, HIGH); } else { MainControls(STAGE, LOW); }

Yes, definitely. A floating pin sometimes works the way you'd expect, but I've also had them changing state based on the state of nearby switches on the panel, or the state of nearby pins on the arduino board, or even acting like a capacitive sensor and changing state when I waved my hand near the switch body. Toggle switches are also susceptible to contact bounce. Possibly only when the contacts open, but it's there. I always wind up using software debouncing, and if you're looking I just used the Bounce2 library in a different project and it's quite easy to work with. But hardware debouncing looks like fun, and I'm a little envious of Mr0nak's setup. Yep! I started out with the lock in series with the stage button, but I've got a few RGB status LEDs scattered around. Putting the lock on a separate input lets me make smart decisions about how to update them void stageLedSet() { // If abort button has been hit, blink fast. // Otherwise, set the colour depending on whether stage lock is on. if (abortState) { if (fastBlinkState) { leds[stageStateLed] = CRGB::Red; } else { leds[stageStateLed] = CRGB::Black; } } else { if (readMuxPin(stageLockPin)) { leds[stageStateLed] = CRGB::Green; } else { leds[stageStateLed] = CRGB::Red; } } }

Using a pull down resistor means the input will be a logic LOW when the switch is open, and a logic HIGH when the switch is closed. The state of the input is exactly what you want to put in the control packet and send upstream; for the simplest case you can literally do this MainControls(STAGE, digitalRead(StagePin)); No need to constantly be confused inverting all the booleans. (and please, please don't invert them twice!) The game carries out a stage operation when the value of the stage input transitions from 0 to 1. Under normal circumstances the control packet has the stage bit set to 0 when the stage button is open, and 1 when the button is closed - the transition from low to high happens when you press the button. But with your bug, when the vessel is loaded and the connector handshake happens, the very first control packet the game receives already has the stage bit set to 1, causing the immediate stage. After that, pressing the button results in a transition from 1 to 0 (with no effect apart from preparing for the next rising transition). And releasing the button results in a transition from 0 to 1. So the staging happens approximately normally, but when the button is released, not pressed. EDIT: Back to how things work with pulldowns, my code is complicated slightly by using a multiplexer and doing input debouncing in software. But the way the staging bit of the control packet is constructed is hopefully pretty straightforward: boolean stageStatus() { if (readMuxPin(stagePin) && readMuxPin(stageLockPin)) { return true; } else { return false; } } void controls() { if (connected) { if (stageStatus()) { MainControls(STAGE, HIGH); } else { MainControls(STAGE, LOW); } ...

Work on what you've got now. You're right, the game doesn't need any new features pre-1.0.

I'm curious about your reasoning for this. Doesn't seem to add up.

You probably want to give a mod manager like CKAN a try. Makes managing updates and dependencies trivial.

That's an awesome looking MKS setup there.

Nah, the best day is 22nd of July - Pi Approximation Day.

If it's too hard to train a pilot to flip a switch on a goo canister, yes.

It's always specified. Check out the orbit in the map view or in the tracking station. The orbit will have little dots running along it that indicate which direction to go in.

You haven't mentioned whether you installed KSP through Steam or bought it through the Squad website. I'm only familiar with the Steam version, but understand there's not much difference between the two at all. The game ships with both 32 bit and 64 bit executables, which is why you see "KSP" and "KSP_x64" data folders. But generally, unless you've explicitly done something to run the 64 bit game, you'll be running with 32 bit. I know that is the case with Steam.

And don't forget the simplest option for custom inputs - pull apart a keyboard and wire new switches in to it.

That is a fantastic looking panel so far. Nice work! My inner small child is very glad you didn't butcher the Atari for it.

Not strictly space program related, but a Rosie Kerman as an engineer would be fantastic.

A core tenet of flat earth philosophy is "I haven't personally seen the curvature of the earth therefore it can't be a sphere". Using it as an analogy to ignore sexism is some next-level irony.

No craft file, but this is my Mun crane. An OKTO probe core with a seat above, reaction wheel and KAS winch below. Girder segments radiating out from the probe core then down, with wheels and KAS containers full of assorted bits and bobs at the bottom. There's also a few struts added on the sides to help keep the legs rigid. Most useful thing I did was including some KAS pipe connectors. When I pick up a module I then bolt it in place with a couple of pipes. The resulting contraption is rock solid cruising across the surface at 20m/s. If I were building this again I'd try to get the unladen centre of weight lower by adding something to the bottoms of the legs, and definitely add some RCS. It's very hard to move around and prone to tipping when it's not carrying anything.

The latest Astronomer's pack is in CKAN now. I literally installed it by clicking half a dozen checkboxes.

I haven't accidentally staged once since building my own control panel.

For anybody unsure of why gendered terms are problematic in English, and some suggestions for how to deal with them, http://theconversation.com/gender-neutral-communication-how-to-do-it-38383 is a great start.

(I demand pictures of your crane! )

I use KAS winches with radial docking connectors for this. * Build a crane with an appropriate winch, and add some radial docking connectors. These can be attached anywhere a Kerbal can reach, or put in a container somewhere. * Get the crane to the module you want to move. * EVA a Kerbal, get them to one of your radial docking connectors, right click and tell them to grab it. The Kerbal will remove the connector and attach it to their back. * Move them over to the module you want to lift, right click the connector and select attach. Attach it to the module. * Send the Kerbal over to the winch. Right click and grab, and select grab connector. Again, the winch connector will now be attached to your Kerbal's back. * Walk over to your radial docking connector, right-click and select on of the Plug options. Docked will link the two vessels together as if they're docked. Undocked will treat them as separate but attached by the connector. * Board your vessel again, and you can right-click the winch to get a bunch of options for controlling it. Another good option is to use the electromagnet. The easiest way to do that is to attach the electromagnet to the end of the winch in the VAB. Then you should be able to either manually move the magnet to the target vessel and attach it, or position your crane over the target and just extend the winch and let the magnet drop down. Right-click the magnet to turn it on or off. The key to this stuff is to practice it on the launch pad to get a feel for how the different KAS parts work. Build a simple vessel like this one, with a crew pod and RTG, KAS ground pylon, two horizontal winches, an electromagnet and a radial connector. A Kerbal on EVA will be able to grab the ground pylon. Attach it to the ground a few metres away from the ship, then play around attaching different things to it until you figure out the best way for your crane. EDIT: This is my mun crane, the Colonial Spider, carting an MKS module from its landing site to join with my in-progress base. You can't see the radial docking connector, but it's there on the top of the module. Amongst other supplies I jammed in those containers were a handful of pipe connectors. Turns out anchoring the module in place with a pipe is a great way to help keep everything stable.

There are two config packages for TAC LS, one for the stock configuration and one for realism overhaul. One of those is required and if you don't manually select one it will default to the RSS config. And that pulls in RSS and several others as dependencies. So manually select TAC Life Support and the TAC Life Support Stock Config.

You might want to also try it with a slower speed, and worst case try with a different USB cable. I've had several arduinos arrive with cables bad enough that I couldn't talk to the board at all.

This evening I've uninstalled my local build of the old 0.16.1 plugin and switched to zitronen's 0.17.1. Added the new bits to my packet structs, and everything's running smoothly with my controller. When I get some time over the weekend I'm keen to update my controller to read the new ActionGroups field in VesselData.

If you're using KAS winches, adding a pipe or two for lateral stability will make life a lot happier.