stibbons

Coincidentally, this list bubbled up shortly after I watched Amy Shira Teitel give a talk about the Dyna Soar for the Sydney science festival. That talk made me want to read more about the Dyna Soar, as well as pick up her book.

Your list of "facts" is full of opinions.

My KSPSerialIO fork has had a handful of updates, fixing things that worked on one platform but not another. It's now run for extended periods on my Linux gaming rig, but I haven't given it very thorough testing on OS X. Would love to hear from anybody who's using it in anger there. I took the whole setup to the Sydney Mini Maker Faire again this last weekend, and had it running at the stall my maker space had set up. Very popular with kids who loved mashing the big red stage button, and people of all sizes interested in learning how it works. As part of the prep for that I spent a frantic few days finally wiring up the analogue gauges that show radar altitude and vertical speed. Those things have been sitting in the panel unconnected for more than two years, shame on me. Work on the new enclosure is going much slower. I'm still having trouble getting acceptable results from the CNC mill. I'm on the verge of giving up and taking my designs to be cut in a professional mill shop. We'll see. Also having vague thoughts about how to make the plugin side of things easier to work with. I'm tempted to try something new based on telemachus or krpc. And writing my own plugin implementing a protocol similar to the Objects in Space serial protocol is starting to sound like an attractive option.

Answered in the FAQ on the website.

I'm not a huge fan of using this thread for anything other than showcasing people's projects. But: The MAX7219 is a constant-current driver that's really only designed for powering LEDs. They're overpriced and unsuitable for this stuff. One or more daisy-chained 74HC595 shift registers will be fine for expanding the outputs. Then, for each switch, a common transistor should be fine. I highly recommend reading SparkFun's transistor tutorial to get a handle on using them as switches. Each light will need a separate one, and you should have no trouble feeding the output from the shift register in to an NPN transistor acting as a low-side switch for the light.

The flag my space program has been using since flags were introduced. It's an interrobang, that most noble of punctuation, on a purple field.

You might be able to optimise this even more by tracking the current value the LED is displaying. Then you only need to update it when the associated VData variable has changed. After that, yeah, all of the floating point calculations are really hurting you. The last time I checked, an ATMega 2560 was roughly ten times slower with floating point calculations than integer operations. If you can cast the AP and PE to longs and get the dV calculations done that way it would probably help a fair bit. Doing it on another micro adds a lot of complexity. As Freshmeat said I'm using multiple micros, with comms between them over I2C. The problem there is that the stock Arduino Wire library is hilariously slow, and trying to offload processing like that could easily just leave you with an even bigger time deficit. I ended up using my own I2C implementation (based on Atmel's application notes) and it's working OK, but it took me a while and I haven't yet taken the time to package that work up in to an easy library. I have been idly toying with the idea of writing a new plugin with a lighter weight and extensible serial protocol. But that will be quite some time away.

Pretty much what @Freshmeat said. The plugin would need to be updated to integrate with Action Groups Extended, and the changes to the serial protocol that would require seem to me likely fairly involved. The keyboard emulation trick is probably the best way, at least for the time being.

Read up on antenna properties. Depending on which antenna you're using, you'll be able to calculate how much power you'll consume per second while transmitting. From there you just need to ensure that your total output from your solar panels is close to or exceeds that. The wiki entry on solar panels also gives figures for how solar generation efficiency varies with distance from the sun, which you'll need to take in to account when figuring out how much charge you'll be getting.

A notepad and pencil maybe?

I ninja'd your post with a link to the connection rules. The important thing is that both ComSats need an antenna connected for the link to be established. For your setup, ComSat 1 has a dish pointed at ComSat 2. But the only possible connection from ComSat 2 to 1 comes from 2's omni antenna. So you'd have to be within omni range for the link to be established. My preferred setup for the early game is a comsat with one Communotron 16 omni, and one of the first dish antennas. Launch 4-5 of those in identical orbits around 750km. The omni should be enough to keep links between satellites as well as a link to KSC. And then set the dish on each satellite to target the active vessel. That will give you uninterrupted coverage around the Kerbin system.

Comsat 2 should have a dish pointed back to Comsat 1. Likewise Comsat 3 should have a dish pointed back to Comsat 2. I'm actually a little bit surprised you've got any connection between satellites at all. But that might just be because you got lucky with the angles. EDIT: The Remotetech guide does have some documentation on connection rules that should hopefully clear this up for you.

Real life has kept me busy, so I didn't really get a chance to start a new hard mode career in 1.1.3 until this week. I'm pretty lousy with plane construction, but today I managed to get an early tech tree air breather running. Flew it on a few surface observation missions around KSC, and this is the start of a much longer trek to take temperature readings a good quarter of the planet away, around 45°N, 50°W. Really hope I make it.

Margaret Hamilton is awesome. She was the director and lead programmer for the software engineering teams for Apollo and Skylab. Dr. Katherine Mack is a pretty cool theoretical astrophysicist and science communicator who's well worth following on the social medias.

I've been closing the doors and they survive reentry. Only to explode on impact when I land on them. I'm certain similar craft used to be able to land on a Science Jr, but now I'm adding extra radial chutes to slow down a bit more.

The current build runs on OS X, just follow the directions in the installation guide to get it working. https://github.com/KSP-CKAN/CKAN/wiki/Installing-CKAN-on-OSX

Graphotron is another option for logging and charting telemetry. http://forum.kerbalspaceprogram.com/index.php?/topic/107461-part-112-graphotron-v04-may-31-2016-track-plot-sensor-flight-data/

Welcome! The API docs you've been looking at are a little old. I'm not sure if they've been updated for KSP 1.1. http://docuwiki-kspapi.rhcloud.com/ is a much nicer resource. I think you can do it by creating a class that derives from MonoBehaviour, and specifies the KSPAddon attribute to load at the main menu and has the once attribute set to true - ie, it'll persist for the entirety of the game. In theory, that means that class's OnDestroy() method will be called when the game is shutting down. Something like this: [KSPAddon(KSPAddon.Startup.MainMenu, true)] public class SaveSyncer : MonoBehaviour { void OnDestroy() { // Do save file finagling here } } I haven't actually tested this, though.

As far as I'm aware, the FlightGlobals class should always be available. (taking a guess here, but do RemoteTech addons also derive from MonoBehaviour?) So you should be able to just do something like Vessel ActiveVessel = FlightGlobals.ActiveVessel; If that's not working, I can only suggest asking in the RemoteTech forum. They'll know much more about how their addons are supposed to work. EDIT: jinxed by @Crzyrndm

My primary platform is Linux, which is why I'm invested in seeing some cross platform support. I was really hoping this change would also help with Windows 10, but while it works everywhere else, KSP on my Win10 install was either not reading the port at all, or locking up hard. Was pretty impressive actually. I'll let you know when I have anything useful there.

My tastes range fairly widely as well. But when I'm working I need mellow instrumentals to concentrate. Penguin Cafe Orchestra is a recurring favourite.

There's probably a few more around.

And I'm saying that subjective opinions on what is or isn't critical information have nothing to do with QA, hence it isn't justified at all.

Sorry, I don't understand the link you're trying to make here. Disabling debug facilities in a release build is a perfectly normal and reasonable thing to do. It's orthogonal to the QA process. How do you get from "they didn't give me a cheat menu" to "nobody tested this"?

I managed to get a new fork of the KSPSerialIO plugin up and running on my hardware. http://spacedock.info/mod/850/KSP Serial IO (cross platform)