IncongruousGoat

I took a look at that earlier. Here's my opinion on it, answer by answer: 1. This answer seems to cover it pretty well. Arduinos are really tiny. Their clock speed is measured in megahertz and the amount of RAM the have available is measured in kilobytes. You're going to have a really hard time fitting the Python interpeter into that. Compiling Python to something that can run on an Arduino might be possible, from a technical perspective, but it's something I (as an experienced programmer) would be apprehensive to try to get working. For your purposes, it's not possible. 2. This only works if the Arduino is plugged into a computer. Not very useful for a model rocket. 3. This looks interesting, but a bit of digging reveals a few problems. It requires 55 KB of system memory, which means a larger or more expensive Arduino. However, what really kills it is that (according to the people who made it) you still need to know C and a good amount about microcontrollers to get it set up in the first place. 4. This is just a manual version of 2 5. Unfortunately, the chip that answer talks about has been discontinued. 6. Not actually an answer. 7. Seems to just be 2 and 4 again. 8. This guy doesn't have any idea what he's talking about.

Well, except then @Cheif Operations Director is stuck writing in C. Now, I like C much more than the next guy, but it's not exactly great as a first language for someone who isn't really into computer science.

Other than hardware not supporting it, no, but there's a couple reasons why Python might not be the best choice for a flight computer: 1. It's very slow. As in, a program written in Python will run slower than an equivalent program written in, say, C, or Java. Since flight computers typically need to be quite responsive, you might not want to use a slower language. 2. It's very abstracted. That is to say, the data types and constructs you use in Python are mostly unrelated to what the underlying computer is actually doing. This makes interacting with hardware in Python a frustrating process. It's possible, but it requires use of weird and obscure bits of the Python standard library. Of course, I speak as someone who thinks Python is largely worthless as a language, so take what I say with a grain of salt.

You can't write the code without knowing what hardware you're using. Well, you can write some code, but you're going to need to adapt it to the particular hardware you're using, and in some cases "adapting" the code means re-writing all of it. Any piece of hardware you find out there will have at least some programming languages that it doesn't support, and about the only language that's guaranteed to be supported everywhere is C. It might be that whatever hardware you're using supports Python (heck, this might be one of the criteria you use when selecting hardware), but it also might not. Whatever the case, it's best to know what hardware you're using before you start writing any software for it. You don't have to buy it right away (though you might need to for testing), but you should at least know what it is.

You're making this for the guidance system for a model rocket? What hardware are you planning to use to control this model rocket? If you've just got a radio transceiver on it and are doing all the computation on a groundstation, you'll probably be fine, but if you want to mount the guidance computer in the model rocket itself then Python is not the right choice of language. There do exist single-board computers that'll fit in a model rocket (think a Raspberry Pi but smaller), but they're expensive and a bit overkill. What you probably want is an Arduino, or something a lot like it. Those definitely do come small enough to fit in a model rocket, but they can only be programmed in C/C++. They won't and, in fact, can't run Python.

Wait. What do you want the result of calling this function to be? Right now, you've got it doing two things: You set the value of a global variable 'c' equal to the value of the input 'b', and you return the value of the input 'b'. The 'return' keyword doesn't do anything with moving variables around. All it does is give the function call a value that you can then assign to stuff. So, for example, you could say something like: 'd = voltage(100)', and the result would be a new variable 'd' with the value 100. If you just call the function without assigning its return to something, the return value is still calculated, but the return value is thrown away (as in, the compiler forgets what it is) immediately, since you didn't tell it to do anything with it.

I endorse this. Not because I want a delta-V view in the map view, but because I want to be able to see my staging sequence from the map view, since it makes flying from map view that much easier.

That's... odd. I just ran that script verbatim through both the Python2 and Python3 interpreters, and both came up with (as I expected) a "name 'c' is not defined" error on line 6. Right, so let's run through what this does line by line and see if that helps you understand what's going wrong. Line 1: Create a new variable 'a' and assign its value to the integer 0 Line 2: define a new function 'voltage' with a single input 'b' Line 3 (in voltage): Create a new variable 'c' in the scope of the function and assign 'b+0' to it. What this means is that the 'c' you've created will only be accessible by other stuff in the body of voltage, and not by anything outside of it. Line 4 (in voltage): Return 'c' from the call to 'voltage'. This doesn't give stuff outside 'voltage' access to 'c'. What it does is make calls to voltage evaluate to whatever the value of 'c' was within 'voltage'. Line 5: Call voltage with b=-100, and then do nothing with the result. What happens here is that voltage is called, it returns -100, and then that -100 is thrown away because you didn't tell Python to do anything with it. Line 6: Compare the 'a' you declared earlier to some variable 'c' (different from the one in 'voltage'), and if so execute the condition body. Now, my Python interpreter throws an error here, since as far as it's concerned 'c' doesn't exist. Which it shouldn't, since you never defined it. It's weird that yours isn't throwing an error here. Line 7 (in the condition started at line 6): Print "Activate Response".

None, for now, and it might stay that way. I didn't pick up Making History when it came out because it didn't add anything I was interested in. Breaking Ground does, and I would have picked it up already were it not for two factors: First, I rarely play stock these days, mostly being buried in the lands of RSS/RO/RP-1, and that's unlikely to change given the lengths I find myself having to go to in order to extract a challenge out of the stock game. Second, my gaming rig (i.e. the only computer I own that can run KSP at a decent framerate) is currently in pieces in a box behind me, and is likely to stay that way for the next 3 weeks because of IRL stuff. Once the turmoil is over I might pick up Breaking Ground... but it's going to take a lot more than good robotics to drag me back to stock KSP, especially to the kinds of things in stock KSP that robotics is good for. Actually, I haven't played KSP in a while, period. Some poking at RO, but my RO install is currently a bit borked and still all the way back in 1.3.1.

Nothing. Yes, literally nothing. I'm floored that the devs are still adding features, even though it's clear (from the existence of the DLC) that sales of KSP itself aren't making much money these days. But, as far as I'm concerned, they could drop all development right now and I would still be happy. Sure, we can all quibble about parts & mechanics we'd like to see added, but let's be honest - we're all enjoying the game perfectly fine as it is. The game, in its current state, is fun. The modding scene is alive and well, as is the community (as evidenced by the fact that we're having this discussion in the first place). There is no feature that Squad could add that would make me like the game more than I already do. It's perfectly acceptable as it is.

Move CO2 from Earth's atmosphere to Mars's atmosphere until the concentration of CO2 in Earth's atmosphere is down to 250 ppm.

Clearly. I admit, I only passed through the southernmost part of the state, and only saw whatever was in line-of-sight from I-90. Stopping at roadside attractions stopped once we left New York and didn't start again until we hit the South Dakota Badlands. Which are stunning, by the way. Highly recommended.

Well, the Saturn I is kind of an odd one, and the history of how it came about has nearly nothing to do with Apollo. The proposal that would eventually lead to the Saturn I was called the Saturn A-1. It was developed (along with the rest of the Saturn family) by von Braun's team at ABMA (later, NASA Huntsville), and had that Jupiter/Redstone cluster as a first stage, the first stage of a Titan I as the second stage, and Centaur as the third stage. It was proposed in 1959 as the fastest way for the U.S. to get heavy-lift capability in excess of that of the USSR, and at first it was greenlit exactly as written. Then, things started getting complicated. The Air Force got involved in the whole thing, partially because of the need on ABMA's part to negotiate with them regarding contracts and supply for Titan I first stages, and partly because these early LV programs were organizational tangles. From the Air Force's involvement came a demand for a 160-inch hydrogen-fueled second stage (as opposed to the 120-inch kerosene-fueled Titan stage then planned), which would be needed for Saturn to be able to launch Dynasoar. After some political twists and turns, including a largely fanciful proposal for a Titan-derived heavy lift vehicle from the Air Force, the Saturn program was eventually switched over to that 160-inch hydrogen stage, for use with Dynasoar. The second production lot of Saturn Is was even configured to launch Dynasoar... which was switched to launching on the Titan 3C, and then cancelled. Saturn I, of course, only flew a handful of times before being replaced by the (Apollo-derived) Saturn IB. The worst part is that I just covered a part of the history after 1959. The earlier stuff is even wackier, especially some of the configuations that were considered for that first stage. Chestnuts like an R-7-ish purely parallel-staged booster, or a first stage with the liquid kerosene tank wrapped around the LOX tank. There's some more reading on the subject here: http://astronautix.com/s/saturni.html

Wait, what? C's execution is as linear or non-linear as you want it to be, and if pointers are causing Heisenbugs then you need to seriously re-assess your code. Also, there's plenty it's good for other than just drivers. Kernels, operating systems, servers, compilers, interpreters, VMs... Anything that needs to perform low-level interactions quickly and efficiently. It's also not half-bad for supercomputing applications. @Nivee~ To address the original question... what part of it do you need help with? If it's the numerical analysis, I can't really help you, but if it's help with C you're after then I can answer questions all day.

That's the thing, though - I'd had the vehicle inspected a few weeks prior. I guess my mechanic didn't think the rust damage was bad enough to warrant mentioning. Either that, or he just did a bad job of it.

You don't need the contract to complete the challenge anymore (see the challenge rules for further elaboration), but if you really want it, there's a link to it in the first continuation thread (https://forum.kerbalspaceprogram.com/index.php?/topic/145204-the-ultimate-challenge-originally-by-just-jim/). That link will give you a .zip archive which contains a text file and a persistent.sfs. Make a new save, then overwrite its persistent.sfs with the one in the archive. That will give you an empty career save with the contract and 10 million funds (which should be more than enough). Again, though, you don't need it, and it's easier to just start up a sandbox game and go from there.

Oh boy. So, I (very) recently moved from the East Coast to the West Coast. My original plan was to simply load all of my stuff into my car (2002 Subaru Legacy) and start driving west, with a friend along to help share the load of dealing with how mind-numbingly boring Minnesota is. For the first 2 days, everything seemed to be going all right, but on the third day we ran into some snow in the Black Hills, had some hard driving, and had the brake light come on on the car's dashboard. Now, I didn't think anything of it at the time, assuming that the sensor that detected whether the parking brake was engaged was broken. However, as we drove across Wyoming, we noticed the brake pedal becoming increasingly spongy. When we finally pulled into Jackson, WY for the night, you needed to push the pedal nearly all the way down to get any meaningful deceleration. We decided to take it to a mechanic in the morning, get it fixed, and keep on driving. It wasn't fixable. Two mechanics and a lot of tense waiting later, we found out what had gone wrong. The right rear brake line had rusted through and was leaking brake fluid everywhere. Now, normally this wouldn't be so bad to fix, but on this particular car the right rear brake line ran above the gas tank. This was a problem because removing the gas tank would require taking apart most of the underside of the car, which wasn't possible due to the sheer amount of rust damage.The car was technically drivable, but it wasn't anything that either of us wanted to take on the highway. Thankfully, there's a U-Haul rental place in Jackson. We rented a truck and trailer and hauled the car (and my stuff) the rest of the way to Seattle, where I (very, very carefully) drove the car the 6 miles from the U-Haul dropoff point to the Airbnb in Redmond where I'm currently staying. So now I'm stuck here in Redmond without a working car, 2 miles one way from the city center (where all the grocery stores are), and in a neighborhood where the bus only runs once every hour. And I won't be getting a replacement for this car for 3 weeks, because of reasons. Yaaaaay.

Sure, it could be implemented... but, IMO, it takes a LOT of the fun out of the game. Where's the challenge in flying a grand tour when you can build magically create arbitrarily big ships at arbitrary locations? I mean, sure, it makes sense for a save where you're setting down massive amounts of infrastructure... but at that point you've already probably modded the game, and as mentioned above, there's a mod for this. Several, in fact. Also, it pushes suspension of disbelief a little too far. I let current stock ISRU slide because rocket fuel is, chemically speaking, not very complicated, but building a rocket is a whole nother story. You need lots of very precisely machined/fabricated parts, many of which cannot be built without lots of supporting infrastructure. Kerbals on Kerbin can built rockets because (in principle, at least) they have an entire planet's worth of supply line behind them. The same cannot be said for an automated lander on Duna. One of the nice things about KSP is, simplifications aside, how much it's based in real rocketry and real physics, but part manufacturing respects neither of these.

None. Honestly, I'd forgotten that it was even a feature.

As an update, I got my B.S. in Computer Science. No job in aerospace, but that's okay. It turns out I'm just not that interested in GNC type things.

Location: The waiting place. 6/10, but what are you waiting for?

@KSK What are the rules regarding adjectives and adverbs in Old Kerba? Actually, do we have a complete description of the grammar of Old Kerba lying around somewhere? I ask because I'm interested in determining if Old Kerba can be described using a context-free grammar (which would imply all kinds of things about how easy or otherwise it is to parse by machine).

We have music! ...aaaaand scrub. High-altitude winds picked up.

Launch delayed to 11:00 PM EDT. No official reason yet.

Well, the way they're talking about it makes it seem like it's going to be a pretty comprehensive black-box sort of SDK, which means that the frontends that will be built for it are going to be pretty trivial. In either case, the SDK itself is free & open source, so I'm sure that someone will come up with a free frontend for it sooner or later. Maybe, but, again, I'm going to wait until we actually have our hands on the thing before I start passing judgement. Also, I think you underestimate the dedication of the kinds of people who get strange things to build in strange environments.