pincushionman

Yes. To describe things that may not be apparent in the title, like (early in career) what experiments it carries, number of stages, number of crew, part contracts, etc. The "name" usually covers the intended destination. It was REALLY important before we got the ship thumbnails.

Do other sources (Cable box, Blu-Ray, etc.) send 5.1 sound via the HDMI connection? * oh, just saw the sentence about the HDMI being on the graphics card. You may be out of luck; you'd need to consult the graphics card manufacturer's technical support. AND the motherboard's, since they need to talk to each other for it to happen.

I was going to be witty and respond to that, but then I thought better of it and realized I'd be derailing the thread. EDIT: dang new editor. You used to be able to abuse the quote blocks for comedic effect. SUPPOSEDLY you can use the Inspect Element options to do it, but it doesn't stick.

NASA blatantly uses FAR and KJR. That airplane makes it look like a few of 'em use Infernal Robotics and pWings too. EDIT: Oh, I didn't realize that plane was a Burt Rutan hack*. That guy pretty much says "I want a plane that does…" and then he makes a plane that does it before anyone tells him he can't. * hack in the sense of clever and impressive

All we have is clay.

They're mods.

What would numbering these engines accomplish for you? You don't have maintenance actiond to track. Failure messages don't specify which instance of a part was damaged or destroyed. i can see where this might come into play during roleplay, but as far as the gameplay goes it doesn't go into those sorts of details.

Um…you do know at least one of those is a photoshop hack, right? This land across the street from my office regularly (my company makes one of the fuselage sections); I don't think it's long enough to get the entire fuselage in at once.

I don't think that counts. Ore-related contracts are separate from surface sample contracts, and ore isn't even "science" as defined by the game. It might be possible to add the Kerbals' "collect surface sample" function to the ore drills via a module manager script, though.

At the risk of sounding daft (as I am not knowledgeable (very) in general relativity), I was under the impression that the existence of mass was one of the axioms and therefore not, technically, deriveable from the theory (the existence of spacetime as a manifold being another one). Inertia and gravitation are consequences of mass. That doesn't mean you can't prove it, though. The theory states that "IF mass exists, THEN these predictions…" And all predictions thus far are consistent with observations except edge cases involving quantum length scales. Now, correct me if I'm wrong (I'm reaching even further into the bag of things I don't fully understand), but the existence of mass is not an axiom of quantum mechanics, and it really is a consequence of the interaction of fields (in particular, the Higgs). And has been observed to be consistent with said theory, again except for edge cases. …But in either case, the existence of mass is well-established in both theories, as well as in the simpler Newtonian theory. The success of all these makes a theory without mass a pretty tough sell. Exactly what mass is is still a matter of debate, but that is a far cry from questioning its existence. Now, one could conceivably refactor GR so that mass is not an aciom but a consequence, but you'd need another thing to take its place as the axiom, and there's little reason to even try to do that. Occam's Razor and all that.

It's probably there, under other dirt, and it weathers between visits. So, pretty much erosion in action. what kind of ground is it? Dirt? Rocks? Vegetation?

I imagine a big part of using "spacecraft" is that it sounds more official or professional than "spaceship," which conjures images of Star Destroyers and the Enterprise. Which are things we definitely have not at this point in time. Where is the line drawn? Not sure, but we certainly haven't reached it in anything we've built. People get opinions about names. Even dealing with water vessels, arguing over what is or is not a "ship," a "boat," a "raft," or a "watercraft" is a little too much Serious Business for my taste.

Good luck coming up with a short (or even long, really) list of categories. I can't even count the number of skill codes at my company that just have "engineer" in the title. I myself am a stress analyst (an engineer); I've got responsibilities in design support, manufacturing support, and product certification. My company makes aircraft components (nacelles, thrust reversers, fuselages, etc.).

I thought I read in one of the devnotes that fairings, when used as an interstage, would add a virtual strut in the 1.1 code. Can't remember when I read that, though. Either way, not how it is now, and doesn't address how to actually attach it. There is the technique of attaching decouplers, then docking ports, then one mating port under one engine, then the "mating" multicoupler, then stuffing the rest of the docking ports on that side. Only one is part of "the stack," but the others dock up when the physics engine starts. I've heard that works.

I'm going to go so far as to say you have too much booster and not enough center stack. You have six massive boosters and a center stack that looks to be only as massive as two boosters. And the boosters are stacked tanks. As a result, the CoM of each booster will move back as fuel drains, and there isn't enough mass in the center stack to "overpower" that action - especially if you're running the center engine at the same time (as its own CoM will also be moving back). Are you running seven engines, or just the six boosters? If you're running the center too, you probably have enough TWR to try it using only the boosters and using the center engine after you drop them. Picture in the VAB, then drain all your first-stage tanks and compare the positions of the vessel CoM. I'm guessing it starts too far aft and doesn't exactly get better as fuel drains. Also, describe your turn. If you're trying to turn more than a couple degrees from prograde at 350-ish m/s (sound barrier), you're screwed.

I'd be shocked if the physics didn't behave differently. Remember, we're going from PhysX 2.X to 3.3, I think, which is a lot more involved than simply "you can now use multiple cores, guys." A lot of the underlying code had to change to accomplish just that, plus any new features or performance tweaks they added in that time frame. If implemented well, these kinds of changes are largely transparent, but if anything is noticeable, it's usually in edge- or corner cases. Thing is, "edge case" pretty much describes KSP's implementation of game physics.

Doesn't something like Telemachus allow you to post some of the info to a second monitor via a webserver? I thought I also remember someone trying to make a glass-cockpit tablet app that would accomplish much the same thing. not sure it would be fast enough to emulate the navball, but if you're creative you might be able to get enough info to fly.

If they're identical engines then your Isp is that of the engine type. If you mix and match (i.e. you use Thuds or Twitches off the side of a tank for extra thrust, in addition to a central engine) you need to do a weighted average against flow rate.

My wife is at work tonight. Hospital doesn't close because everybody wants dates! But we dropped the boys off at the Y on Friday night and slipped off for…Star Wars. That spacey enough for you?

I'm going to agree with pandaman above and point out that the aero model isn't the issue here, as the only "closed" parts we have are service bays, cargo bays, and fairings, which already exclude their contents from drag. You can't make any other "closed" shapes without FAR. It's the friction interaction between objects that's the problem here. In the animation below it should be obvious the drag is so low as to be negligible, and yet Bill slides off like it's an ice rink. As XrayLima also mentioned, the other week in Devnotes they noted a lot of work going into dealing with inter-craft interaction of this nature (I believe the activity described was driving a rover into another vessel then flying it to the island aerodrome), which SOUNDS like it should be an edge case, but as everybody here knows, we do it all the time. And Hodo, your Jool transfer with your rover is a whole 'nother issue. First of all, space, so no drag. Second, during non-physics timewarp the vessels don't interact at all (let alone this glitchy stuff), so they just pass through one another like ghosts and just follow their own orbits unless you dock 'em.

Well, given the short Munar cycle, one could easily use that as the basis for the week-equivalent. It wiuld also be a stronger and more culturally-universal concept than we have in our world. "Muuk" = 6 days. As for a month-equivalent, Kerbin has an additional lunar marker we don't to take advantage of. Minmus. Minmus' synodic period is 1220132 s = 338.9 h = 56.5 d, approximately. That's a little long, in my opinion, but not out of the question. There's almost exactly 7.5 of these Minmus cycles per Kerbin year. To make things easier, we might base the "Minth" on Minmus' half-cycle - 28.25 days, or 4.7 6-day Muuks. Now we're in a situation like what we have in the real world, where none of our months match the lunar cycle OR (except February) weeks, but they're close. There are 15.2 Minths (of 28 days) in a Kerbin year. Vary the day-in-a-monthh a little bit, and it's pretty analogous to our situation.

You can't. Here's a longer article on the same thing. They said they did it in one take, but you should only take that to mean "we left the camera running the whole time." They only had 27 s of weightlessness at a time, so they cut the 5-minute recovery periods out and smoothed them over using a computer. The spots this happens are fairly obvious if you know to look for them: everyone is in their seats or standing holding on to stuff, and all the balls are on the floor. If you look at the people at those moments, the movement seems a little awkward, almost like somebody did a subtle "impossible match on action" cut - because they did. The fact that they used a camera rig that was fixed between shots and only had a single degree of freedom helped a lot. http://nofilmschool.com/2016/02/shooting-zero-g-behind-scenes-ok-go-new-music-video EDIT: I just watched it in HD, rather than on my phone, and it's not as obvious as I thought. They did a really good job. But it still is obvious where the cuts should be, because the gravity's back.

I second the thought about axial tilt. It would have a much larger impact in the big scheme of things. that said, the close/zero relative inclination of Mun is good for beginning gameplay. First they need something easy to hit, then add inclination before they leave Kerbin's SOI and they NEED it. That's probably why Kerbin-Mun-Minmus system is set up the way it is.

Very likely no, but not simply "because it's android"; it's because of the hardware android is typically built for. KSP physics is very CPU-intensive, and mobile processors simply don't have the power to keep up. Now, that said, not all of the physics going on is hard. The orbital mechanics calculations, for instance, are pretty straightforward. It's the part where relative deflections and internal forces are calculated that curbstomps CPU's. Simplerockets may get around this by…ignoring it and not caring. But it's an integral part of the KSP experience, and much of the gameplay is balanced against building rockets that are strong enough. I haven't played Simplerockets, so I don't know whether that is a concern or not.

Well, I for one am going to have to defer to you here, given that you get to work with the engine internals and all!