Sean Mirrsen

Having RCS on while driving a rover just creates more questions than it answers. What do you use it for? Downforce? Steering? If you're using it for downforce, why do you have RCS thrusters capable of sideways translation? If you're steering with RCS, why aren't you using flight controls in the first place? If gravity is so low that you need RCS for either, why have a rover at all? Correction - why have a rover drive at all? Plus RCS tanks are kinda huge. If you have space for RCS tanks, you probably have space to put the rover core facing forward. So, yeah.

Well, the old Avionics were specifically pilot assist, so yeah, they'd allow something like this. The new SAS is more strict in that regard. But, yes. If the issue is just in that rover controls don't release the control axis the same way pilot controls do, then it's something of an easy fix for Squad. Actually, I would even prefer if there was some kind of "rover SAS". It'd use the same logic that the wheels do to know which way to turn, to know which axis is the turn axis, and would adjust its axis lock behavior accordingly. Not if you're a practical person and have the rover controls rebound to IJKL or the numpad, because using WSAD to control a rover with any reaction wheels at all is a terrible idea.

There's a way to override it. It's really just called "momentarily turning it off". Why do you use SAS on a rover? Unless it's only to hold a course, you don't need the control of pitch and roll. Just turn it off while you're maneuvering and you should be fine. I mean, going full hypothetical here. Let's say you got that option to override the roll axis so you could turn your rover when it's pointing straight up. How do you envision it being used? Used at design time, as a part setting, it will prevent SAS from being used to hold a course. Used during a mission it will require either a manual switch in the right-click menu, or an additional button that isn't the F key but does essentially the same thing, for a rover that doesn't have Alteisen Riese in its ancestry and can actually stand on the ground without user input or rocket engine assistance - and if you built one like that, you probably had the option of pointing its control core forward. All in all, it's not an entirely useful feature, is what I'm saying. The situations where you need a SAS that cannot hold a given axis are... rather few. A more useful feature would be being able to set the "forward" direction of a control core, at least at design time. This way the problem would be circumvented entirely. What he's saying is that the current SAS releases its lock on a given axis depending on user input - but it's a FLIGHT computer. It can't be used properly when the flight controls and the rover controls are the same, but result in different rotations. In this case, the axis used to turn is the roll axis, when it should be yaw. So when turning, SAS releases the yaw axis, but still clamps down the roll axis, the one actually used to turn here - and it sees to it that the rover returns to where it was pointed before turning.

To people who say it doesn't lock down fast enough: Please Use The Old Method. Pulse SAS off and back on with the F key. Because due to the nature of the control system, there is bound to be a split-second delay between the virtual joystick (shown in the lower right as pitch/yaw/roll indicators) being released, and actually hitting zero on a given axis, which triggers the lock-in. A similar problem exists with planes and fine controls - if you set SAS to hold a high pitch and try to correct it, the SAS will let go of your control axis long before the virtual stick reaches the point it was holding, causing the plane to dip down before coming up again. It's actually causing me to use coarse controls for my planes now. >_>

There is no way for the new ASAS to work with rovers of that design. It's not an ASAS flaw, it's more of a... well, design quirk. Notice where your navball is pointing. When you turn, even if you're using the default controls so that turning with A and D turns the rover as well, you're using the yaw axis - when for your probe core, turning like that is the roll axis. Either use F to pulse SAS off while you change direction, or build rovers that are actually facing where they're going.

Already did. If you can toss it up on Youtube so people can see it easier, it'd be quite helpful.The flipping thing with the Aeris is really just in the aerodynamics of it. When you pitch up like that and release, SAS immediately throws the pitch into the other direction - but at that attack angle, all it does is flip the thing over. You can replicate the effect manually, but it takes some doing - and SAS treats it like a perfect "reverse course" maneuver, sticking to the retrograde direction. It also loses track of where you were trying to point it if it flips back on its own.

ASAS in KSP has always done what real-life engineers with more freedom than we have in the game do manually - set engine gimbal angles, control surface trim, etc, automatically. ASAS technically doesn't exist in real life - there are flight computers and autopilots, and ASAS in KSP is somewhere inbetween. And while the current SAS system is a massive improvement over the old ASAS in many important aspects, for many people it fails in its most basic function. Which is, do its level best to keep whatever you have built in whatever direction you've last pointed it. While some people seem to remain unaffected, the problem is absolutely unbearable to those that are, as it becomes simply useless, for all its advanced features. Yes, it is more efficient, yes it can remain always on, yes it is built-in. But without it actually doing its job, those improvements are no more useful than aerodynamic bodywork, ABS, GPS, and climate-control in a car with no engine. That is what the affected people see. Nobody is harping on the new SAS out of sheer spite because of its being changed, after all.

Okay, so I reinstalled and made another test with the Aeris 3A. I've no idea how to Youtube, so here's the video on Dropbox. https://www.dropbox.com/s/crr6am98zh5a91p/KSP%202013-07-25%2021-04-58-647.avi It appears I've been wrong, it is possible to make the Aeris flip out with some intensive abuse, but it's a lot easier with SAS on. I should probably remind Squad that ASAS doesn't stand for Aerial Stunt Augmentation System.

That's not a new problem, and definitely not an ASAS problem. It's a design problem, stemming from the limited amount of control surfaces on the craft. When you pitch the Aeris up at high altitudes, you can notice how it does not have enough lift to easily maintain that angle, and both its canards and elevons are occupied holding it up like that. So when you roll, you occupy them doing the roll - and since there's nothing else left to control it, the craft pitches down. FAR offers good solutions to this, by splitting up ailerons and elevons so that you can have pitch-control surfaces that won't fail you when you're doing roll.

I've tried the Aeris test proposed by Harvester, and I'm seeing a curious occurrence. See if anybody else can replicate it. Take the Aeris 3A stock craft out. Thrust to full, take off from the strip, gear up. Get about 3000 meters up and fly straight and level. SAS off, standard coarse controls. This is the start of the test. Now, try to flip the craft over. Just use the S key or pull hard on your joystick to try and throw the Aeris cockpit-over-tail. If your game is working right, you will fail - the Aeris is stable enough to just pull up hard and stabilize, and no amount of abusing the pitch controls will get it to flip over. Level out again, and enable SAS. Now try to flip over again, but in two different ways. First, just pull up hard (or jam S) and don't let go. This should produce the same effect as previously - i.e. the Aeris will pull up, near vertically, and rapidly gain altitude without flipping out. Now try again, but instead of just pulling up continuously, pull up hard and let go when the craft is about 45 degrees off course. The exact value of deviation isn't entirely precise, but you have to let go when the craft is in "full upswing", severely off course and with some rotational momentum. In my experience, what happens is a total course reversal. Against its own aerodynamic capability (as established by previous tests), the Aeris will flip over and point exactly at the retrograde marker, keeping itself wedged there before slowly, ever so slowly returning to the point where you let go of it. This doesn't come up often in normal flight, since you either make minute corrections or go full pitch, but I think it hints at a problem in the ASAS logic. I'll do a full reinstall of the game when I get home and see if it changes anything.

[Operating System]: Windows 7 HP x64 [Memory]: 4GB [ASAS Trouble (Y/N)]: Yes...ish [Mods installed, pre-patch]: Subassembly Loader [Mods installed, post-patch]: Subassembly Loader [Description of problem (keep it short)]: There are fairly severe problems with course control on the spaceplanes I tried. However, those spaceplanes were ones I constructed myself, prior to patching. Prior to 0.20, even, at least the basic aerodynamic shape. Once in space, the course is held rather well, shuttlepods handle perfectly with unbalanced RCS, and a more modern spaceplane design handles much better in atmosphere too. I am suspecting the core of the problems I have is in the designs themselves. The ASAS performance also seems to vary between launches of the same design, however.

I just rebound the rover controls to the numpad. That way I can control the rover, and still use the magic torque (soon to be perfectly scientific torque) if the rover has a command pod to flip it over.

Since there aren't any mods I care about that might be incompatible (I mean, KSPX is slowly getting integrated anyway, and the Subassembly system is in active enough hands that I think I'll have enough on my plate until I need it), I will be most occupied testing the limits of the new ASAS, primarily with SSTO spaceplanes, and stations constructed out of them.

For a game like KSP, I see literally no downsides to using Steam. No achievements to pester you, no need to even have Steam running, hassle-free updates as soon as they come out, and all accessible along with all your other games if you ever do open the client.

If a typical 1.25m-diameter Kerbal rocket landed in my backyard? I'd start running around screaming. Because I would be on fire.

Indeed, the "lever arm compensation" thing is absolutely silly. What it combats is the tendency of spacecraft to drift or turn in unpredictable ways if the RCS thrusters aren't perfectly positioned. Or rather, that's what it supposedly combats, because... well let's see. I guess the HarrowJet is bound to be my go-to craft for any given theoretical explanation around here. It's a non-contrived, not-oversimplified, not-unrealistic example. RCS thrusters litter the surface of this craft. There are thrusters on the nose, the wings, the sides of the engine pods, etc. Now, some thought actually went into constructing this one - it pitches and rolls pretty well. But it has a problem with yaw, seeing how most of its mass is in the rear, and the only thing way past the CoM to compensate the lever force of the nosecone RCS is the tail. Which is, for aerodynamic lift purposes, lifted high up. So whenever it tries to yaw, the extra bit of thrust from the tail elevation starts rolling it. How does the lever arm compensation fight this? There is literally no way to somehow make the craft not roll by using less thrust - the only RCS units capable of effecting yaw on the HarrowJet are the ones on the nosecone (which is also a shuttlepod, so no it can't have those repositioned), and the ones on the tail - and the centerpoint between them is nowhere near the center of mass. If whichever system tried to calculate the necessary forces to prevent the craft from rolling while turning, it would inevitably come to the conclusion that neither thruster set could exert any force. If it had a fail-safe for that occasion, or just used a "less force from CoM" approach, it would just fail to do its thing. But curiously, the solution already exists. In fact, we've had it for a long time, it was just a wee bit broken and we're getting it upgraded in the next update. A flight computer, which in this case is folded into the A/SAS, will attempt to maintain the orientation of the craft. It won't do this through fancy calculations (well, not of the positions and thrust of RCS blocks at least), but through the sheer determination to maintain orientation. It won't use less thrust, not on the thrusters performing yaw. But it will compensate with thrusters performing roll - it'll just gently roll the craft as you adjust yaw, preventing it from tilting sideways. That is the only solution we need here. It's nice and simple to use, and won't inhibit the craft's mobility.

The earliest KSP folder I have is marked 0.9, so I guess that's when I downloaded it first. Couldn't buy it till it appeared on Steam.

My "Space Harrier" SSTO series, since renamed as "HarrowJet", has long, long been a staple of my SSTO fleet. First prototype, suborbital flight: The series went through numerous variations, of engine types: ..wing layouts (Not all of them were good): ..and eventually it was refitted for interplanetary travel: ...it didn't end well. So now it's been reworked into more of a close-range vehicle, showcasing advances in design... ..and gimmicks. Lots of gimmicks. It received VSTOL capability around that time (and lost the Space Harrier name around then too, ironically). Which allowed it to land on the Mun. Or try, at first. But it succeeded! Now it's being reworked again. Waiting for the advances in ASAS technology, it received an upgrade in VSTOL capability and aerodynamics. Work continues. I really only keep it around so long because I can't get over how good it flies for how good it looks - and that's without any kind of clipping abuse.

If the craft needs a booster to get into orbit, no matter how many stages the booster or the craft have, then it's not an SSTO. Unless you mean a pusher stage, that is a 'booster' for orbital maneuvers or interplanetary transfer, that launches separately.

Not a "genius" design, but a "genius" action - I thought that my plane was flying slow and stable enough to let Jeb take a walk on it. Turned out, not quite. And while we're on the topic of planes and SSTOs... Protip: the Mun has no air.

Shoot for the Mun. Even if you miss, you end up among the stärs. Or at worst, a decaying orbit around Jool.

0.20 isn't a version that's 20% complete. It's just the 20th major update, which is why you don't see anyone refer to it as "version 0.2". With that in mind, the version that precedes 1.0 could be anything, 0.30 or 0.126 - development will take as long, and as many intermediate releases as needed.

On the absolutely literal side of the question, the debug menu is a developer tool for testing the game without constraints. Since embedded developer testing tools have always been called "cheats" when used by the players themselves (see: the various console commands, /give commands, god mode, etc, across the entire genre spectrum), then by sheer definition, using the debug menu to enable part clipping is, in fact, cheating. Or, if you can sense the difference, it's using cheats. The regular part-clipping mechanic, though, is an exploit. It's half bug, half unfinished feature, that lets you sort of do something like what the debug-menu version allows. The difference is in the how of the thing. There are two primary "branches" to part clipping usage, in my eyes. The first is the intended use - the reason the bug/feature persists is that it allows people to place items that should be placeable, but due to whichever shortcoming of collision-detection, aren't. People use it to cluster engines (less useful now that multicouplers are there), put fuel tanks and engines in the middle of wings, attach stubborn parts, and so on. I am perfectly fine with clipping being used this way, as, really, that's what it's there for. But then there's the other branch, which I can't call anything but "abuse" - intake spam, wing spam, putting engines inside structural pieces, overlapping fuel tanks with something (the tank's already occupied with fuel - if you clip something into it, you should have less fuel, but it doesn't work that way yet), generally abusing the clipping mechanic, with the debug menu or without, in order to create a craft that functions better than it looks like it should. I admire KSP for the way how both visual and functional design combine in it. It's a challenge to make something that both looks, and works good, especially with limitations imposed by stock parts, and I feel that using - abusing - the clipping mechanic to cut corners and take shortcuts through this process, is cheating, in the worst sense of the word. But anyway. As many people have said, this is still a singleplayer game, and you are free to play it as you wish. Just be mindful of that, and don't boast in front of other players how you can create the sleekest and awesomest craft ever, conveniently forgetting to mention how you got it to work that way.

The first still happens in extreme cases in KSP, and the latter does not apply as all of KSP's stellar bodies are on rails. Neither does KSP when the numeric integration would be at work. At any significant time warp, everything is reduced to a parametrized point. On the contrary, it is perfect for casual play (nothing is more exciting than having real physics in accessible form), and would not require anything more complex than has already been done by other games, while adding a great amount of possibilities to both the world and the gameplay.

I'm using an Acer Aspire 5745G. A pretty old model. I could buy a much more powerful one now, from the same Acer series, for less than I bought this one back then. It's got a Core i5 @2.5(max)GHz, 4GB RAM, and a GF GT330M w/1GB VRAM. I've been playing pretty much everything on it, and besides the need for a harddrive change and some nascent problems with the keyboard (the 'W' key is seriously worn out... darn FPS games...), it's been my perfect work and gaming machine for the last few years. So even if "gaming laptops" don't exist, laptops are still perfectly suitable for gaming. Battery life be damned.