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!