Kerbart

No. No. No. Please don’t spread misinformation, this is exactly what I meant earlier when I said “claiming fair use doesn’t make it fair use.” It’s ok when you’re not profiting from in because you have explicit permission from Squad to do so. Fair use has nothing to do with it—and this would hardly be a case of fair use to begin with. Not making profit is not the criterium for Fair Use. Fair Use is intended to cover “copyright infringement” as “collateral damage”. Kennedy gets shot, and a newspaper uses a photo of that event without permission—that is not fair use, but copyright infringement. Another newspaper writes an article and publishes the same picture to show what the lawsuit is about—now it’s fair use, because it’s not a picture of the assassination but an illustration of what the lawsuit is about. Copyright infringement is very much independent of whether you’re making money from it or not. Do you think it’s legal to copy KSP from a friend and not pay for it? Of course not, even though neither of you is making no money on that deal—it’s still not legal. Making money has nothing to do with whether it’s copyright infringement or not—having permission from the copyright holder (or not) does.

In addition, a lot of people will tell you “fair use” which is generally interpreted as a “license to steal” (it’s ok because it is fair use), which it is not. Claiming it’s Fair Use doesn’t make it so—it has to meet certain criteria. I am not a lawyer (but having photograpy as a hobby kinda forces you to into the subject a bit) so I’ll leave the details to them, but in these kinds of discussions I see way too often “it’s fair use, so it’s ok” when it’s not.

The bottom line binds the variable gx to the return value of read_gyroscope. But since it doesn’t have a return statement, the return value is None. So what you probably want is something like this, in lieu of actually reading the gyroscope hardware port: def read_gyroscope(): return 64.8 gx = read_gyroscope() print(gx)

But gx will now be None, because the function isn’t returning a value.

LEFT Alt, to be more specific, if it’s not working you’re probably using the right Alt key (marked “Alt Gr” in some countries).

If it happens faster than your neurons can process that you would barely notice anything. One moment you’re there, the ne...

With five years of mods, I think it's pretty hard to come up with something that hasn't been offered by mods yet. But since apparently it's really easy, pray tell, what would be this magical content to be offered in, say, the next three DLC's? Meanwhile I keep hearing that parts offered by DLC "have no value," yet at the same time we see here in the forum complaints over: mods being abandoned mods causing crashes mods depending on other mods that are then being abandoned. In that sense, the DLC parts are as good as stock. They'll be refreshed with every update, they'll work without dependencies and if you share craft with others they'll virtually always work as most players will have the DLC on their machines. For me the implicit contract that Squad offers with DLC - "these parts will continue to work with each update" is worth the reasonable price asked for it.

That looks very much like the fonts you'd use on a drawing board, tracing them with a pen through a template. We used the DIN (German) version in college, which has a more rounded 3, but I bet there's some kind of ASA standard for drawing letters. DIN Normschrift:

You can simply change the values stored in a dictionary, for instance like this: fd['x'] = 150 fd['y'] = 230 But it's more useful to see things in perspective, so here is a more elaborate example: def main(): # initialize flight data fd = {'x-pos': 0.0, 'y-pos': 0.0, 'mass': 200.0 } lift_off(fd, max_height=50) ... def lift_off(fd, max_height): while fd['y-pos'] < max_height: fd['y-pos'] += 10 While the code itself is complete BS, it demonstrate how you'd store flight data inside a dictionary, access it elsewhere and modify it as needed. It looks cool, but I think it's the sensor only, you will probably need a processing board as well. If that's needed, start out with the Circuit Playground Express; it's great fun, and has a ton of sensors and leds to play around with and get some hands-on experience in what you want to achieve. What you probably want to do is create a function that reads your sensor, like gx = read_gyroscope()

No. The dictionary (let's name if fd for flightdata) is the variable. (Python pro's spare me the flaming I know we're mangling semantics here), but it helps you in reducing the number of variables you'd have to pass around (or to bypass that define as globals). So instead of: x = 100 y = 200 mass = 350 (and many more like those) you do: fd = {'x': 100, 'y': 200, 'mass': 350} And instead of doing print(x) you now do print(fd['x']) - but in return for that little extra typing you only have to pass one variable around, that holds all your flight data values - accessible through keys that are defined as readable strings

You are correct. it's a string. look at it like label for a value, or what it really is - a key in a lookup table.

The dictionary is a list of values, just like [1, 2, 3]. But instead of referring to them by position df[0], df[1]. df[2], you refer to them by name. Names suggest text (although dictionary keys can be numeric as well) and text needs to be enclosed in quotes to differentiate it from code. df = {x: 100. y: 200} This would create a dictionary with keys of the values of variable x and y. So if x=5 and y=0, what you're really doing is: df = {5: 100, 0: 200} If now, somewhere in your code x gets another value (x=6) your code will run into problems: print(df[x]) Now really means df[6], and that is not defined in the dictionary. Aside from that, what you really want is something like this: df = {'value of x': 100, 'value of y': 200} # but that is a lot of typing # so instead we use shorthand names: df = {'x': 100, 'y': 200} There are better ways - using classes - but I'd focus on the dictionaries for now. they get you results quicker.

One of the nice things about Python is that the code tends to be so clean and simple that there's really no gain in using pseudo code. That's why you will hardly find any pseudo code in books of Python programming; what's the point? Yes, but I made a mistake there (rushed, using iPad to enter code, etc). Inside the dictionary you use labels as keys, so it would be: flight_data = {'x': 0, 'y': 0, 'mass': 0.0} At that point you can refer to them as indexed values, but instead of a numeric index, you can use the labels: print(flight_data['x']) print(flight_data['y']) For brevity you could shorten flight_data to fd, and create constants for the labels at the top of your code X = 'x coord' # allowing for more elaborate descriptions Y = 'y coord' MASS = 'mass' VX = 'x velocity' # --------- # some code # --------- fd = {X: 0.0, Y: 0.0, MASS: 200.0} # -------------- # even more code # -------------- print(fd[MASS]) Python doesn't really have explicit constants, but a common practice is to write them in capitals, to indicate that you're not changing them. "But wait," you say, "aren't those effectively the global variables you were trying to avoid?" Technically, yes. But remember that the main issue with globals is that they're being changed when you don't expect it. These are constants. They don't change. So you're not breaking "rules" (good practice, really) with them. Check out adafruit.com - they sell all kinds of little circuit boards that run Python. Their Circuit Playground Express for instance comes with a ton of input and output ports, leds, sensors, and easy ways to interact with them. It runs a special verson of Python called Circuit Python which in itself is a fork from micropython, a Python build intended to run on embedded systems. Adafruit is now even equipping Arduino's (what, eventually, is what you probably want to use to control your rocket) with Circuit Python. The Adafruit website has a forum and tons of examples on how to make their circuit boards interact with other hardware.

Squad was producing software in a naive totally unsustainable way: sell software with a promise that it's continuously being updated for a fixed pay once price. That worked very well in the beginning when no one had the game and copies of the game sold like fresh donuts. You conveniently forgot to mention that the time between updates grew longer and longer, and that new content with each update became less and less, as the market for KSP became saturated (everyone who wanted to buy the game had done so already) and the income stream dried up. Since T2 has taken over and Squad has started selling DLC. updates have become more frequent, much-requested functionality has been added to the base game (delta V, precision node editing, etc) and more parts have been added over the past 12 months than in the three years before that combined. Not only that, those parts cover a few areas that were highly in demand - robotics, propeller engines, large tanks - making clear that we now have a Squad that is listening to its customers and creating the content it is asking for. And all for a reasonable price. The propellers and blade are coming as a complete surprise. If this truly was the evil money-hoarding-squeeze-the-last-penny corporation, it would have been an additional DLC release. Instead, it's part of something (some of us) already paid for. There's your free content (in a way). All I see is a lot more content, a continuation of Squad's spirit of giving us tremendous value for money. Still waiting for those micropayments and banning of mods that were predicted by the nay-sayers.

If I remember correctly that was about one specific mod that bypassed paying for content that would be unlocked by a DLC. The minute someone rips off Squad's DLC and starts posting them here I can assure you T2 will shut down those as well -- but that's far from "banning mods."

The Oberth effect has to do with the rocket engine doing more Work (Force x velocity) and while there definitely is a positive effect, most of the gains of a low altitude intercept come from the simple fact that with a higher orbital velocity, you need to slow down less to inject into orbit. The gains are very real and it’s a legit reason to inject at low altitudes but unless someone shows me the math I’m not convinced it’s mainly Oberth.

The problem is, that if you're only pulling on one side, the scale is going to show 0 as the whole ensemble is going to accelerate with 1g in the direction that you're pulling. If you want the scale to remain in the center, you have to zero that force out. That's what happens on earth. When Yo Mamma steps on the scale, it's not just being pushed on from the top - it would sink through the surface of the earth. The earth is pushing back as well.

There's a couple of solutions, depending on what does cryptic (*cough*) variable names represent. If these are flight parameters representing values to be shared between various functions, you could pass them along through a dictionary like this: def main(): flight_data = {x: 0, y: 0, total_mass: 0, t=0.0} pre_flight(flight_data) # initialize flight data lift_off(flight_data) grav_roll(flight_data) coast(flight_data) circularize(flight_data) Some will argue that it's hardly better than global data, or that it's only semantically different from global data, but at least you're aware of where the data resides. And it's easier to scale. Perhaps an in-flight calculation needs data that is retrieved from simulating 5s of flight. Now you can, using cloned flight data; with one set of global variables you cannot. One step further would be to create a class for your flight data, which can also take care of some of the recurring data processing. I'm making stuff up as I go along here, but something like this: def main(): fd = FlightData(0.0, 0.0, 200.0) pre_flight(fd) lift_off(fd) # etc class FlightData: def __init__(self, x, y, mass): self.x = x self.y = y self.mass = mass def apply_velocity(self, v, t): '''Apply velocity vector v for t seconds''' self.x += v.x * t self.y += v.y * t You could then even take it a step further and have a RocketShip class: class RocketShip: def __init__(self, name): self.name = name self.flight_data = FlightData(0.0, 0.0, 200.0) def lift_off(self): while self.flight_data.y <= 200: # do lift-off stuff ... And now your main code would look something like this: def main(): rs_cheif = RocketShip("Cheif's rocket ship") rs_cheif.lift_off() rs_cheif.grav_roll() # etc Instead of having one big monolithic block of code, everything is compartimentalized which makes fixing issues a lot simpler.

85 tons. It’s a common gotcha in physics exams. Imagine a 1 ton weight hanging from a rope attached to the ceiling. Obviously the force pulling on the rope is one ton, right (yeah bring it on, pedantic 9,815 N whiners; the units are not the problem we’re dealing with here)? Now replace the ceiling with a giant hand pulling the string. Has anything changed? But now there’s an upward force of one ton at the end of the string! Yes, there always was. In an equilibrium there’s always two equal (but opposite) forces at work. Still, for two 85 ton vessels keeping each other in a stable spin there’s 85 tons pulling, not 170. If you’re using plain FE360 (not that anyone would, in space), you probably want some safety margins (based on a max elastic deformation limit of 300 N/mm2, so let’s settle for 150 N/mm2, that gets us a cable area of 5,560 mm2, or a cable diameter of 84 mm. That is substantial—about 33/8” for the non-metric speakers here, and likely adds to the weight, though it’s likely we’d be using a light-weight, high tensile material in reality. Good point.

That is an excellent thought. On earth we don’t have to deal with that (gravity, atmospheric drag) but in space that will likely be an issue. It should dampen out under continuous spin though, eventually... right?

Some will say that introducing globals to solve certain issues with the way code is structured is a bad idea, but they probably never ran into a challenge like this. Still, the tendency to introduce Heisenbugs into your code is a reason to avoid it as much as possible.

Checking for True boolean: if var: ... Checking for False boolean: if not var: ... As @Shpaget mentions, if you have two abort functions, call them something like hard_abort and soft_abort; depending on subtle casing differences will be a recipe for long nights of painful debugging later on.

Progress! That’s what we do it for The one thing I would recommend is using more descriptive names for “inflight;” what’s the difference between the four of them? I don’t intend you to answer that question here, but rather inside the program; if they represent various flight stages consider “stage_liftoff” “stage_roll” etc. A few more generic suggestions: An if statement checks for an expression that yields a boolean value. So instead of writing “if var == True:” you can simply type “if var:” which is preferred as there is less code to read. While interchanging True and False with 1 and 0 perfectly works I’d stick to boolean values for consistency. It’s one of those things which makes your code easier to understand. Future you will thank you common practice in python is to separate words in names with underscores, and use all lowercase. Since what you’re calling has to be a function, make it emergency_abort() instead of Emergencyabortfunction() While most of the experienced coders would likely do it different, finding your own way is important in learning how to code. Congratulations on reaching your (preliminary) goal and keep going at it!

And all of that cuts both ways. Profit is a delicate balance between many things, and shaking things up radically is a desperate last-options move. It’s highly unpredictable what any “game destroying” actions would result in revenue-wise, while clearly destroying the interest of the game, so introducing per-launch micropayments or “pay 50 gems to unlock robotics” seems out of the question to me. With leadership coming from other industries comes experience, so they have learned that the point of buying outsider companies that don’t fit in your own company should remain independent lest you’d lose the whole point of buying them. Really, T2 on the whole brings stability to Squad, I think. It’s unlikely that it’s a coincidence that we see so much more content being added to the game now (“but as paid DLC,” some will whine. Why yes, how else would they get paid for developing it?)

Keep in mind that the only reason a large publisher buys a small developer is to utterly destroy their game and alienate the fan base, burning the entire investment made into it. It’s the only reason. No other motivation exists.