Dave Kerbin

I've not had too many problems with docking close in, and now know how to get ships into orbital position for the close approach thanks to some help on the forums. What I did find out is hard and frustrating to dock, and what is maybe making it so hard for other people, is when a ship is poorly designed for docking. I was building my station and sent up my fuel reserve tank - big orange tank with a large RCS tank, battery, probe control and Sr. docking port on one end and a poodle engine on the other, with 4 docking ports on the side and 4 RCS thrusters near the docking port (poor thinking on my part). It seemed impossible to dock due in large part to the poor RCS placement: any thrust at all would throw off the docking port position. So I finally stopped, parked it about 100m from the station and undocked my empty crew module (escape pod/station keeping craft). I flew that over and easily docked with one of the side ports on the tank. With the new combined ship I disabled all the RCS ports on the fuel tank and the reaction wheel to turn it into dead weight. I then set it to control from my command pod and used it as a tug to dock the fuel tank in just a few minutes with an almost picture perfect approach. Lesson learned, the ship makes all the difference when docking. Unfortunately I may be back there again. I was already courting trouble bringing up the permanent habitat module to the station, it is intended to dock to my center axis and has the docking port, a hitchhiker pod and a cupola module. Problems already started in that the module was 2 tons more then what my delivery system normally carries (everything so far has reused the design and testing I did for the crew module) so after a failed launch I had to add an addition fuel tank for the booster. I got to the station a little light on fuel but in good shape. Because of the cupola on top the plan for docking was a bit different - I put a Jr. docking port on the side of the hitchhiker module so it could be carried into position by a tug. My tug was a mostly untested micro ship - a regular docking port attached to a small RCS tank lined with 4 RCS thrusters and solar panels, in turn attached to a tiny probe and battery and then a Jr. docking port. This way the tug could be used to clamp and tug with either port type, and served as an adapter when docked. There have been a lot of issues trying to do the docking mission - I didn't put a light near the port so its hard to see, I can't seem to get it set as a target until I'm real close (which is an issue), and by itself the tug is so tiny that even with fine controls it whips around at the tiniest thrust. And the Jr. port is on the top, so it flys backwards if I want to use it that way (I think I can fix that with control from here).

Thanks, being able to see it at any time is even better, now I can check on G forces when testing future manned equipment.

When you crash hard and destroy your ship there is a mission report that lists things like mission time, maximum G force, altitude, etc. However up until now I can't seem to get this report when I land safely (landed or splashed down). I can click the recover button from the observation building but that just removes the ship and doesn't tell me anything. If I still have a splashed down mission open and paused (resume flight, space center and settings available) how can I end it in such a way that I get a mission report?

I passed along your advice to Ludfield. He made a micro burn to level out the orbital plane then pushed up to around 128km where he waited for just under 10 hours as his orbit got closer and closer until his next pass showed a distance of just 31km. He planned a new maneuver to bring the distance down to 3.9km and then performed a pair of retrograde corrections until the expected approach was just 1.1km. From there he switched to his RCS system - he claimed to be having trouble getting small enough burns out of the poodle liquid fuel engine and didn't want to risk overshooting. A series of RCS burns zero'd out the velocity between Ludfield's ship and the target and another burn sent him slowly towards it at a gentle 10 m/s. The remotely operated ship had already been left oriented up/down so it was a matter of getting into position above it and orienting down. Ludfield didn't have much difficulty here, having read the reports from the Krussian training mission. Ludfield is very happy, he is about to be the first Kerbal to manually dock with another craft. The magnetic clamps engage and the two ships are docks with minimal wobble. The ships are docked and perfectly aligned (each ship has 3 solar wings with a missing 4th wing providing a point of reference for the 'top' of the ship when using RCS docking controls). It has taken about 11 minutes to go from 1km to docked. A short EVA takes Ludfield over to the other ship and he undocks. His new ship has less fuel but a full tank of mono propellent. Overall the docking used around 18 units of liquid fuel about about 80 units of mono propellent from Ludfield's original ship. Ludfield uses RCS to push away before turning around and preparing to deorbit. As the atmosphere starts to drag on his ship he releases the orbital service module and watchs as it drifts away. A safe splashdown brings the mission to a close.

My space program continues as docking procedures are tested and retested for safety. My Kerbals now understand how to get ships into stable circular orbits and how to raise or lower them, and completed a milestone of seperately launching and then docking two drone ships. Further docking practice with the cooperation of the Krussians and their space station 'Scenario' have helped refine our knowledge of RCS maneuvers by moving pieces of the station to different docking ports. However one piece of knowledge that still eludes my Kerbals is getting the orbits of two ships close enough (<4km) for docking maneuvers. Despite several additional attempts the first docking success seems to have owed a lot to a lucky launch window. Currently my KSP has been developing and testing a crew launch and return vehicle - designed to be a safe, easy to fly and reliable way to launch 0-3 Kerbals into orbit, dock with a station or craft for EVA transfer, then return 0-3 Kerbals safely to an ocean splashdown while also ensuring no debris is left in orbit. Initial tests have gone well, including one test that flew straight up until at the limit of its fuel it broke free of Kerbin's gravity and entered orbit around the Sun. The administration called this a waste, but the long orbital period helped identify a critical flaw in the solar panel arrangement. Just recently the first crewed launch flew, orbited once and then returned safely with no new issues identified. That brings us to my current mission. A remotely controlled launch has already been made to put an empty crew vehicle into a flat, stable 125km orbit. Ludfield Kerman then launched in a second crew vehicle and moved into a similar 123km orbit, with the intent of docking with vehicle #1, performing an EVA, and returning in vehicle #1 while #2 is returned seperately under remote control. While an attempt was made to time the launch for an intercept the estimates where off, and Ludfield's ships is considerably ahead of the target. At this point Kerbal scientists on the ground are suggesting Ludfield make some random orbital changes and see what happens. While Ludfield has fuel reserves for several maneuvers (283 liquid fuel, about 30 needed for each 100m/s of change and about 25 needed in reserve to ensure a safe return) he has doubts about the plan (which is odd since his stupidity rating is almost 100%, though his courage is very low). So, any tips or orbital mechanics for getting craft lined up without massive fuel use or spending weeks in orbit waiting for an alignment? (Ludfield only brought a sandwich and a package of K&Ks from the space center's candy vending machine)

When you deploy a parachute (space) the parachute icon in staging turns to several colors (Cyan, Yellow, Red, Green that I've noticed so far). What colors are there and what do they mean? Can the colors tell me if my chute is weakened and will rip apart when it fully deploys at 500m?

My Kerbals have been conducting a series of proving missions in preparation for the construction of a refueling space station. This is mostly through the time honored way of trial and error. I've sort of figured out how to dock and how to efficently do some orbit changes though lift off probably still has a lot more brute force then needed. My Kerbals want to keep the planets orbit clean of debris so anything that goes up has to attach to the station or come back down. But since the goal is to get as much fuel up there as possible I want to minimize how much needs to be left behind in the boosters when I detach them and then turn them around to do a deorbiting burn. Given my engine (impulse in vaccum), dry weight and orbiting altitude what would the math be to figure how much fuel I need to add to make a deorbiting burn at the apoapsis (I assume this is something "Delta V" related). My Kerbals aren't really concerned where the debris crashes since the planet seems to be nearly devoid of any settlements beyond the KSC.

I previously assumed that career mode would revolve around completing specific missions like orbiting a satellite or landing on the Mun with the option to repeat them in some way for smaller gains, but what you’ve described sounds much better. It seems easier to create a wide range of goals and much more balanced for allowing sandbox like pursuit of the players own goals. If I understand what you’re proposing it is to have instruments that each ‘collect’ a specific science ‘resource’, with instruments some having a limited use count before they are worn out. The resources are not infinite but also get used up in the process. Cities XL has a resource system like this – you need things like water and oil and each map has an overlay showing which parts of the map have it (in KSP it would be hidden). When you place a water tower it takes a circular bite out of the overlay, so you can’t just place water towers side by side. From the technical side it’s just a 1 bit map of yes/no values, and placed structures mark a point and radius where the resource is already collected. Attempting to collect anything either on a grid section marked 0 in the map, or within the radius of a previously ‘mined’ point fails. Better instruments might take a larger bite. I assume this would work even in the planetary nature of Kerbal – each planet, moon and the sun has a map for each type of science resource they contain. Either the map or the instrument has altitude parameters – you need to be right on the surface to collect rocks, while others require a certain altitude range, like between 70km and 100km to gather from a magnetic anomaly map. Once a resource is ‘collected’ you aren’t instantly turning it into science. Instead there are path(s) by which an entity can convert units of one resource into units of another resource, until eventually you reach the Kerbal Space Center where the R&D building has the conversions to ‘Science’. For example we could land on Duna and use our remote rock collection device to collect 1x ‘Duna Rock’ resource which weighs 1.0t. We can pack that on our ship and fly it back to KSC where we can convert 1x ‘Duna Rock’ into 100x ‘Science’ to spend on the tech tree. Alternatively if we send Bob Kerman on the mission he can be commanded to ‘sort’ ‘Duna Rock’ resources (there are things Kerbals do better then a machine), converting 1x ‘Duna Rock’ into 1x ‘Sorted Duna Rock’. Both can be returned to the KSC to be converted into 100x science, but ‘Sorted Duna Rock’ only weighs 0.1t. Finally we have a third option – we can pack a ‘mass spectrometer’ part on our probe. With this tool we can convert 1x ‘Duna Rock’ or 1x ‘Sorted Duna Rock’ into 5x ‘Duna Rock Information’. This resource weighs 0.0t (nothing), which means we can transmit it through an antenna back to the KSC. However the conversion between ‘Duna Rock Information’ and ‘Science’ is only 1x for 1x instead of 1x for 100x, so we get a total of 5x ‘Science’ for breaking down the rock and transmitting the information back by antenna, vs 100x ‘Science’ for actually bringing it back for complete study. Finally I assume we will have antennas with different efficiencies – the rate at which they can send weightless information resources back based on the size of the antenna (or really an in game value shown in the part description) and divided by the distance (longer distance means a slower data rate to ensure everything is received). So the little antenna we have right now might be perfect for sending back just about anything from Kerbin orbit, but on Duna the distance factor would dramatically increase the time to transmit just 1x resource back to KSC. For this you would want a larger Duna base station with a big transmitting antenna. Your little rover transmits the information resources to the base station (short distance so the antenna is still fast), and then the powerful base station antenna sends it back to KSC. The antenna efficiency becomes really important if there are practical limits on just how slow you can send, preventing the exploit of just time warping. The realistic but computationally harder approach is that transmissions require line of sight to the receiver (parts and other small scale objects don’t block LoS, just planets), and each resource unit can only be transmitted in full. That means that if the efficiency has dropped to the point that it takes 5 minutes to send 1x resource then you must have a LoS window of at least 5 minutes to send it. If LoS is broken the transfer has to start over again. A probe on the dark side of the Mun would need an orbiting relay to send information back to KSC, and a probe on Duna must transmit fast enough to complete at least one transfer before Kerbin rotates out of view.

Thumbs up. I can understand when doing 'far' switching that the target is lost for the time being, as you're basically unloading one instance and loading up another, but when doing close range [ ] instant switching the target should be retained.

First of course this is a great idea - as a programmer I was thinking of it myself and went searching to see if someone had already done it or started a conversation. With regard to automation I think that is part of the point - I'd love to be able to design a 'program' to go along with my unmanned orbital refueling stations to cover the mundane task of putting a few up in proper orbit and then deorbiting their upper stage. Different people play the game differently, and I happen to be one of those that likes the design and planning part but don't get as much out of the basic flight tasks once I've mastered them. I think this would be a more 'realistic' alternative to MechJeb which I've tried and found both 'cheating' a little, but at the same time worse then doing some actions manually because it wants to do them in its own way. I like to feel that any failures are because I made a specific mistake which I can then find and fix, and failures like a well tested rocket using ascent assist going out of control is much more frustrating because the reason for the failure is due to some buried code in MechJeb. Language wise I think using a BASIC dialect would not only match the flavor of a 60's space program, but also make it easy for non-programmers to learn and use. Strict old-school BASIC is also somewhat drag and drop friendly in the way each statement is easily identified by a keyword instead of by inference. There are some challenges with an in-game language. You've already got one of them, which is how to 'name' parts and objects for reference in code. You want it to be simple and straight forward, but still cover everything. Consider what happens when you dock spacecraft together to form a larger ship or station; You might even launch duplicates of the same craft file, like standardized orbiting fuel depots, which are then joined in orbit to create a super depot. You might also want some form of reflection that allows a program to dynamically locate a part or parts. For example DPort(#ship) would give you the first docking port part inside the #ship part tree, while DPorts(#ship) would return an array of all of them. Another challenge is with the limitations of how KSP works - to optimize performance objects outside a certain range or above a certain time warp become simple inert masses. For practical purposes a ship stops being a complex system of working parts and instead becomes a one step orbital mass equation as soon as you go to the space center or another ship. For example if you wrote a program that turned on some running light while solar power is at zero (ship is in the dark) KSP would only be able to execute it you where directly viewing your ship at 1x or low warp (I'm not sure of the exact warp steps where part function and part existance stop being simulated, based on the atmospheric warp restrictions I'd say it is 4x or less). I think this means that any program would need to be something with a defined start and end, or at least the ability for the player to 'stop' a running program. A running program would be treated in a manner similar to the ship being throttled up - you can't warp and you can't switch to another object, which puts some serious limitations on what programs can do. Since very near objects do getsimulated it could be that a close enough objects can be 'remotely' commanded by your ships program.