Sean Mirrsen

Yeah, that was the new SAS doing its thing. The Aeris has a peculiar aerodynamic profile, in that it can be flipped, with a very precise combination of inputs. With SAS on, the combination of inputs is just "tap S once". Plus the SAS locks the new course, backwards, so for a while you can be flying in reverse.

My kerbals are busy goofing off.

Offering a counterpoint to clean lines and neo-gothic cathedrals, here's my new SSTO design. I can't help but think that it looks like somebody rammed two rocketplanes together, but instead of exploding they combined into Gurren Lagann. It's got three different wing profiles that interlock without intersecting (i.e. clipping), which is why it was named the Padmasana. The command pod is detachable, works like a shuttlepod, and is technically capable of return from Jool orbit, on ion power. Plus is looks like the head of something from the Gundam franchise. (I've no idea why Jeb is so happy to fly in it. Probably unrelated.)

I know of the kind of system you mean, and I like it when it's done right, and applied right. I mostly see it in racing games for some reason. Also, whenever it exists, it exists as a setting in the options - you are given the option to tweak it to your liking. Fine Controls in KSP are already that system, they simply may be a little too quick for your liking - in which case the option to make the input as smooth as you need it would be the thing to add. The issue is twofold here. The flight physics are as much to blame for this as the keyboard controls, and, honestly, I've flown IL-2 Sturmovik with a keyboard - the only difference is the amount of roll momentum. The most agile of fighters in IL-2 will respond sharply to keyboard input, sharp enough to make aiming at anything but point-blank range a chore, but they won't start movement so suddenly, because they have an actual flight model behind them - and like I said earlier, they don't use all of their control surfaces to steer at once. KSP suffers from a lack of a flight model (what we have now isn't a flight model as much as it's a falling model - the barest basics of air resistance and lift) first and foremost. When it actually gets an overhaul of that, I think we'll see planes handling much more realistically. Also, I'm not sure if it was fixed, but if you're on one of those non-Windows platforms, I think there was a bug that made fine controls mode not work. Also also, since 0.21.1, there is a forced deadzone on the control input, so that SAS doesn't lose its lock on the intended direction so easily. Also also also, this video I made with the Aeris 3A. It was back before the .21.1 hotfix, to showcase SAS issues. I switch to fine controls about a minute in, so you can see the change in handling. If you're not seeing that change, then something is indeed wrong.

See, the problem with the Ravenspear is that it's a small, lightweight airframe. And it has only four control surfaces, two of which are powerful wing-length ailerons that it uses for pitch. So when you tell it to roll, it uses all of those surfaces to roll, plus the reaction wheel in the pod. If we could dedicate ailerons to roll and pitch separately, like we can with FAR, this kind of "problem" wouldn't exist. And there's a mighty big problem with acceleration/deceleration as you propose. The problem being that the new ASAS will only lock onto a heading once the control input has returned to zero. Under that system, you'll have even more lag in SAS response than you do now. I've just tried flying the Ravenspear, and it really handles like a dream with fine controls. If you need more smoothness and precision than that, I'd suggest you get a flight stick.

Fine controls already does that. If your craft reacts too fast even with fine controls, then you have way too much control authority - cut down on it. The only way to go slower than fine controls is by using trim, which is Alt+direction. Even finer controls could be possible, of course, but they'd have to be a setting in the options menu (i.e. "fine controls smoothing factor") rather than a separate mode. There are only so many buttons and so many modes possible to keep track of.

Making equipment decay and fail at a certain rate based on distance from a body with atmosphere is certainly possible. It's the orbital decay - the shifting of the orbit - that isn't. So you can definitely have that element of "this satellite's been up there for 60 years, time for a new one", in game-friendly terms, but actual shifting orbits are unlikely.

Not possible with the on-rails system. It is, after all, on rails. Every orbit outside of an atmosphere and that doesn't intersect another SOI, is perfectly stable in KSP.

I once had to somersault an 80-ton SSTO spaceplane through/over a forest of solar panels when I realized RCS wouln't stop me in time and I would waste too much time turning engines back on. Barely cleared everything, and approached to dock from the other side of the station. Despite that experience, I usually keep the panels open, unless they are in the way of the docking craft. So far, only one panel broken during docking operations, by an EVAing transfer pilot. I'm fairly gentle with the approaches.

All or most SSTO parts have been said to be scheduled for a complete overhaul at some future point, so nobody is likely to work on the existing ones much. And the custom-length fuselages and varied fuel mixes are best fixed with customizeable parts, such as the tweakables system that's coming up sometime in the next few updates (I think), and dynamic parts like the dynamic wings and dynamic fairings in the Mods section. The issue here is the combinatorial explosion - say you have three fuselages. Mk1, Mk2, Mk3. You also have transitions between them. And they all hold only fuel. That's five parts. Now you add custom-length parts, tripling the count of the standards - eleven parts total. Now add the standard fuel mix variant - twenty-two parts. A standard component page being four wide (I think), that's anywhere from a whole page to two-thirds of one, devoted just to fuselage parts. And then there's parts that hold no fuel. If you get tweakable dynamic parts instead, you just keep the adapters, and have the three fuselages, like before, that you can adjust to any length, and fill with whichever fuel mix you want. Five parts.

It's not standalone. Just try loading a 0.20 save into 0.21 and it'll give you the option to attempt conversion. You may want to back it up beforehand, even if the game does do it as well.

More than you would be annoyed at the part popping off entirely or exploding instead of being damaged? It's not like the current parts can take a whole lot of punishment - a lightweight unmanned rover turning over can already break solar panels - both folding and normal ones, housing or no. Rovers can already break their wheels just driving around. I think that getting rid of the "spontaneous mass existence failure" principle would be a great move, not least because it would give you warning without completely breaking whatever you're flying. If the stress of the engine block pushing up against a heavy rocket is too great for a fuel tank to handle, right now it'll just take the punishment, and then suddenly explode. If it could get damaged, you could get advance warning - if the tank starts to crumple, you have barely seconds left to throttle down before something breaks completely. This could be very useful in career mode, where you likely won't have the option of just rolling back bad launches.

An annoyance in what way? I'll take a crumpled tank with half capacity, a bent wing, a faulty decoupler that may not fire, or a smashed engine that doesn't give coaxial thrust and has less power, over any of those things fully intact, but torn off the craft or gone in a puff of smoke.

Sure. What did you have in mind?I made an escape pod that can technically come back to Kerbin from about anywhere. Technically. If you have lots and lots of patience.

(emphasis mine)I'm sorry, I mean no offense by this. But I've been reading lots of NotAlwaysRight.com lately, and that honestly sounds like some of the finest gems present there, such as "you should have known I meant large when I said small!". SAS is just a computer system. It can't know when you want it to stop, except if you tell it where to stop. In your case, the best way to do that would be to briefly press "F" at the exact moment the craft is pointing in the direction you want, i.e. exactly as the old system was used. The new system does its level best to help you fly, but it can't read your mind.

That's actually a good idea. +1

It's the most compact solution to adding SAS to podless shuttlebikes using the command seat. It's also a fancy nosecone and the best "warhead" for unguided rockets. As for something special, since it's an avionics package, it could add a "follow horizon" function, so that whatever course the aircraft holds is adjusted for the planet's reference frame, preventing gradual pitch-up on long flights.

Heh, that's just the realities of scale. Your ship is tiny compared to the planet. So when you zoom out, your ship will become a speck on the screen long before you see any movement of the planet. Welcome to space! First thing to know about it: space is big. Really big. You just won't believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it's a long way down the road to the chemist's, but that's just peanuts to space. And so on.

I find it's much better. It still doesn't hold a heading perfectly, but the array of bugs it had with completely losing a heading is gone. The most flipping-out-iest SSTO I've built to date has safely made it to orbit with it. It's definitely an improvement over 0.21, and the only way it's inferior to the 0.20.2 ASAS is the failure to precisely hold a heading on imbalanced vehicles.

I've had these for a long time. I've been experimenting with other ways to use them. They're a very neat system. Command pod, escape pod, and minishuttle all in one. I'm waiting for some retractable powered wheels so that I can make the rover-pod without the wheels sticking out in flight.

He's just using imgur page links instead of image links.

After the 21.1 hotfix patch, first thing I did was bring my latest trainwreck of SSTO design up into a near-perfect orbit, zero hassle and smooth as can be. (previous record height was "crater in nearest mountain") With further refinements improving long burn accuracy, I'd say the new SAS is a winner. Yes, it does 'give' a little under stress, and yes it's a problem for long interplanetary transfers, but A) not nearly as game-breaking as what it did to stations and big ships previously, and entirely expectable to get fixed within the next update or two, as I'm sure most people understand the importance of that kind of accuracy. Not to mention C) possible to account and compensate for, ultimately.

Just pointing out the stuff I see. I can see a reaction wheel being usable on a rover to keep it stable. I can see it being usable with SAS. However. Consider that said reaction wheel is strong enough to keep your rover pointing in one direction, and returning it to that direction. If you really need SAS to pull a turn, and your control pod is wrongly oriented... why not use the roll controls? The reaction wheel will turn you just fine. I can see RCS being usable on a rover, especially when in a low-G environment where some really long jumps may be in order, and overturning is just one of many problems. But given that RWs are an option, and RCS fuel is limited (and heavy), why would you use RCS at the same time as driving a rover normally? It's just rather baffling to me.

The force exertable by a gyroscope is proportional to its mass and rotational speed. So it's possible to have a series of smaller wheels that do the same thing as one large one. The flat reaction wheel modules likely contain a series of small wheels as well, instead of just one big wheel - probably a bigger RW in the center for roll, and matched pairs of smaller RWs for pitch and yaw. It's not the most plausible explanation, but it's quite possible.

Indeed. Plus, if anything, it would be at the poles of something. Keeping the axis stable.