Tiron

KAS Very, very broken in 0.20. Winches, Hooks, and Connector don't load. I lost two of my flights! D:

Not as long as you put everything in the right places. You need to put a mechjeb-enabled part on your ship in order to use any of the options. You'll get a pop-out menu on the left side with checkboxes to turn the various panes on or off. They're all off by default. Mechjeb 1 has a couple of unmanned pods, and some probe cores both radial(In 'Command and Control') and inline(In 'command pods'). Mechjeb 2 has a single radial probe core. 1.9.8 and 2.0.x share no parts or files, and thus can be installed side by side...though I suspect mixing them on the same craft is probably less than advisable.

Mechjeb 2 is still in development, and as such installs separately. Different plugin, different part (that's right, singular.) Nothing from Mechjeb 1 is overwritten or changed, so you can run them side-by-side. In order to use Mechjeb 2, you must use the Mechjeb 2 AR202 unit. If you installed overtop of 1.9.8 You'll still have all the other parts, including a second AR202 case, but the old parts will continue to use Mechjeb 1. The Mechjeb 2 AR202 is smaller than the Mechjeb 1 AR202. 75% of the size, if I recall right.

Actually, it's not ENTIRELY untrue... because there's two different versions of it. One works right, one does not, because they use different attachment methods. http://kerbalspaceprogram.com/docking-strut/ which if I remember correctly creates the strut as a physical object. There's an error in the way it's done, so when the strut is placed it causes an erroneous force out of nowhere, which can cause spinning, push the ship off course, or in the right circumstances even tear the ship apart. This is the 1.0.0.0 version. http://kerbalspaceprogram.com/docking-strut-2/ an updated version, using a different locking method, that works just fine. It has an unsearchable, messed up spaceport page that simply has a link to a the file. If I remember correctly this is the 1.0.0.2 version, and was the version linked from the creator's forum thread before the database messed up. In short, the hearsay is PART right...the version you can find easily IS messed up and doesn't work right...because it's an older, somewhat experimental version. The newer version, which can't be found in a spaceport search, is the version to use.

The Docking Strut is much more realistic, because you have to have two, pre-installed strut bases to connect. You can't just magically make a connection to wherever.

Yes, does the same thing regardless of if you use coordinates or select a target (he fixed the co-ords thing in one of the dev versions). The problem is it's getting bad landing predictions while the auto-land is turned on, and issuing erroneous 'course corrections' based on them. The initial Deorbit burn is correct, because it doesn't have a landing prediction yet.

http://kerbalspaceprogram.com/docking-strut-2/ which doesn't show up in spaceport searches and has an oddly broken spaceport page works in 0.19.1 without inducing spinning. It uses a different method to attach and was the one linked from the creator's announcement thread prior to the great database doom.

Having a big-time problem with the landing module on 2.0.7-39. Trying to land a kethane mining and refinery rig on Duna. It's got a cluster of 7 NTRs on it, but lost one of the outboards during a recontact mishap (which the RCS was able to correct for, until I just shut the opposite engine off). When I activate autoland, it does a pretty good initial deorbit burn, and then starts issuing absolutely stupid course corrections that end up pushing the Peridune back up into the mid atmosphere. The second to last burn it does, it actually stops attempting to steer and just lets it drift while the engines run. The final burn expends all fuel, while the listed Delta V of the course correction goes UP as it burns. The net result is a crash approximately 1/3rd to 1/4th of the way around the planet past the landing site. Proximate cause seems to be that the 'Landing Prediction' module is malfunctioning while the auto-land is turned on, giving obviously incorrect predictions that are EXTREMELY short of the mark. Turning off autoland seems to fix the predictions, revealing that the initial deorbit burn is in fact pretty good: On the most recent attempt the initial burn put the landing site at a bit over 21km short. The result of the initial Deorbit burn, clearly showing the really bad landing site prediction. Mere seconds later, with the Autoland switched off before it can do a 'course correction'. Shot of the craft in question, which has 2 mechjeb2 units (one on the top half, one on the bottom), a probe core (it occurs to me the core's on the top half so that part doesn't NEED a Mechjeb unit...), and is using parts from Kethane 0.4.3 and Kerbal Attachment System 0.2.3 (excellent mod, btw). For the record the damage occured during the Duna Injection Burn, and it's been fine since. I've pulled the pre-burn quicksave.sfs if you want it, but the two other ships in flight are using a few more mods: There's a slightly stranded spaceplane landed on Duna with a DEMV mk3 EX and an ISA Mapsat GPS module as well as Kethane and KAS parts. There's also a mapping probe on its way to Eve with Kethane and ISA parts, as well as a Protractor...which doesn't really do what I wanted it for so I'm probably going to re-ditch it after the probe is done. I also have the subassembly loader and Romfarer's redo of the Sunbeam (v25), the former of which is VAB/SPH only and the latter isn't currently being used on any ships in flight. Also the DEMV mk2 and DEMV mk5, also not being used atm. Also, larger Xenon tanks from the 'Ion-Hybrid pack' 1.4.3, which are also not in use. (The extra engines were NOT installed, just the tanks, to be used as part of a propellant depot station.) Aaand Docking Strut 2, also not being used (but lovely just the same). Edit: I'm going to try letting it do the first, fairly small correction burn and see where that puts the landing site. Will report back shortly. Edit2: The first course correction puts it about 177km long. :|

Also remember that Kethane Refining works by using negative amounts of fuel from the tanks in question (it's a dirty, dirty hack but it works). In the case of Xenon and Monopropellant this isn't much of an issue, because they automagically flow anywhere on the craft. For Oxidizer or Liquidfuel, it has to be set up such that if you replaced the refiner with an engine, the engine could draw fuel from the target tank. This means, for example, that fuel lines have to run from the tank to the refinery, not from the refinery to the tank(because, behind the scenes, the tank is sending negative fuel to the refinery).

My first round the world suborbital flight was with this, and took less than 50 minutes because it's just that fast: http://kerbalspaceprogram.com/ravenspear-mk3-d-manta-stock/ Here's a screenshot of the test flight for that model: http://cloud-2.steampowered.com/ugc/576731339815250873/564244E5F9DAA815B5FC6D7231FAC6E75DFDF44B/ You can indeed, but it won't change the actual setting on the engine unless the craft is 'alive'. Given it was an ion engine, it should've still been able to warp after cutting the throttle since the engine can't run without power anyway (preventing the 'you cannot warp while the ship is under acceleration message).

Well there's about a dozen people complaining about it in the comments on the spaceport, and nothing helpful comes up on a google search. Given it's such an easy work around...ought to be a note somewhere.

I don't think that's the issue, at least not on mine. It turns the game into a slideshow at launch if map drawing is enabled. Turn it, off, and the lag goes away. I'm gonna play around with it a bit and report back later. :| Edit: Quick report: Re-activating at 17km caused massive lag. At 33km caused maybe the slightest, most minor of hitches. Once. Seems to be a 'scanning at low altitude' problem. Since the scanning is enabled by default... Edit2: The lag breakpoint is somewhere between 25 and 26km. Edit3: Don't occur during descent, only initial launch...that's weird.

Stupid little annoyance I noted while trying to use MJ2 on a rover: The Navball Orientation of the AR202 Case seems to be rotated 90 degrees to the right. You have to either place it on the left side of the rover or leave it half buried in the top rather than flush with the surface to get the navball properly oriented.

I just managed one myself a little over a week ago... It's a (VERY heavily modified) variation on my Ravenspeark Mk3-D, which I've dubbed the Ravenspear Mk3-F (the E was a twin-cockpit version of the D that I never uploaded), using some tricks I'd used on the C and some experimental variants of it. It'll make orbit with enough fuel left to transfer to the mun (though not enough to pull into a mun orbit when it gets there, so far anyway.) It's even possible to actually land it, though it does get a bit unstable at high speeds with the rocket fuel gone (I suspect because it's got too much lift for that amount of weight), Once you drop below 200 m/s it's fine though. Debating on uploading it (I mostly uploaded the -D to prove a point in a...discussion...about flat spin characteristics and recoverability). Edit: Err, the screenshot's a tiny bit outdated...this was the first 'full featured' version I got to orbit, before I started messing with it to improve the efficiency... the current version looks mostly the same though.

Well it's been modified an aweful lot since I posted, as I try to figure out how to work around the fuel routing problem... I have an idea now that I think will work though... but it's half torn apart atm as I need to do some rebuilding. It's the exact same problem manifested in the exact same way as on the mockup, though. Complete with the two dead fuel lines and pulling fuel from four tanks instead of two, and two of them on the 3-based landing stage. The mockup's just umpty thousand times easier to follow because it doesn't have 250+ parts. It also doesn't require any mods...unlike the actual rocket.

The actual rocket that was having the problem had 6-symmetry on all stages, asparagus wired. The upper and lower stages were wired in pairs, the lander stage was wired in triads so that it could land stably. The tester is chopped down, without the 'extra' asparagus stages, to demonstrate the way the fuel flow gets confused. The lines don't break, they just don't get activated. If you move the radial engines down to the tri-stage, all three lines function properly. I've run the lines both with symmetry enabled and one at a time, and redone the fuel line setup entirely three or four times. And used different wiring schemes to accomplish the task at hand. None of these worked. The actual rocket is 2m, planned to use 12 tanks (two groups of six in hex symmetry), wrapped around a hex symmetry stage around a single centeral core, all of it asparagus staged. There's multiple stages thrown in, as it's intended for an eve land-and-return trip. The design I was going for would've have a huge 19-section for on the bottom for kerbin orbit, a small 19 section for transit (outer ring), and landing (middle ring and core) above that, then a large 7-section (inner ring and core only) for Eve ascent, with a 1m 7-section with rad-rockets for final orbital boost and possibly transit, and a small core-only stage on top with a rad-rocket as a contingency. I wire the asparagus setup to cross sections though, so the upper stage engines can fire immediately after the section under them drops, burning fuel from the lower section to do it. I just can't seem to get it wired through the landing stage.

Yeah, I thought as much but I thought I'd better check first. The thing that gets me is that both of the individual transitions works fine, it's just sequentially that it has a problem with. Thanks, though!

and for the record, in my experience, gimbaled engines can't really control roll at all, so in atmo you need some kind of controllable fins to be able to manage roll in any meaningful way. I tend to use Standard Canards rather than Winglets though, as they're lighter and have more lift... >.>

http://pastebin.com/uYqUwSbk then. Named Fuel Flow Tester.craft Edit: Sorry, ADHD Got me. I actually thought about that, except that all my lines are purely tank-to-tank, with all of them separated by decouplers... and the problem isn't the fuel flowing where it shouldn't, it's the fuel not flowing. There's actually two fuel lines that are showing up inactive(Grey), even though they're part of a set of three, and the third one is fully functional. Edit2: Oh, and the tester is set up so that the staging shows the way the fuel should flow, at least in theory, with each fuel line on its own stage so you can see the active and inactive ones easier.

I've read they're planning on adding the ability to save 'assemblies' to do just this later, but for now there's no such option. You CAN just edit the .craft files to accomplish it, as they're just text, but it's a bit of a pain. You have to edit the parts you don't want to use out of it (Like the command pod!), and make sure to also get the link references to the missing parts on all the remaining parts. Sometimes it'll tolerate a link to a part that no longer exists, but sometimes it blows up and displays 'loaded ship missing parts' instead of the craft's name, which also has the side effect of locking the game up.

Been trying to build a Returnable Eve expedition for most of a week, and it's not been going well... and now I've run into what I *think* is a bug in the fuel logic, but I'm not sure. Basically, I'm trying to do inter-stage asparagus-ing (it's awesome when it works), but I'm having some problems getting fuel routed from my lower stages to an upper one(With radial engines) through the lander stage. Basically, the Lander stage is a 3-3-1 asparagus setup (So it can land stably even with one of them gone), and the stages both above and below it are 2-2-2-1 based. The fuel routing just won't seem to work right, no matter what I try. Instead of burning all the radials on the upper stage off the two active asparagus stages on the bottom, it burns off the two bottom tanks AND off two of the tanks on the lander stage simultaneously(Since the lander's 3-based, this would end up unbalancing it.) Two of the three fuel lines leading from below up to the lander stage show as inactive. Disabling flow on one tank on the lander stage fixes it, but then runs into this bug when you try to re-enable it later. I made a stripped down mockup (bare minimum of everything, to make it easier to follow and to mess with different configurations: Instead of 2-2-2-1-3-3-1-2-2-2, it's set up as just 2-1-3-1-2 with all the engines but the radials removed for clarity), and it also exhibits the problem. Experimentation has shown that the fuel flow logic can track through either of the transitions by themselves just fine (Meaning the 2-1-2 or the 3-1-2), but can't seem to figure out how to get through both in one go. I evidentally haven't made enough posts to do attachments, or something, so I can't attach the .craft file. Here's a screenshot of the mockup as a consolation prize: http://steamcommunity.com/sharedfiles/filedetails/?id=101012978