DMagic

I think Whackjob is right Fernbhoy. That rocket may have been stable before, but it probably shouldn't have been. That cupola is just bouncing around up there, and those two radial engines don't look stable at all, the force of their engines is pushing them off center long before the rocket explodes. The rocket also has very little in the way of torque; I think that capsules only provide torque when manned, so only your command pod is doing anything. The 2.5m grey ASAS module is completely redundant in your situation, it provides no torque and the command pod provides SAS functionality. The only use for this part is on large probe controlled crafts (and even this won't be true if they add SAS to the probe cores).

Just a few more things about testing here. This is my 600 part CPU performance test rocket (which is a story for another thread). The design is simple and very symmetrical, it just has a ton of parts, but it flies perfectly straight. For control points it has the command pod, two inline reaction wheels, the lander can (it's unmanned though, so I don't think it does anything), twenty winglets at this stage, three or four rings of RCS (which are never really needed), and only one, central gimbaling engine in all stages. It can turn at relatively low altitudes, too. It is sluggish, and doesn't hold course perfectly, but I think that's to be expected. Only minor manual inputs are needed to keep it steady. During the most unstable section of flight, shown on the right, there is a bit of wobble and some rotation. You can see that the RCS does fire to keep it fairly steady, but manual input is necessary to keep it from rotating and to hold it on course. This really isn't surprising though, that short section of the flight is not designed to handle large changes in direction and that central stack on the bottom left flops around a lot. This craft was created in 0.20, so it could also have some instability related to that, but nothing major. And here is another thing that I mentioned earlier. Mechjeb was updated so I tested out the Smart ASS function on a tall, somewhat wobbly rocket. With the stock SAS function there wasn't really any wobble at all and this stayed straight up. Mechjeb is definitely more aggressive in keeping the rocket on course. The winglets move quite a bit more and the rocket starts to wobble. And it is definitely better at holding the rocket on a fixed course once you start turning. Even when I decouple the lower stage Mechjeb is better than SAS at holding course.

I just tested your design too. I throttled up, pushed T, then space and took my hands off the keyboard. It went perfectly straight up, no wobble, no veering off course, all the way until I ran out of fuel; it continued straight on until it neared it's peak of about 210000m, where it started very slightly veering to the west (maybe 1 or 2o off course. The canards made very slight movements, but I had to zoom in just to see them. If you haven't already done so, submit a bug report. There is no way that your craft should have the kind of problems you describe. Edit: Here is another thing to try if you can get a command pod into space (it doesn't have to be in orbit, just above 70000m or so. Decouple the rocket so that you just have the command pod. First check for any no-input phantom rotation, both with and without SAS on. Then turn off SAS and stat spinning, you should continue spinning in the same direction. Next turn on SAS, you should top almost immediately. You shouldn't need any batteries or solar panels. The command pod has enough power for a few minutes of screwing around like this.

Have you filed a bug report? If others can fly the same craft perfectly straight and you can't then it seems that there is a bug somewhere and it should be reported. And not that I think this should matter or cause such an issue, but you probably shouldn't use the inline advanced stabilizer. The command pod has SAS functionality, so there shouldn't be any reason to use another SAS part.

I think I agree with this. It may break some people's old .craft files, but this is still very early in development; everyone should expect their saves and crafts to break. This would reduce the total part load and clear up some confusion about how the new SAS functionality works. Then we could have just three reaction wheel parts. And with the way parts work now we should only need one inline reaction wheel just scaled to three different sizes (0.625m, 1.25m, and 2.5m) with corresponding torque values and mass. Edit: See here for C7's response about adding SAS to the probe cores. http://forum.kerbalspaceprogram.com/showthread.php/42121-What-s-the-justification-for-probes-not-having-SAS?p=542657&viewfull=1#post542657

MechJeb has been updated. I would like to see what happens when people use MechJeb's Smart ASS to control their crafts instead of the new SAS. If you were having unexplained flight behavior before it would be interesting to see if MechJeb can compensate where the new SAS can't. I'm not suggesting that you should have to use MJ from here on out, but it would help to know if these unexplained forces are enough to overpower MJ as well as the stock SAS.

The 2.5m grey ASAS module has several problems: The name should be changed. There is no more ASAS functionality, so having a part named ASAS does nothing but confuse people. The part itself seems to have little legitimate use. The only thing I can understand it being used for is large, 2.5m probes, which lack SAS functionality. But a large 2.5m probe craft is likely to need more reaction wheel torque than is provided by only the probe core. This means that we need to add 1.25m inline reaction wheels. And if we are going to fit those parts in somewhere then we might as well just use the 1.25m inline advanced stabilizer instead of the 2.5m ASAS part. So if we are going to keep the 2.5m part around, it should have reaction wheel functionality added to it. The name and mass should then be changed accordingly.

The avionics package may be your best bet for small probes. I don't like it much though, it looks kind of funny, and I'm not sure if this part is configured differently than the other SAS equipped parts. A scaled down version of the Inline Advanced Stabilizer would be much better for probes. With the way part files work now couldn't they just add another section in the .cfg file with a "RescaleFactor = 0.5" duplicate of the IAS part, with correspondingly updated mass and torque settings? And I'm thinking that the only reason we still have that stupid 2.5m ASAS module (even the name just seems to add to the confusion) is to allow compatibility with old crafts. If they aren't going to add reaction wheels to that part then they should just get rid of it. It might break a few old craft files, but they already decided to break saves, so I don't think this is a good enough reason to keep it around.

Are you referring to out of control spinning with no input? If you have some kind of phantom rotation then it's a bug, and if you can reproduce with just stock parts you should definitely fill out a bug report. This has been around for a while and it is definitely a problem; it might be caused by parts clipping through each other or it might be something else, so bug reports and craft files are essential for fixing this. And this might not be related to the new SAS functionality. The old ASAS may have been able to compensate for this, but in some cases the new SAS might not be able to, that doesn't necessarily mean that there is anything wrong the new SAS, just that it works differently from the old ASAS. I don't know about space planes. Maybe the solution is to make the avionics package more aggressive and update the description to make this difference clear. Asymmetrical crafts are inherently unstable. Maybe the old ASAS was able to compensate in some cases, but that doesn't mean that you should expect a craft that was stable in 0.20 to always be stable in 0.21. You might be able to keep it stable with many more inline reaction wheels, more RCS, or more command pods, or you might not be able to. If you are going to fly something inherently unstable then you should probably be prepared to babysit it during long burns. You'll have to wait for C7's blog post for more details about how the new SAS system actually works. And I changed the wording to make it clear that it can only try to maintain a heading (this is after all what the old ASAS did, just more aggressively), but it may not be aggressive enough. It seems that way. Better design and more effective use of control mechanisms may allow you to maintain a heading, or it might not. And I can almost guarantee you that, within a week or two, someone will make a standalone ASAS functionality plugin. But really I see no reason why someone can't just use MechJeb to maintain a heading and just ignore all of the other features of the plugin (assuming that it works the same way when updated). There is definitely something wrong here. I have tried building something very similar to your rocket and SAS does a fairly good job of maintaining heading; not perfect, but it never veers way off course like your example. And like I said in the first post, I don't think there is any reason to use two parts with SAS functionality. If someone can explain why multiple SAS controls can help than I would like to hear it and understand why. But until then I think you should only use SAS parts (Avionics Package, Inline Advanced Stabilizer, or the 2.5m ASAS module) when building probe crafts, or maybe planes. If you want more torque you can put multiple Inline Reaction Wheels, but don't use multiple SAS parts. If people are still having issues like this after starting from a clean install, with no mods, new crafts, and no joystick/gamepad, then there is a bug and you should report it properly, not just in random SAS threads.

I made a thread on this in the tutorial section. http://forum.kerbalspaceprogram.com/showthread.php/41941-New-SAS-functionality-and-You%21 Basically it's what Kaleb said above. There is no such thing as ASAS anymore (really change the name of that 2.5m part).

0.23 Update Not much changed in 0.23. Subjectively the SAS system feels about the same, there may be some minor tweaks from 0.22, but I haven't noticed it. No changes to the parts. There are two issues that do deserve mention. The "docking mode" control bug has been fixed. Using the WASD keys in docking mode for translation control will no longer activate damping mode. The roll controls (QE) do activate damping mode, but this is to be expected. While not strictly related to the SAS system, the new tweakables system can affect stability. Maximum engine thrust can now be controlled separately for each engine. In the VAB you can monitor the center of thrust during such adjustments to account for mass imbalances on a non-symmetrical craft. Thrust can also be altered in-flight, but obviously you won't be able to directly observe the new center of thrust. Everything else below should still be valid for the current SAS system. --------- 0.22 Update There have been some changes in the 0.22 update to the SAS system. Parts: Inline Reaction Wheel - No change Inline Advanced Stabilizer - No change, provides the same torque as the inline reaction wheel but has a higher mass; don’t use this part ASAS Module (2.5m grey wheel) - No change, still has the same aggravating name, still provides the same torque as the smaller reaction wheels at a lower weight Avionics Package ---> Sensor Array Computing Nose Cone - No longer has any SAS function; this is now a science system part Command pods and probe cores - No change Hex Probe Core - Still has bugs in .cfg file; includes old, pre-0.21 SAS entries and bounded by ')' instead of '}'. MkI Command Pod - Has the same amount of torque, but doesn't seem to shake as much with SAS on. Functionality Changes: Summary: - SAS indicator on Navball – Now shows when you are in damping mode by replacing “SAS†with two spinning arrows icon - Higher usage of available control authority – Can maintain heading better, but may cause more oscillations - Unbalanced crafts maintain heading better under thrust – Should see less of that “stable drift†that happened in 0.21 – See below # - Damping mode – Switching to damping mode briefly causes controls on all axes to drop to zero – See below & - RCS translation controls - Damping mode activated by translation when using 'docking mode', but not when using 'staging mode' - See below * System Changes: There are several aspects of the SAS system that have been tweaked in 0.22. The first, and most visually obvious change is the SAS indicator above the Nav Ball. When SAS is activated with “F†or “T†the light turns on as normal, but when the system is in damping mode the indicator changes to two spinning arrows. Any manual input will switch the system to damping mode; it will stay in this mode for a brief moment after releasing manual input (how long it stays in damping mode depends on how much the craft is changing direction). Once the system is in locking mode the light will change back to the “SAS†indicator. The system still works off of your true orientation in the Kerbal universe. This means that while SAS is activated you will stay oriented in the same direction with respect to the universe, regardless of your position with respect to the planet/moon you are orbiting. This is effectively the same thing that happens when you activate timewarp. If you point at the prograde vector, wait half an orbit and you will be pointed retrograde; if you point at the surface, wait half an orbit and you will be pointed directly up from the planet. If you create a maneuver node and point at the blue vector you will follow it throughout the orbit (though you will slowly drift away from the vector, I assume this is due to the orbit of an object around its parent body; this doesn’t happen in Kerbol orbit). On the whole, the SAS system seems more aggressive. It uses more available control authority to try to maintain heading. This can cause more oscillations if you aren’t careful. By using manual corrections and toggling off/on SAS with “F†it is usually possible to avoid these large oscillations. This isn’t always easy though, and very long, or otherwise unstable crafts will probably have this problem regardless of what you do; that is more of a problem of bad craft design than a faulty SAS system (that some of these designs may have worked in previous versions doesn’t mean they aren’t problematic). Roll control has been greatly improved. In many cases SAS will stop roll almost immediately after control is released; with relatively small crafts it works almost as well as using RCS to stop rolls. You can still overload its ability to prevent roll (SRBs are great for doing this, which might cause some issues early in career mode), but it is better overall. # - Unbalanced crafts should work better in 0.22; this is best demonstrated with a test case. These crafts are identical, but were built from scratch on new saves in both 0.22 and 0.21. Click on the pictures for bigger versions. The craft has one command pod, one large reaction wheel and one gimbaling engine. During launch it is easily able to handle the imbalance in both versions, though 0.22 does feel more stable overall. Once the upper stage is separated the behavior of SAS differs between the two versions. In 0.21 SAS can hold the craft steady at up to about 50-60% throttle, after that the craft will begin spinning out of control; in 0.22 it is stable at a slightly higher throttle. In both cases SAS is using full control authority on the pitch and yaw axes to maintain heading. There are two important points here, and one big difference. In 0.21, even when the craft is held steady it won’t maintain its original heading. It drifts a few degrees in the direction of the imbalance, then holds its heading there, even when there is excess control authority available. In 0.22 this drift is greatly reduced; SAS mostly holds the original heading until it loses the ability to maintain heading at all (this is greatly helped by slowing increasing throttle, instead of going straight to the max). One important point that can be observed here is that it is possible to get stuck in damping mode. If you start rotating or go beyond the system’s ability to maintain heading the indicator will switch to the damping icon and will stay there. This doesn’t seem to affect the amount of control authority used, it simply means that the system has no heading to lock onto. & - The other point is that damping mode doesn’t work the way you might think. At around 50% throttle the controls on the pitch and yaw axes are almost maxed out and the system is in locking mode. If you then rotate, the system switches into damping mode. Right away, you will notice that all control on the pitch and yaw axes drop to zero. This will cause the craft to start spinning out of control despite the fact that there is enough control authority to hold it steady. The system will resume controlling the pitch and yaw axes (even if you continue to hold the rotate controls), but that brief interval where the controls drop to zero is enough throw off the system. RCS: * - Using the translation controls for RCS in 'staging mode' (the H J K L I N keys) will not cause damping mode to be activated. Using the translation controls in 'docking mode' (the WASD keys) will cause damping mode to activate. This remains the case with 'fine controls' (activated with the CAPS lock key) on or off, and this also occurs even with RCS turned off. This behavior is not entirely predictable, activation of damping mode seems to be at least somewhat dependent on whether or not the RCS thrust is imbalanced. And excessive input, or very imbalanced thrust can cause damping mode to activate in 'staging mode', but I believe this is because the craft is momentarily unable to hold its heading (similar to the situation described above), and is not the same as what happens in 'docking mode'. The 'staging mode' case seems to be more useful, docking usually requires careful control over your heading, and damping mode is not as effective as locking mode for providing this. I would recommend staying in 'staging mode' and using the translation controls instead of using 'docking mode'. Will update as more info becomes available. 0.21 Information Most of the information below should still apply. See C7's latest blog post on the new SAS system The 0.21 update brought with it many changes to the SAS functionality and a whole host of complaints to go along with them. So I feel like I should attempt to explain how some of these new systems work. Keep in mind that this is from my non-developer point of view, so if you find anything blatantly wrong here just tell me and I'll update this post. That said, most of what's changed can easily be understood by taking a minute to look at the part .cfg files. Changes from the old system: ASAS functionality is gone, replaced by SAS Command pod torque is replaced by the reaction wheel system Part names and functions: SAS Module (1.25m grey wheel) ---> Inline Reaction Wheel - Provides torque and SAS function ASAS Module (1.25m yellow wheel) ---> Inline Advanced Stabilizer - Provides torque and SAS function ASAS Module (2.5m grey wheel) ---> Same name - Provides torque and SAS function Avionics Package ---> Same name - Provides SAS function only All command pods, cockpits, and probe cores ---> Same names - All provide varying amounts of torque, and SAS function New System: Reaction Wheels: These are what provide rotational torque. They allow your crafts to move without using gimbaling engines, RCS, or control surfaces in an atmosphere. This is an improvement on the old system and is more realistic than the magical command pod torque. Pushing "T" to turn on SAS has no effect on the reaction wheel system. You can produce torque regardless of whether or not the SAS light is on. All parts with reaction wheel functionality use electrical power when you turn, they all have an option to toggle torque if you right-click on them, and they all have the line "name = ModuleReactionWheel" in the .cfg file, which is followed by the specific torque values in each axis and the electrical power consumption rate. All command pods, cockpits, probe cores, and the three reaction wheel parts mentioned in the section above provide this function. The chair, however, does not. SAS Functionality: The new implementation of SAS is probably the more confusing change. This is what tries to maintain your heading (true orientation actually, which will change as you orbit a planet), controls reaction wheels, activates control surfaces, gimbaling engines, and RCS thrusters. Any and every control system is controlled by any part with the SAS function. You do not need to add an Inline Advanced Stabilizer or Inline Reaction Wheel to control RCS, gimbals, or control surfaces. SAS is not nearly as aggressive as the old ASAS functionality. This reduces wobbling and over corrections a lot, but in many cases your rocket might drift away from its current heading. The 0.21.1 update addresses this and seems to reduce or eliminate drift in most cases. Adding more Reaction Wheel parts can help eliminate drift or accommodate an unbalanced rocket. As detailed in C7’s blog post linked above, there are two modes for the SAS system. In damping mode, SAS will not try to maintain a heading, it will only provide stability and should allow for smoother control over your craft. In locking mode SAS will try to maintain a heading. There is, however, a delay in switching between damping and locking modes. Constant manual input (or joystick signal noise) will prevent locking mode from activating. This is not an autopilot, so don't expect it to be one. It also does not lock out the controls, you can activate SAS and still control your craft. As mentioned above, it is present in all of the manned command pods, cockpits, all of the probe cores, the Inline Reaction Wheel, the Avionics Package, the 2.5m grey ASAS module, and the Inline Advanced Stabilizer. The chair, again, does not have SAS functionality or provide torque. Any part with SAS functionality will have the line "name = ModuleSAS" in the .cfg file. This function does not use any electrical power, it has no right-click toggle value, and it does not provide any rotational torque by itself. When you push "T" (or hold "F") to turn on SAS, you are now activating the new SAS functionality. There is only one effect of activating SAS now, not like before where you had the somewhat conflicting SAS/ASAS functionality activated with "T". RCS Changes While not strictly related to the new SAS system, there has been an important change to the way RCS functions. When under the fine control mode (activated with CAPS Lock, and indicated by the icons in the lower left corner changing from orange to blue) the RCS thruster compensate for their distance from the center of mass. Thrusters further away from the COM will provide less thrust. This should help to reduce unwanted rotation while docking. Don’t expect it to work perfectly; proper RCS placement is still important. .cfg File: Here is an example of the relevant portions of the Mark1-2 Command Pod .cfg file: MODULE { name = ModuleSAS } MODULE { name = ModuleReactionWheel PitchTorque = 15 YawTorque = 15 RollTorque = 15 RESOURCE { name = ElectricCharge rate = 1.2 } } “name = ModuleSAS†provides the SAS function. “name = ModuleReactionWheel†and the lines following it provide torque. It should also be noted, that while the old ASAS functionality has been removed from all parts in KSP, it is still present and can be reactivated. Adding the line “module = AdvSASModule†to a part’s .cfg file should provide the ASAS function. See UmbralRaptor’s post down the page a little for more on this. Usage in 0.21: So there is now a change in the proper usage of these parts. The only purpose of the reaction wheel parts is to provide extra torque; the 1.25m yellow Inline Advanced Stabilizer, the Inline Reaction Wheel, and the 2.5m ASAS parts. The command pod or a probe core should provide any SAS functionality that you need. Again, chairs present a special use case and will require either a probe core or one of the parts listed above, both to provide SAS functionality and to provide torque for movement. You can add as many Inline Reaction Wheel modules as is necessary. More of these should allow you to turn easier, maintain a heading, and compensate for unbalanced rockets (within reason), they will also use more electrical power. Summary: - ASAS is gone, it has been replaced with SAS - All command pods, cockpits, and probe cores have SAS, all four parts under the Control Part tab also have SAS - SAS is less aggressive than ASAS, but more versatile - Manual input may be required to maintain a course - It is not an autopilot, but it won't waste RCS like the old ASAS did, and it should make docking far simpler - SAS is the only thing you are activating/deactivating with the "T" and "F" keys - Command pod torque has been replaced with the reaction wheel system, this allows for turning independent of any other control system - All command pods, cockpits, and probe cores have reaction wheel torque to varying degrees - The Inline Advanced Stabilizer, Inline Reaction Wheel, and 2.5m ASAS module also have reaction wheel torque and SAS functionality - Torque can be disabled with action groups or through the right-click toggle button - Torque uses electricity Troubleshooting: If you are having issues with maintaining a heading, uncontrollable spinning, or other control problems then there a few steps you may want to take. Make new crafts from scratch. Start with something simple just to check if everything is working right. Vanamonde and stupid_chris have good examples on page 2 of this thread. Making and testing similar crafts will allow everyone to make sure that we all have consistent flight behavior. If you use a joystick/gamepad then unplug it and uninstall any drivers (even if you aren't actually using it) to make sure this isn't causing any issues. This still appears to be an issue in 0.22, so it's a good idea to check this if you are having problems. There are several threads in the support forums concerning joystick support. Be careful to avoid having parts clip through each other. This is known to cause phantom rotational forces; this may not be the only cause of this bug. Completely delete your KSP folder and make a fresh reinstallation. Make backups if you want, but it's probably best to start everything from scratch; it's still early in the game's development, you should expect to have to do this with every update. If you find anything wrong with this thread please tell me and I will update this post.

This is very true. I've found that the default DeltaV window in Mechjeb causes about a 10-20% drop in FPS. If you use MechJeb and have FPS problems, closing this window can make a difference; not a huge difference, but 2 or 3 extra FPS can be fairly noticeable. And the drop in GPU usage makes sense when you think about performance being CPU limited. The GPU doesn't have to work nearly as hard at 10 FPS than it does at 60 FPS, so usage drops. Edit: And about Unity multithreading, I don't think the problem is with Unity's threading, it's the version of PhysX it uses. You can clearly see that KSP uses more than 1 thread by looking at it's CPU usage. But PhysX version 2 is single-threaded and has bad performance on the CPU. PhysX version 3 is supposedly much better, but I'm not sure if it's feasible for KSP to switch to that, or if it's something that would have to be supported by Unity first.

I wouldn't count on a weekend release. But I do look forward to seeing how your Moho mission turns out, there are never enough of those.

It just means that there are four rings on the gimbals instead of three. Once again, Google and Wikipedia help here. http://en.wikipedia.org/wiki/Gimbal_lock

The version of PhysX used by Unity doesn't support GPU physics; everything is done on the CPU. So this isn't an issue for graphics card choice.

The KSP NavBall may not suffer from gimbal lock, but the camera does. That's why you can't just continually rotate in one direction. Once you hit that maximum rotation you have to spin it around 180o and rotate it back the other way.

I do love the Delta IV Heavy. It seems to me that it's the most Kerbal of all the rockets currently in use.

It's harder to get into a circular low orbit. But if all you care about is actually getting into a stable orbit then it's easiest to do the injection burn very close to the planet/moon and stop once you get into a stable, highly eccentric orbit.

I crashed into the north pole once with an unmanned lander, but I never spent much time near these things. It's interesting to see what happens when you get to the bottom. I'm guessing that you fell through the ground, and that's why your altimeter started freaking out. There's not much you can do about getting good pictures at the poles, since they never have good light. You could try cranking up all of the brightness settings, and brightening up the picture itself, but it probably won't help much.

I think the problem is that you are probably trying to get to Moho the same way you get to any other planet; wait for an ejection window from LKO, do a correction burn mid flight, then do a single orbital injection burn. This is possible, but it's very tricky to do well with Moho. Even small deviations from an ideal transfer between Kerbin and Moho can lead to very high delta-v requirements for the injection burn (I've seen anything between 2300 and 5000 m/s). I've been to Moho many, many times, probably more than any other planet. For almost every attempt I completely ignored transfer windows. There are some tricks for dealing with the inclination change that have already been mentioned, like waiting until you are at the ascending or descending node to do the ejection burn. Those help, and can save you some delta-v. But the most important thing, at least I think so, is to just treat a Moho transfer like an orbital rendezvous. Do your ejection burn in LKO until your solar periapsis crosses Moho's orbit (it's best to do this so that you intercept Moho's orbit near its own solar periapsis). Then do multiple shorter burns at periapsis to bring down your apoapsis down a bit. You might have to make a few orbits around the sun to get a good intercept. But by doing it this way you can insure a near ideal intercept, one where you meet Moho at, or very close to, your own solar periapsis. Yes, this method means that you don't get much benefit from the Oberth effect; some, or most, of the injection burn is done in solar orbit, far away from Moho. But I can almost guarantee you that you won't get an ideal intercept by setting up the transfer the traditional way. This is especially true if you are using a large lander, or other heavy vehicle, that requires very long burns. This method also means that your final injection burn should be much shorter, which is much easier than trying to deal with a single 4000 m/s burn near Moho. I use some tricks to deal with the inclination change, some are described in my Moho thread, others have been mentioned here, but those really only save about 500 - 600 m/s of delta-v. Setting up transfers the way I described above I was regularly able to go from LKO to a stable, 100km polar orbit above Moho using under 5000 m/s of delta-v, my record was around 4300 m/s. And this was done using all manner of different vehicles, from relatively small and easily maneuverable crafts, to ridiculously heavy things that took 15 minutes for the ejection burn (and took 5 minutes just to turn around).

Are you talking about actual fuel amounts, or the little green fuel meter next to the engine in the stage list? Edit: 1 minute too late

Are the two center tanks that you are draining from of equal size? If so, you could just use one fuel line fore each center tank. Send fuel from one tank to the left engine, and fuel from the other tank to the right engine. Then from there send it back to the bottom central tank. That might help, because I think the game is getting confused trying to balance fuel flow from so many different sources. That said, I'm not sure I understand the purpose of this overly complicated setup. Are you trying to get the central section into space with the top part, two empty fuel tanks, and two engines? I assume those are engines between the fuel tanks, with a thin decoupler below them (with the little red arrows). I can understand refueling in space, but why would you need two engines? It might work better to just use a single engine with a bigger fuel tank above it, then you would only have one source for fuel.

I think the crew management aspect was the initial change that will break our save files, but it sounds like there will be additional changes as well. From what Harvester said it sounds like they have a lot of changes they want to make, all of which will break save continuity. They were just waiting until they had a major, save-breaking, addition before they implemented these other changes (none of which they have actually given details about). And although I haven't seen anything explicitly saying this, I think they mean that we can put Kerbals into any part that can actually hold them. As in, command pods, lander cans and so on, not just any part. Unlike now, where Kerbals are only automatically put into the first manned part.

Eww, Mark 55's are best avoided unless they are absolutely necessary. Do you have very low TWR? Because unless you are just barely lifting off, it would be better to just replace the LV-T30's with T45's, or maybe 2 T30's and 2T45's

You don't need action groups for landing legs, at least if you only have one set of them. Just push 'G', it's set as a permanent action group for landing legs. And it's always a good idea to have at least on gimballing engine on your first stage. Control surfaces only work well in the lower atmosphere, during most of your ascent you will probably be reliant on other methods for turning.