CaptainKipard

I'm going for efficient, not easy. It'll come in handy when career mode arrives. Hmm. Well I'm looking straight down on KSC and Minmus orbit looks tilted right, so it's orbital plane is at 96o relative to kerbin north right now. Surely that means I must head towards east +6o and not -6o right? That's a minor detail anyway. At least now I know when to launch. You and HoY get rep for answering, because it's not a very easy question.

Go into your settings.cfg in your main KSP folder. Change CONIC_PATCH_LIMIT to 5. Any more than that and you'll start getting performance issues.

Using quantum struts at docking locations will eliminate almost all of the wobble, even with SAS on. I keep my station parallel to kerbins rotational axis this way without any problems.

So i plan on visiting Minmus a lot, since it's a prime location for mining pure green. Can I save some delta-v by matching minmus orbit during insertion without having to do any (or much) correcting after I establish a parking orbit? If so what do i need to do in order to match the inclination and longitude of the ascending node of minmus? I'm guessing I have to launch at a specific time and yaw/pitch towards the right heading, but I don't know exactly. Thanks for helping.

So those converters on your tankers are single use disposable? Fatherman away...

I'll let better players answer the maths question. Let me just suggest a mod called "engineer redux" to you. If you don't actually want to calculate all of this it'll give you a comprehensive readout of delta-v, mass, thrust to weight ratios, thrust (in newtons), amount of time available while thrusting at full throttle, specific impulse, cost. All of those are available for individual stages as well as total. You'll be able to judge at a glance if you can get somewhere. With it you'll even be able to quickly design rockets that don't leave any debris in orbit, without actually testing your rocket in flight. And remember more fuel and more rockets doesn't necessarily mean significant increases in delta-v

<Flies in> You wanted a one-click solution for your kethane woes? Here's one I just tested. The only downside is you have to sacrifice a little delta-v on your tanker. I re-read the OP of this thread and got to thinking. It's true LFO doesn't behave like monopropellant.... but kethane does . 1. Build a rocket/rover with a drill, a kethane tank and a KAS port. No need for anything else, no even a radial atachment point. In action groups assign "deploy drill" to 1. You could do "toggle" instead but it might get complicated later on if you want to plug in more than one tanker. Having a key for "everything on" is better. 2. Build a rocket/rover with an LFO tank, a converter and a winch (i still have mine on a radial attachment point for convenience). Nothing else is needed. Not even a kethane tank. In action groups assign "activate fuel convert" and "activate oxidizer convert" to 1. You can decide your own ways of switching things off. 3. Fly both craft to your destination 4. Connect your craft using KAS (in docked mode again I guess) 5. Press "1" 6. ? 7. Profit! The converter draws kethane from the tank on the other craft and fills it's own tank with precious LFO. No need for fuel lines! Captain Kipard......AWAY!

Can I manually add a kethane deposit under the KSC for testing purposes?

Yes, what's even better you can take advantage of another crafts solar arrays without having to manually transfer electricity. It might be faster to transfer it manually though. This brings up an interesting point because every resource flows freely through a docked KAS cable except LF and O. Xenon and monopropellant fill up every tank at the same time that they're created by a kethane converter. Electricity also fills up one crafts batteries while it's being created by panels on another craft. But LF and O have to be transferred manually. Is this a bug or a limitation?

Well something's definitely wrong here. I just loaded my game and I realised that the LFO tank isn't actually filling up, which is weird because the RCS tank fills up just fine and I've also used the same setup to fill a xenon tank on a different test craft.

Let's see. 1. I'm using KSP v. 0.2.02, KAS v. 0.3.1 and Kethane v. 0.6 although my setup worked with 0.4.4. 2. My tanker is using a KW rocketry SC-2 LFT. I don't see why that would change anything but it's the only significant difference I can see from your screenshots. 3. Does your converter (is it a rover?) have any partially empty LFO/RCS/Xenon tanks? It might be filling those first like I said. I can't think of anything else, but if you upload your craft files somewhere I can see if it works on my computer and whatnot. If you do then remove all the extraneous mod parts first.

For the sake of clarity I think he means periastron, as in "astron"; the greek for "star".

Ok. This is the tanker. The attachment point sits on the LFO tank. Only the winch is connected to the radial attachment point node. The port sits on the attachment point surface and is unused but it's there anyway just in case. This is the drill/converter. The radial attachment point sits on the converter unit. The converter is sticking out through the winch there. When i built the rocket I didn't know it would extend like that when converting. Anyway there's also a winch under there connected to the radial attachment point node. It's also unused at the moment. The three ports are visible below. They sit on the surface like you said (you have to fiddle with orientation) with the hose from tanker plugged in. Here's the whole thing. In this image it's drilling, converting and filling the tanker RCS tank. I think it only does one resource at a time. Basically i noted 3 things when coming up with this. 1. The radial attachment point is fuel crossfeed capable just like everything 2. I assumed KAS works like a fuel line so I connected from the tanker to the drill/converter, and not the other way around in order to get the negative fuel usage. 3. Docked ships can exchange resources so I used the docked attachment mode. I might try other ways of doing it some other time. For now this works just fine. One thing I did notice however was that the drill/converter fills it's own tanks first and only then fills the tanker.

Yeah there's always more than one way of doing things. I can't actually help you there because I've never used .NET. I'll say this though. Whatever technique you're using seems to degrade gracefully because blocking the memory access doesn't seem to break your program. That's the reason I'm saying there must actually be a way of getting the folder without being so intrusive.

I have successfully used KAS with kethane. I have a drill/converter on one rocket and an empty tank on another. I can drill, convert and fill the tanker all at the same time. Here's my setup: Tanker has: LFO/Xenon/Monopropellant tank --> Radial attachment point --> KAS Vertical Winch --> KAS Connector Drill/converter has: Converter --> Radial atachment point --> 3 KAS radial connector ports I just attach the connector from the tanker to one of the ports on the converter craft in docked mode and when i click "convert" it fills my tanker.

You didn't understand what I wrote. The infuser is making my firewall complain about direct memory access when I click to choose the folder. You should be able to program it in such a way that it doesn't need to access explorer.exe in memory, and still make it work the way it does, otherwise it just looks suspicious.

This mod is exactly what I was looking for. I use it on all my rockets to mark the port, starboard and dorsal sides, which is very often useful for delicate RCS maneuvers, plus it just looks pretty. Thankyou.

Great stuff, glad I could help. Also is it really necessary to access explorer in memory in order to choose a folder. I seems like you should be able to do it without that. Makes your infuser look kinda suspicious.

Just for the benefit of the fork developers, the current quickfix posted in this thread works for me with three minor problems: 1. I once found that one of the hinges on an in-flight craft decided to rotate 180 deg between games. 2. None of the parts have working collision meshes. I've looked through the dae files with notepad and it's as if every mesh with id node_collider is simply ignored, and if it's called something else (like node_collider2 for example) it's drawn like the rest of the mesh. 3. Textures look darker than in any screenshot I've seen. It still functions like it should though.

Thanks for this plugin. It seems to work just fine on 0.2 however I'm having a little problem with the infuser. It works great for most things however when I try to pick the B9 parts folder, I'm not seeing every single part in the generated list. Could it have something to do with the fact that B9 parts folders have multiple cfgs, or am I doing something wrong?