Majiir

A plugin-based interpreter would have the advantages that it\'s self-contained and exposes a clean API. However, it has several disadvantages over equivalent C# code: [li]C# is primarily an object-oriented language. Though KSP doesn\'t take full advantage of this, it does revolve around per-object events, so you\'d need some way to elegantly script those.[/li] [li]Performance is an issue since some part events execute every frame. To optimize this you could compile a script object at run-time (using reflection, as with regular expressions) or Roslyn when it comes out.[/li] But the biggest problem, in my mind, is adoption. It\'s clear that a lot of amateur developers are having trouble building plugins, but I don\'t think it\'s because of the language. It\'s symptomatic of the way KSP classes are structured; they follow Unity conventions pretty closely, which is great for internal consistency. The problem is that Unity conventions are absolutely terrible. As a seasoned C# developer, I find the 'Unity way' is confusing, counterintuitive and problematic, so I can only imagine how difficult it must be for a beginner. In other words, a scripting interface would make things easier, but primarily because you\'d have to neatly wrap KSP in a clean, well-structured API.

I\'ve been working on this using stock parts. My concept involves using a space tug for the high delta-V maneuvers. The main ship launches into a low Kerbin orbit, and from there a tug boosts it to the Mun. After entering Mun SOI, the tug maneuvers both ships into a low/medium (<100km) orbit, burns hard retrograde to reduce the orbital velocity of the lander as much as possible, and then burns prograde again to maintain an orbit. Switch now to the lander, which has a full half-tank of fuel. In my tests, I can perform the powered Mun landing and just barely launch back to a low Mun orbit (20-25km). The tug meets up with the lander and burns on a Mun escape trajectory. (If you do it right, you\'ll be on a deorbit trajectory when you re-enter Kerbin SOI.) The tug either burns to stay in orbit or lands. Now, for a simple Mun-Kerbin mission, this is pretty inefficient; the tug is a good bit larger than a Mun lander. But when you want to go to the Mun and back twice, it looks a lot better. The first step is to minimize the design for the round-trip Mun mission, but my approach of late has been a little more demanding on the design. I wanted a decoupler below the capsule because otherwise the crew will die when doing a water landing, and I wanted an ASAS to make docking and landing easier. (I might drop the decoupler requirement since the tug can maneuver the ship into a KSC landing.) Now, step backwards. That ship, launch vehicle and all, needs to be able to land on Kerbin. That means lander legs and parachutes, and as I found out the hard way, more weight and a launch vehicle that no longer gets you into orbit. So this is where I\'m going back to the drawing board. Orbital rendezvous and docking has become trivial for me, so I\'ve been trying some trickier moves, like ballistic rendezvous and aligning launch windows for an 'instant' rendezvous. I might also try capturing a craft in Kerbin orbit and carrying it down on a landing platform. It may be possible to accomplish this without using any tug ships, but you\'d need to design a ship which can, in reverse order: [li]Land on Kerbin[/li] [li]Leave Mun SOI for Kerbin deorbit[/li] [li]Launch from Mun into orbit[/li] [li]Powered landing on Mun[/li] [li]Transition from lunar injection to stable Mun (de)orbit[/li] [li]Translunar injection from Kerbin orbit[/li] [li]Launch into Kerbin orbit[/li] ...all while carrying a ship which can, in turn, do all of those things. The delta-v requirements are high, but the landing weights are enormous. You can land a Mun ship on Kerbin pretty easily, but take that, add enough fuel to launch from the Mun and get it back to Kerbin, and then give it enough fuel and thrust to deorbit and perform a powered landing on the Mun. (Remember, no aerobraking.) So yeah, I\'m going with tugs. The total launch mass may not even increase much since the tug is responsible for a significant portion of the delta-v, but its thrust requirements are low. (My light and medium tug designs use just a single landing engine; I expect the heavy tug will do the same, as long as it\'s only performing orbital operations.)

For my purpose (landing computer) I actually simulate the water as being farther down than it really is. Coming to a near-stop at water level isn\'t so great, because then your engines shut off and the craft plunges in. I\'ve thought about making some kind of radar part which would give plugins easy access to this kind of information, but I imagine the requirements of each plugin are too different to neatly wrap them all up into one device.

If you hover over the water very near KSC, you indeed hit the ground below. When you go further, Physics.Raycast() will return false. You\'re correct that identifying a bitmask which also detects water would be more useful. To be honest, I might just raycast everything, so I can also detect landed ships.

Consider the difference between energy and power. A solar panel will generate a different amount of power based on its distance and angle to the sun, and an ion engine will consume a certain amount of power based on its desired thrust. A battery stores some amount of energy, but it also has a maximum power output (and input). I think it\'s acceptable for an API to handle these basic conversions so that plugins don\'t have a misunderstanding when making power/energy transactions. Parts should be able to draw power from each other, but energy should be internal.

Something to keep in mind is that the coordinate system has very little relation to the behavior of your ship. The position Z coordinate is not always 'up', and the angular X coordinate is not always pitch. Especially when dealing with rotations, you need to be careful to transform your vectors to something that\'s meaningful to your control system and then transform them back into something the game will recognize. (I carelessly made the Z-is-up error even though I knew better, and it took me about 30 minutes to figure out. Then, later, my SAS code worked fine until the ship rolled away from the default orientation, and suddenly it would correct for pitch by adjusting yaw. Very frustrating.)

The Raycast function returns a success flag. If you\'re casting a ray from your ship to the center of the planet and you don\'t hit anything, you\'re over water. (I\'m trying to think of edge cases where this isn\'t true, but nothing\'s coming to me.)

I used the current altitude to approximate height over water. Do let me know if you figure out the mask to detect it directly, though.

Go for it.

The problem with that example is that MyPart extends KSPPart, which in turn extends the global Part class provided by KSP. I think piling additional methods on top of that class would create unnecessary confusion. I\'ve been a bit slow to make progress here since I\'ve been toying around with reflection, but I have a revised plan for wrapping KSP classes. Each part has up to one wrapper object, which in turn wraps exactly one KSP part object. The wrapping mechanism is completely hidden from the (code) user. When an API Part object is created, the corresponding KSP (and Unity) object is created as well. When any API function returns a Part, it returns a wrapper, creating and binding it if it doesn\'t already exist. If I can get over the reflection hurdle, I think the advantages will be obvious. I might be very busy before April 1, though, so we\'ll see how much time I can put into it...

I just want to note that this is invalid code. The second line should read: if (FlightGlobals.Vessels[i] == this.vessel) {

You can do something like this: // reference this class in your part.cfg public class DodrianFlightComputerPartClass : Dodrian.FlightComputer { } namespace Dodrian { public class FlightComputer : global::Part { // put your class code here } // put other namespace classes here }

While we\'re at it, we could ask Squad to give us a more decipherable API. (It drives me nuts that there are interdependent public fields in most of the KSP classes.) In the meantime, I think building our own, well-documented API is the best solution. (Shameless pimping, I know.)

This is just a particular example of a much larger problem that KSP is ill-suited to handle (in its current state): event priorities. It\'s difficult to predict all the different types of input that parts might handle. Autopilots? Stabilizers? Some in-between? What happens when more than one part demands the helm? What if a stabilizer and an auto-lander both consider themselves to be more important than the other, and thus nobody gets helm control? Your proposed setup essentially defers the problem to a later place in the code, but the fundamental problem is still there. Perhaps a better way to solve this might be to stack modules when determining inputs. By default, there is always one entry: the player. Most plugins will probably want to give the player the last word, but some might act as stabilizers and 'soften' the player\'s input. This should be an option. An auto-lander will certainly want control, but some stabilizers might want to 'filter' its controls to soften the descent. There\'s nothing we can do to prevent poorly-designed plugins from completely interfering with others, but you can at least establish a 'best practice' where each plugin is allowed to see the inputs of each plugin which came before it and adjust as necessary. Establish some categories where plugins can register themselves. Such a framework might even warn the user when multiple high-level autopilots are mounted on the ship.

Ah, I see. For a moment I thought you had duplicated Kerbin, complete with Mun on each. Still good work, though. I would try additionally recalculating the orbit for Kerbin (around Kerbol of course) to update its own SOI.

Doooo post code!

You can retrieve an array, but I think that\'s a copy of the internal List (which is exposed as a field, not a property).

Are you sure? It looks to me like vessels hold a reference to an Orbit, which in turn has a CelestialBody. Vessels have an int for the current stage, but I don\'t see one for the planets. It seems like adding a CelestialBody to another\'s orbitingBodies list could do the trick. I\'m just having trouble properly cloning/creating a CelestialBody.

I spent some time last night thinking about an interesting design problem. Ideally, a more complete API will proxy/wrap a whole collection of KSP classes. The most important is probably the Part class. My wrapper class exposes C# events, which is certainly handy for developing a single part type. Where it really shines is when you subscribe to events from other parts, ones that you aren\'t necessarily writing a plugin for. (Suppose you want to activate a decoupler when a stage runs out of fuel; you can subscribe to the child part\'s events and listen for that state without actually modifying any fuel tanks.) So, being able to wrap any arbitrary Part is important. Here\'s the problem: KSP doesn\'t expose events. In order to make this work, parts of the underlying Part class (specifically, the event methods) need to be modified in a similar way as my Proxy class. We can\'t decompile and redistribute the KSP binaries, so that leaves us with the Dark Art of programming: reflection. I\'m admittedly a reflection newbie, but I think it may be possible to build a loader which patches the KSP classes in memory before running the game. It\'s a bit more than I wanted to do, but I think the payoff may be worth it.

Working on it: http://kerbalspaceprogram.com/forum/index.php?topic=8371.0 So far, the issue is copying/creating new CelestialBody objects. There\'s probably an internal factory class that produces these. Reflection might give us a way, though...

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