AngusJimiKeith

Afternoon, EST. Don't know the exact time. Oh, it's more lift, more drag. Hm. Not sure how I feel about that. At least it's accurate.

Already snagged the angled intakes! ...Of course, I have to see how well my designs hold up in 1.0.2, since it appears there's less lift and more drag... (I had a design that I tested up to 1,500 m/s in 1.0 but didn't have time to make an entry of it. I don't think it'll go so fast in the update.)

Had it on for a while. It's fun on a launch...Then I realized the constant shaking was literally giving me a headache. Also, I was trying to compensate for it, because it really does look like the craft is wobbling around, rather than the camera. Still have it on for IVA, which is really where it belongs.

It would also be pretty cool to pull off something like GOCE, where you have an ion *just barely* compensate for the altitude you lose from drag. Wouldn't be practical in KSP for any long amount of time though.

I hadn't actually thought about that. My inclination would be "on," though I can't give a good reason. Additionally, another question for my own scenario: what's preventing someone from diving from a higher altitude to pick up speed and then pull up into level flight? Ok, the F3 menu probably helps prevent that, but it is a possible exploit. EDIT: Alright, that sounds good Slashy. I confess I'd never be able to hold steady at one altitude within +/- 5 meters for long - can't even do that in the low atmosphere!

I see where you're coming from. It's definitely possible to "lob" craft up to ridiculous heights (The SP-1C I used in my entry broke 40k on an entirely unintentional zoom climb once - I had stopped paying attention for a bit too long. ) My argument is that as long as it is lift, and lift specifically, that keeps the plane up, then speed doesn't matter - if you drop below the speed required to hold altitude from lift, you either fall or go ballistic. Showing a Lift/Weight ratio >= 1 would be the ideal solution. However, in KSP, there's no easy way to measure lift. I've been spoiled by the likes of KER and now AeroGUI but stock obviously doesn't have those tools. I don't know what the best solution to this issue would be. Any other thoughts? (Slashy?)

Plus or minus 5 m/s vertical speed for some time is a good limit, yeah. That is for altitude. Not being able to maintain speed doesn't bother me so much on altitude runs because you're generally pushing the craft to its limits, so it might not have the thrust to stay that fast. As long as it maintains lift, I'd say that counts. For speed runs, however, consistent airspeed does become a factor, and I'm much more inclined to say it needs to be maintained. (Also, note that I am separating "speed" and "altitude" runs here - while doable on the same flight, they are different objectives and should have different constraints.) EDIT: In the interest of fairness, I've just noticed this: Error in the leaderboards: Slashy, the 803 m/s on my flight was not in level flight! That was in a dive on the way back to KSC. My max in level flight is essentially what was shown on the navball in the altitude picture: 761.8 m/s. I don't anticipate that record will stay for long, anyway.

I'll be honest, I read that tidbit on the forums, but haven't had time to try it myself. 263, if Celsius, is awfully high for ambient...And if Kelvin is below freezing! It doesn't really make sense in Farenheit or Rankine either...Huh. Needs further investigation. I'm not exactly the best aero engineer around (not even on these forums...), but man do I love this stuff. I'm happy to be around and provide some insight. (Especially now that, you know, the stock atmosphere is at least a reasonable approximation of reality!)

That does seem backwards. Keep in mind that less dense air means less thrust and less lift as well, which somewhat offsets the gains. (IRL, lower density performance is actually worse, but that may not be the case in KSP).

1. As far as I'm aware, yes, this happens in KSP. That's a good idea to mitigate it, too... 2. Nope, intakes behind solid structures still get air, at least as far as I'm aware. 3. The thermometer part actually does this now! Slap one on critical areas like the nose. Else, there's the debug menu, but that might violate the rules. 4. Not sure. Mach effects are a thing now, but I don't know how accurately they're modeled. I kind of doubt anything like this. 5. Each part has a few stats related to heat now, such as "thermal mass". Not entirely sure what they all do yet, but suffice to say that some parts heat up faster than others. And now a question of my own: anyone having issues with asymmetrical thrust/flameouts? I've done the old place engine 1 -> place intake 1 -> place engine 2 -> place intake 2 method and I'm still having issues.

It was...sort of intentional. I already had (most of) this plane built, and honestly didn't feel like re-balancing it without the oxidizer. I also used only half my fuel on this run. I'll probably make another run at it without the oxidizer and with less fuel in the front tank to see if I can keep the CoM/CoP in the right places. This particular design is extremely maneuverable and the slightest mass balance tweaks throw it pretty close to instability :/ And yeah, I was showing proof. Better safe than sorry. (Also, it was a sanity check for me, since I'm using Rapiers.) I should see how close this can get to orbit... I'll make a lighter weight run sometime after my exam on Friday (which is, coincidentally, about controlling unstable aerospace systems ).

Well, here goes my first ever challenge entry! My SP-1C HyperStreak (as opposed to the -1A SkyStreak and -1B SuperStreak...) reached a max altitude of 28,901 meters ASL. It was flown by Jeb and Val, and returned safely to the KSC runway, as well. It's a bit of a beefier craft than most of the ones here, but it works for me The only issue might be the minor clipping: the two intakes are attached to clipped tail connectors. Not sure whether that's allowed or not. (There are only two shock cone intakes, no funky intake spam going on.) And here's the album:

Can I get technical here? I'm going to get technical here. For those who don't want technical, a summary: SO. MUCH. THIS. Here's the thing: SAS is a rocket controller. Not a plane controller. I don't mean "it isn't tweaked to fly rockets." I mean the algorithm itself is designed for a rocket. In controls engineering, there is no "one solution." (No, not even PID). And planes, dynamically, are wildly different beasts than rockets. Theoretically, the "best" solution is a custom controller for every craft. However, since I don't see stock (or even mods...) giving us transfer functions and Bode diagrams anytime soon, this is never going to be feasible in KSP. At the very least, though, there should be some consideration for how fundamentally different planes and rockets behave. Breaking it down a bit, here's what rocket SAS has issues with on planes, in my (fairly limited, to be honest) experience: -- The damping ratio on roll is ridiculously low. Over-rolling is incredibly frequent in many small aircraft. On the flip side, and this is where the "one size does NOT fit all" thing comes in, larger aircraft with longer wings can barely roll at all, even with a fair amount of control surfaces! -- There is zero tolerance for pitch instability. I've kept an aircraft with center of pressure ahead of center of mass under control in KSP 1.0, but there's no way to harness the instability (as in real-life aircraft like the Su-27 and F-22). -- Yaw...I don't even know. Most designs I see don't have enough tail, but even so, constant veering in one direction should be damped out. -- Control inputs totally disable the controller! This is the behavior I'd most like to see changed. Control inputs should be inputs to the controller, not overrides for it. SAS seems to be the same algorithm for all control axes (roll, pitch, yaw). That works pretty well for rockets, but it doesn't for planes. Ultimately, a slightly different controller for each axis would make a world of difference, IMO. On the flip side: I have no idea how this would be implemented for planes and planes only. By cockpit? No good, they're used for plenty of other things. A separate hotkey? Probably confusing. A different class of Kerbal *could* work, but I'd personally prefer Jeb and Val to be able to fly both planes and spacecraft. It's certainly a tricky issue to circumvent. ...Maybe one of these days I'll stop being so grumpy about sticking to C++ and Python, learn C# and Unity, and make a controller mod myself....

Ah, gotcha. KSP's sales data isn't public, but inferring from Killing Floor 2 (right above) and CS:GO (right below), it's...substantially more than 3000 for KSP specifically. Unless I'm reading the data wrong, which is a definite possibility (getting numbers from steamspy.com)

I know, but I'm still impressed. I don't know if the ranking factors in pre-1.0 sales or not, but regardless, it's still selling like crazy. Nice to see it had a successful launch over at GOG as well!

Note that this is only the list of cross-platform games. If you go to Windows only, KSP is still #5. It's still amazingly impressive, especially looking at the titles above it (Star Wars collection? GTA?) Way to go Squad and KSP.

June 2013, right after .20.2 came out. I didn't even know the game was early access until I actually dug into it a bit more. I didn't know a thing about mods or the community. My first launch failed because I went for a realistic gravity turn in the souposphere. I just *had* to get it though. A coworker showed it to me and I couldn't even wait for the Steam summer sale to hit.

I launched Val and Jeb in Mk 1 pods several times to test out both my old (NEAR) ascent profile and the atmospheric heating. Result: the heating is a fun challenge...and my old launch profile is a tiny bit too shallow. I also had a ton of fun with a supermaneuverable aircraft.

Fairly simple reason, actually: in reality, crossfeed is pretty difficult, and costs quite a bit of money to develop. Since no customers for the Delta IV have required the extra performance crossfeed provides, it hasn't been developed. There's no reason to. And, for the record, Falcon Heavy is the same way: last I heard, it was not going to use crossfeed unless some customer needs it, which gives a (monetary) incentive to develop it.

And lighter weight, and cheaper! The biggest drawback of plastic printers is that they can really only do one color at a time, two if you have a really nice one.

And a bit of searching reddit later, confirmed they are the same material as Shapeways models. I would NOT recommend flying them. Also, the price will be up there.

Assuming PLA or ABS, 3D printed stuff is pretty tough. I've flown a 10% infilled ABS structure with a fairly good sized hollow space in the middle (storing avionics) to 80k feet on a weather balloon, had it fall back at 15 m/s or so, and survive unscathed. The next flight, it came down on a rock and had only a small puncture. I'm currently designing a both a fixed wing model aircraft and a bi-copter to be 3d printed, and I expect them to both perform fine structurally. EDIT: As for price, I bought 2 kg of filament for $40. Even with a decent profit margin, if it's standard plastic prints, they shouldn't be terrible. Certainly not Shapeways level. EDIT2: Nope.

Apologies for creating/feeding that bit of fairly reckless speculation.

Hey guys?

Started in .20, landed on the Mun in .20. Had an extensive space program through .21, which I consider my most successful version by far. Since then, I haven't had as much time to play *and* I've been restarting with every version, so progress has been slower. My current career is finally shaping up to actually get somewhere, and I'm hoping to surpass my .21 save.