Majiir

You\'d need to modify the SolarPanel module to extend the LandingLeg class. This should work cleanly as long as the SolarPanel class correctly calls the base event methods.

Yes, but like I said, the scene sometimes resets. There\'s probably a way to consistently run some kind of initialization code, but I haven\'t played with it too much yet.

Here\'s a trick I\'ve used to do this: leave a bit of fuel in your engine/tank stages. When you\'re about to jettison them, point your ship retrograde, throttle up and jettison them quickly. If you do it right (the necessary thrust depends a lot on the design of the stages) they\'ll collide safely and continue to burn straight. At high altitudes, it\'s easy to completely deorbit the stages.

Working on it! No luck so far, though...

BLOOD FOR THE BLOOD GOD! http://i.imgur.com/6jsO4.png

// These are only guaranteed when you\'re in Kerbin orbit (or on the launchpad) CelestialBody kerbin = FlightGlobals.getMainBody(); CelestialBody mun = kerbin.orbitingBodies[0]; Orbit ko = kerbin.orbit; Orbit mo = mun.orbit; kerbin.rotates = false; // You can change rotation speeds, too /* If the Mun comes too close, it actually sucks you into its SOI * even if you\'re landed on Kerbin. This value is a bit extreme, but * it keeps us on the safe side. */ mun.sphereOfInfluence = 0; // Bring the Mun to us! mo.semiMajorAxis = kerbin.Radius + mun.Radius + 80000; mo.semiMinorAxis = kerbin.Radius + mun.Radius + 80000; /* Use a try/catch block because otherwise this method throws an * exception and the rest of your plugin can\'t execute. */ try { mo.RecalculateOrbit(kerbin); } catch { } [EDIT] This is why it\'s a good reason to keep your orbit at least as high as the radii combined: http://i.imgur.com/k74du.png

It depends. If your scene persists (because you still have a ship in it) the Mun will stay on its new orbit. However, if you remove all the ships and then launch one, it resets. I\'m sure there\'s a way around that, but I haven\'t bothered to find it yet. I just used the part loader to hook onto the onPartActivate event. From there, it\'s actually pretty easy to get access to the celestial bodies. (You can look at what your ship is orbiting, or get a list of all celestial bodies from the FlightGlobals class, etc.) Modifying the orbits is less easy, and I haven\'t yet had any luck adding a new Mun... but I\'ll keep trying!

A picture is worth a thousand words—or in this case, screams: http://imgur.com/a/5AqUY

To a part? Probably not. In order to create a celestial object with its own sphere of influence, you\'d need to do some pretty wild reflection voodoo.

I\'ve started on a primitive API as a proof of concept. Here\'s the source for the test plugin I made: using System; using KerbalAPI; // This is the class in the part.cfg file public class SabotageProxy : Sabotage.Proxy { } // This is where we put our code public class Sabotage : Part<Sabotage> { public Sabotage() { ActiveUpdate += MyUpdateHandler; } private void MyUpdateHandler(object sender, EventArgs e) { Explode(); } } On the surface, this might not look any better (it might even look worse) than the equivalent plugin using the standard API. There are a few important differences, though, and this method has a great deal of potential. Note that the Sabotage class does not extend the KSP Part class. The generic Part<> class it extends is part of KerbalAPI and defines a clean interface without any Unity methods. ActiveUpdate is a C# event, and you can see it handled by MyUpdateHandler(). Explode() works just as KSP Part.explode() does, but other methods (like requesting fuel) might be improved by an API implementation. This is achieved so far without reflection. I\'d like to avoid using reflection wherever possible, though in some cases it might be appropriate. (For example, to expose public properties to the part.cfg file.) When I get home I\'ll put the source on Github and post a link here. [EDIT] Source is here: https://github.com/KerbalAPI/KerbalAPI [EDIT] I should note that this is an equally valid way to handle the event: protected override void OnActiveUpdate() { base.OnActiveUpdate(); Explode(); } The difference is basically just capitalization for now, but the takeaway is that more complex functionality can be handled by the API while exposing a useful interface for plugin developers. [EDIT] This also lets us use namespaces! ;D

You don\'t have to, but it\'ll be about a thousand times easier since there\'s no online documentation.

You\'ll see a purple marker appear in space when you\'re within 100km. I usually do orbital maneuvers until I\'m less than 1km away, at which point I do direct burns with my main engine, and then when I\'m within 50m I use RCS thrusters to position myself. This mathematical approach is good for fast rendezvous, but might there be a more reliable way to align the phases of the orbits? (Maybe put both ships into non-circular orbits so you can get timestamps for each one hitting an apoapsis, and do the maths from there?)

Will post screenshots of my dockings when I get home. Tip: top-mounted lander legs and modest RCS. [EDIT] Here we go: http://imgur.com/a/nJ9Zf

The Mission Launch two ships into Kerbin orbit. Designate one as the target ship. You may place this ship into any stable (non-atmospheric) orbit, but once you\'ve positioned it, you may not move it again. (Imagine it\'s out of fuel.) Your second ship is the capture vessel, which must rendezvous with the target, dock with it, and use its own engines to deorbit the target safely. The Challenge Do it as fast as possible, using the mission time from launch to touchdown for the target ship. I\'ve done a few docking missions by now, but I only paid attention to the clock on one of them and achieved this in about 18 mission hours. I\'ll try again tonight with time in mind and take screenshots to have better evidence. A few notes: [li]I use stock parts. Docking is not only possible, but actually reasonably easy, with stock parts.[/li] [li]The target craft can tumble out of control, so I sometimes switch control to it to stabilize it. I don\'t do any actual maneuvering on the target, so I deem this acceptable.[/li] [li]Bonus points for small retrieval craft (and launch vehicle).[/li] [li]Bonus points for retrieval from high-inclination orbit.[/li] [li]Bonus points for large/heavy target craft. (Requires more impulse to deorbit.)[/li] I also don\'t use any parachutes, solid boosters or apoapsis/periapsis numbers, but I\'m not sure if those count as verifiable challenge bonuses. [EDIT] Actually, it looks like I achieved this in under 8 mission hours: http://imgur.com/a/nJ9Zf

The large® consumers of oxygen are fuel cells (for missions like Apollo) and hydrogen- or kerosine-fueled rockets. (Hydrazine/nitrogen tetroxide is presumably what\'s used in RCS thrusters.) Having separate oxygen fuel tanks lets us do things like collecting hydrogen/oxygen from the Mun and oxygen from the upper Kerbin atmosphere. About 70% of the total mass launched is liquid oxygen, so you can imagine how useful it would be to produce it somewhere in space!

That\'s an accurate criticism, but there\'s a flipside: While difficult to maintain, a well-structured API can provide stability for plugin writers.

I toyed around with the part class loader last night. (My proud creation: a solid booster that explodes when you pause/resume the game.) There\'s obviously a lot of potential here, since we\'re essentially working with the same tools as the developers. There\'s just something bugging me about the API we\'re given: it\'s messy. I want to discuss how we (the KSP community) might develop an API for part modding that meets several goals: [li]Takes full advantage of language features (like events) and complies with common C# coding conventions (like PascalCase member names)[/li] [li]Provides a clean interface with everything we need and nothing we don\'t[/li] [li]Is useful in intermediate stages of development, not just when finished[/li] [li]Requires minimal modification to KSP itself[/li] This is no small task, so I thought some brainstorming and theory-crafting might be in order before jumping on in.

The interesting thing about ion engines is that they can consume all kinds of fuel, but the type of fuel used (and the power applied) changes the performance characteristics of the engine. (See VASIMR, especially the Variable Specific Impulse part.) A generic fuel system would allow engines to consume Xenon and Helium alike, but it also gives us other options, like ejecting hydrazine or kerosene from liquid tanks. I wouldn\'t sweat the precise details about what type of fuel to consume just yet. As long as it consumes some fuel, and the engine\'s thrust and specific impulse are in line, you\'ll have a balanced engine.

Forget the Kessler Syndrome. Let\'s make it hazardous to even stand atop a Mun mountain!

That\'s what I thought too, but PayPal rejected my card anyway. It seems that since the card is associated with a locked-down account, they won\'t process anything from that card, even if I give all the information (number, billing address, etc.) without logging in. I understand using other payment processors is difficult. I ran a web business for a few years, and even being based in the U.S., it was difficult to find a small-business-friendly processor.

I\'ve been trying for a few days now to preorder the game, but I\'ve had no luck. PayPal decided to put some 'random security restrictions' on my account, and I have to wait for them to snail-mail me an authentication code so I can unlock it. Since my credit card is on file with that account, I can\'t use PayPal to charge that card anonymously. Needless to say, I\'m thoroughly irritated by their overzealous 'security' system. In the meantime, is there any other payment processor I can use? Can I 'reserve' a preorder copy of KSP and get it once I work out the PayPal shenanigans? Thanks, Majiir