Tiron

Unless they've changed the behavior, it autosaves every time a craft is first loaded onto the pad/runway. The 'revert to launch' is basically just loading the autosave. You can do it manually by holding F9, just don't load a new craft onto the pad/runway to do it.

The latter problem is the one we're talking about, more or less. For spaceplanes it's MUCH better, because it allows control overrides without fighting them. Effectively the way it's working now is very similar to the way the old avionics nosecone worked, only better. So yes, it's great for planes. For rockets...not so much, because it won't hold an attitude. Especially when trying to execute precise maneuvers in space it's very difficult to use.

Given the massive overhauls to the crew system, I'd want to look at a persistence file and test a bit before I suggested doing that. I've seen one report from a guy that may have slightly broken his game editing his persistence file to bring a kerbal back to life. Another thing you can try if you haven't launched any more flights, is that it autosaves automatically each time a new flight is started. It saves it as Autosave.sfs, right next to Persistent.sfs. It's actually an entire, second persistence file, just with a different name and keyed to F9 to load it (just DON'T load a new flight onto the pad to load it, it'll overwrite the old autosave with the new one for that flight). You can in fact rename/move Persistence.sfs, and rename Autosave.sfs to persistent.sfs. If you do that with the game closed (or at least sitting on the main menu, if you're in flight or in the space center it'll get overwritten with the in-progress save when you exit the game/go to the main menu), next time you load your save it'll automatically load up with the autosave.

Even slightly broken, it's still a LOT easier with the new SAS than it used to be. I haven't flown more than a craft or two to orbit manually since I stopped playing the 13.3 demo and bought 0.16, and I managed it pretty okay with the Kerbal-X all stock. Minus my bad, rusty piloting caused mostly by my attention wandering (I have ADHD, it does that).

Well, it's a thread that's not criticizing the PROBLEM, it's criticizing squad for not staying awake all night to address our concerns about the problem, more or less. A certain degree of derision is not entirely unwarranted.

Well it DOES work to a degree, just not quite...right. It's a bit fiddly and difficult, but you can get where you want to go if you're patient enough. Or just use Mechjeb's Killrot, which is basically the same as the old SAS, except it has control override and automatically sets the new target attitude to be the point where you stopped using the controls. The new SAS is much more efficient and dramatically less wobbly, but at the moment seems to be having trouble holding an attitude.

Not at six in the morning we don't. It's not like it's Activison-Blizzard where they make hundreds of millions of dollars and can afford to hire people to stay up all night nannying the forums. Yes, it's broken. I'm pretty sure I found the problem and if I'm right it should hopefully be a relatively easy fix.

Given that I just posted a dev video showing it working the way *I* describe, I would really like it if you could post a link to where an actual dev says the behavior you state is the intention. Because so far as I can tell, the problem I noted is the root cause of every problem everyone else is talking about as well. And even on mine, actually WATCH THE VID. It doesn't just stop the motion. It does, in fact, very briefly REVERSE THE CONTROLS right after coming to a stop, and briefly rotate back the other way. Only for a second or two at most(more like a fraction of a second), but it DOES reverse. If it were simply trying to damp motion it wouldn't need to do that.

Actually it's all the same issue. There's only one, I'm pretty sure. And I'm pretty sure it's NOT intentional. Some of the old SAS worked the way you describe, the pods because they were supposed to be only a partial version they got free as a demo for the full one, and the avionics because attitude hold would make a plane unflyable. the regular SAS also got modified to act this way sometime in 0.20, presumably to make it work as a rover stabilizer. the ASAS never did. But more than that? Check this out: Pre-release demo vid from Chad himself. You'll note there that he starts a rotation on the station, then lets the SAS have it, the same test I was doing, only with a station. It starts off by damping the rotation out, then REVERSES it, and then stops it not where it originally started at, but at the point where he stopped telling it to roll, exactly as I describe. You're mistaking what was in the old version a kludge to make certain things work with the completely unforgiving old system for a design intention. Edit: And the only link I can find that you posted is to a thread where a bunch of people are posting partial system info, mostly people who swear it works fine, which isn't really helpful.

Except there's no PRECISION to it at all. The fact that it lets it keep sliding on after you've let go is a PROBLEM. it is a FAULT. it prevents you from being able to point exactly where you want to point, because you have to somehow manually get on that point and then stop there, which is extremely difficult at best. Sure, it holds once you've gotten stopped, but it doesn't MATTER because it's absurdly difficult to get it to the attitude you WANT it to hold. The problem with the old SAS wasn't that it brought you back its target attitude: It was that it wouldn't ever change what its target attitude was unless you turned it off, then back on. If you tried to use your controls, instead of adjusting the target attitude to where you moved the craft to, it would keep the old target and actually fight you to try to get back to it. The new version allows controls to override it, so that isn't a problem anymore. What it SHOULD be doing, is setting the target attitude to the point where you release the controls. Not moving back to where you started, to where you let go. Mechjeb's killrot function has worked exactly this way as long as I've been using it, and it's why I haven't used stock SAS since I started using Mechjeb. When I first bought the game. in 0.16. If you want to see the behavior I'm talking about as what it SHOULD have, try the 'KillRot' function on Mechjeb's SmartASS. It's basically identical to the old ASAS, only it allows for control input overrides and takes the point where you release as the new target attitude automatically, without having to turn it off. But it's just as inefficient and wobbly as the old SAS too. I'd really like to use the new SAS at least some of the time, but as it stands it's unusable and vastly inferior to Mechjeb's very flawed KillRot implimentation.

I'd just like to point out that if his plane had insufficient control force to hold its heading, it wouldn't shift off target a few degrees and then hold. The fact that it's able to hold a few degrees off indicates that the control forces ARE powerful enough to stop it. If they weren't, it'd keep rotating all the way around, pulling a loop. An accelerating loop, actually, because the 'extra' force the controls couldn't compensate for would lead to a constant acceleration. It's strong enough, it's just either applying its force too slowly or aiming for the wrong point.

Finally finished uploading. 1080P for your viewing pleasure/downloading displeasure. Procedure: 1.) Start at -90 degrees pitch. 2.) Apply full right yaw until the -45 degree marker, then release and allow the SAS to take over. 3.) Bring right to +90 degrees pitch 4.) Apply full left yaw until the +45 degree marker, allow SAS to bring to a stop. 5.) Bring left to -90 degrees pitch. 6.) Apply full left yaw until the 0 degree pitch marker, allow SAS to bring it to a stop. 7.) Bring right to +90 degree pitch 8.) Apply full left yaw until the -90 degree marker (yes, 180 degrees), allow SAS to bring it to a stop. 9.) Bring right to +90 degree pitch. 10.) Apply full right Yaw until about the +60 degree marker, allow SAS to bring to a stop. 11.) Push the wrong button while trying to end recording. What you see here, is that when the SAS is given control, it makes no attempt at all to return the orientation to the point where control was released. Instead, it simply brings the ship, rather slowly, to a halt. The ramping of the control force suggests it's actually getting closer to its aim point as it slows. The distance past the release point it gets is proportional to the rotational speed when the SAS is given control: The higher the speed, the further off the mark it goes before stopping. One key thing to note is that each time after it stops, it briefly reverses the controls a tiny amount before settling in. This suggests that it's not merely movement damping, and that there IS in fact a target attitude it's trying to reach. It's just not being set to the release point for some reason. The fact that it's proportional to the movement speed and the way it ramps down as it slows leads me to believe that it's probably resetting the target attitude constantly as it slows, probably being triggered by the SAS's control inputs. What this means in practical purposes is that whenever you release your controls to the SAS, whatever movement you're engaged in will continue for some distance, and when it's halted the SAS will hold it on a point that's more or less where it stopped at. This means that while making fine adjustments, unless you get the craft all but stopped before you let go, you're going to overshoot by some distance and have to re-correct. This is on Windows 7 Ultimate 64 bit, KSP version 0.21.0.272 from Steam, on a fresh reinstall with no addons installed. The craft is the final stage of a Kerbal-X with the large (non-torqueing) ASAS added. System Stats: AMD FX-6300, 8GB DDR3 RAM, installed in ASUS M5A97 running Bios version 1605, with Sapphire Radeon HD 6870, driver version 13.1 (A tad outdated, but the newest ones don't work with an old game I just reinstalled anyway. Or at least, they don't for install purposes. It might work now that it's in. I'm not sure.)

Based on my testing, it seems to have a problem in the 'target attitude' selection, I think likely that the SAS's own movements are resetting it to the current attitude. Whatever it is, the SAS is not holding the set attitude, and I think in some cases is actively moving it off the attitude you're trying to set, ever so slightly.

It actually has a very cool capability to dynamically select which control devices it uses at any given time, based on how much force it needs. If it needs only a tiny amount, it uses just torque, and nothing else. If it needs more force, it'll start feeding in control surfaces and RCS thrusters (assuming they're on), but ONLY the ones it thinks it needs. So for example, rather than firing ALL the RCS thrusters in a particular direction at full power, it will use just the ones that provide the most rotational force on that axis, and only at the power level it thinks it needs them at. It'll start bringing in other thrusters at lower power levels if it needs more force, I suspect eventually ramping all the way up to full power if it thinks it needs it. And then, when it's got it nearly stabilized, it'll pull all the 'extra' control devices back out and go back to using just torque. It's very slick.

Every time I've tried to use it instead of Mechjeb, I've ended up frustratedly making repeated, very small adjustments to get it and keep it on the attitude I wanted it on, because it keeps sliding off. So much of the way it works is actually better than what Mechjeb does, but it NEEDS to work like Mechjeb's Killrot function has for ages, and that's what I was led to believe we were getting. If it's not, I'll just keep on not using the default systems at all, and use Mechjeb's instead, which still act the way the ASAS used to, except that it lets controls override it. Wasteful as heck with the RCS gas, if you turn RCS on, but at least it actually holds a heading.

That's what the old Pod and Avionics Nosecone did, because they lacked an integral component of the PID system. The ASAS (And the SAS itself until it was patched not long ago) was an explicit attitude hold, and my understanding is that the new system is supposed to be as well, just now allowing you to override it temporarily with control inputs, rather than having to turn it off. If it's not, well, it's frankly a little useless for spaceflight purposes: in space, with nothing to slow or stop your movements but control forces, you NEED an attitude hold, or you're forever making fine adjustments.

*Facepalm*...a very simple explanation for the behavior I observed just occurred to me. I think it's set to have the 'attitude hold' point set to whatever your attitude is when you stop using the controls, like it should to be... except that somehow, when the SAS system kicks in and starts trying to hold that heading, the SAS's control inputs are somehow setting off the part of the algorithm that resets the target attitude to the current one. So basically, it continuously resets the 'target' attitude to the current heading while it's slowing down, until it finally gets itself stopped, at which point it more or less holds, because the variations and inputs at that point are so small they're not really noticeable (especially as it uses torque-only for very small inputs). It'd only be blatantly noticeable on large movements, but would cause some instability on small ones. Exactly what I'm seeing.

I've had that problem with Mechjeb on SSTOs that were pushing controlability and stability right to their limit. I made a design that could Single-Stage to Duna with a Rover, but Mechjeb would lose control of it in the yaw axis on ascent. I had to manual it halfway to orbit before MJ could fly it. It was just so heavy for the amount of thrust, lift, and control forces it had that Mechjeb couldn't cope with it. I could.

It IS better in many ways, but there DOES seem to be some kind of an issue, possibly more than one, with it at the moment, for at least some people. Rampant Fanboyism frankly doesn't help us track down what's wrong or why. It's an Alpha. Bugs happen.

Which got closed immediately as a duplicate. Whoops.

Steam windows version. Title screen indicates 0.21.0.272 I've recorded a video of the behavior I've identified, and am uploading now. In 1080P so it's going to be quite some time. Basically what I've seen, is that when you let go of the controls, it seems to set the 'hold' point some way 'ahead' of where you let go. How far seems to be proportional to your turn rate: for small rotations it's only a very tiny amount. It then attempts to reach and hold this incorrect attitude. For very minor movements it causes it to slide, very slowly, off the point you're trying to set to one a short distance off it. If you do it precisely enough it can be so close it's barely noticable, but it does make it take a bit of fine tuning to get where you want. very fiddly, precise tuning. For larger movements, it causes it to miss completely.

Mechjeb's been updated. As for now, my all stock reinstalled steam version, with the Kerbal-X upper stage, is exhibiting the same behavior with the large ASAS added on. It's starting to try to damp the movements almost immediately, but not at full rotational power: It starts slowly and ramps up, and then as it starts to slow (long before it's stopped), it starts to ramp down. It eventually stops at a point around 90 degrees past where I let go of the controls (a little further with the large ASAS, presumably because of weight), and then holds that position. There seems to be some kind of error in what it's setting as the attitude to hold. The ramp down as it approaches the point where it stops suggests that it's actually aiming for that point almost from the moment you let go. What I'd expect to see is that it would ramp up to full almost immediately, hold until it started to rotate back towards where you let go, and then exhibit the behavior it's currently showing as it approaches that point. This error in setting the hold attitude seems to show up for small movements too, causing the SAS to start pushing it off the point where you set it at, as it tries to reach the erroneous setting.

I went and reinstalled cleanly, and ran a kerbal-x up to orbit fully manually. The behavior was almost the same. My observations: On Torque-Only craft with high mass relative to their control forces, the new SAS system is *extremely* slow to stabilize a gross movement. It initially tries to fine correct it, and brings in more control force gradually as that fails to do anything. This is pretty much how it's supposed to behave, it just doesn't work very well on a craft where you need full force to initiate or stop a movement of any significant rate. It seems to take the new SAS system awhile to realize that the small inputs aren't actually doing anything and go to full power...and then it does the same thing AGAIN when it gets back to where it's trying to hold. This causes it to bounce back and forth before gradually settling in and stabilizes. On something like the Kerbal-X core at 40KM+, where the fins do basically nothing, this can take 10-15 seconds for a gross movement to be nulled. The top stage demonstrates the same problem, to a lesser degree: I've got it on orbit with a bit under 2/3rds fuel...and may have found the problem. If I hold one of the yaw controls down until I've rotated about 45 degrees, it takes a further 90 degrees to stop. When it does stop, rather than rotating around to the point where I let go of the button, it rotates it around 1-2 degrees, to a point very near where it stopped, and stabilizes there. Is the Pod SAS still just acting a movement-damper and not a direction-hold because it lacks an Integral Component, like the old ones did? Going to add the renamed ASAS to it and relaunch.

Yeah, I just ran a Kerbal-X Launch just to test it. I used a Mechjeb unit to give me ascent path guidance on the navball, but flew manually (and STILL botched it by letting my attention wander), and noticed that while it WAS stabilizing, after I finished the initial ascent burn and let go of the controls, it wobbled back and forth on the yaw axis (functioning as pitch due to the placement on the launch pad) for awhile before settling in. It kinda seemed like the initial response was very gentle before getting harder and overcorrecting, eventually managing to null it out after several cycles. What I think might be happening is not so much that it's failing to stabilize, but it's doing so rather slowly, and people are assuming it's not working and trying to correct it manually before it really does anything. Or it'll start to correct, and being very slow fine-tune adjustments when they get impatient and do it manually. And then you end up with the fine-adjustment making it seem like it's creeping.

What throttle setting is this 'nose-down tendency' at, since you don't mention throttle at all. On mine, it holds almost perfectly stable at full throtle, and gains a nose-down tendency when the throttle is cut. The SAS *is* able to hold...eventually. I've admittedly only tried to use the stock SAS once since the update, and I experienced pretty much what they were complaining about: Constantly having to make adjustments to keep doing what I was trying to do (point prograde). Admittedly my target was probably moving slightly(Prograde in the middle of a maneuver), but what it seemed like was happening was that when I released the controls while still moving, it would take several seconds to start trying to stabilize that movement. And it would frequently seem to stabilize at a point a short distance AFTER I let go. It DID seem to be stabilizing, but not where I wanted it to, and there did seem to possibly be some drift, necessitating a lot of manual corrections. It wasn't long before I got frustrated and hit 'prograde' on the SMART A.S.S. again. The craft in question had very low torque and no other control surfaces, but there's a slight element of this visible in the Aries3A behavior too.