voneiden

It's not perfect, but contains I suppose most of the first level pages and thumbnails. 630 pages in total. https://dl.dropboxusercontent.com/u/17806420/13-08-18-kspwiki.zip [20 megabytes]

I can try to help you out. Backups of the wiki are not public (and I sure hope there are proper backups this time..), but I can still try to come up with something.

Neat! It's a small world full of funny coincidences. The conics mode switcher is definitely something Squad should implement in the vanilla game IMO sooner or later. In any case you're most welcome to contribute to this project too (source is on github) if interested!

WinRAR. I think this has happened before. I'll use something else in the next release. I send the author a private message concerning the matter. I wont copy other peoples ideas without their permission. Well, except for MechJeb, I don't mind copying the node snapping from them since they copied ( knowingly or not ) the patched conics switcher from here. Currently most of my programming efforts go towards KSP Mission Control tool, so maneuver node improvement updates might come a bit slow. I'll make a thread on the KSP Mission Control in the near future for those curious to discuss about it.

Released a hotfix that hopefully addresses the issue people were having when switching ships in the map view! Thanks for the feedback everyone, it's always appreciated. Edit: I haven't tried the maneuver planner in MechJeb2, but I imagine so - both plugins provide similar features. I did check their source code though, and it seems they have few extra buttons that allow quick placement of the node to various places on the orbit (ascending/descending nodes, apoapsis/periapsis?).

Did you try ticking the "Keep open" toggle button? When you interact with mouse clicks, KSP closes the maneuver node gizmo sooner or later which in turn hides the node window unless the toggle is set. Oh, that might make sense. I'll do some debugging and see how it reacts to changing vessels.. Thanks. I have a tutorial in my signature which deals also with finding the correct position for the ejection node without knowing anything about the correct ejection angle. I'll keep this in mind though.

Doesn't the lambert solver exactly solve a non-planar transfer? Could "Ejection inclination" be the information you're looking for? E: Of course you still need to figure the right launch angle and time of launch yourself to be able to get on the correctly oriented parking orbit.

NOTE - Check out superseding plugin PreciseNode by regex About Maneuver Node Improvement plugin exists to assist in carefully designing maneuver nodes and dealing with their slippery nature. With the the plugin you can easily cycle through the available nodes and edit their attributes either with the help of keyboard or mouse. Originally released somewhere around 0.17 I guess, I have not updated this plugin for a while. The new version adds buttons to enable mouse-only usage, buttons for changing patched conics mode, and a toggle switch that will allow you to edit the previously active node even if the bloody Gizmo closes. Try not to double-click too much, or you're going to change the camera focus to something else. I also realize(d recently) that MechJeb sports a very similar tool, Maneuver Node Editor. If you already use MechJeb, you might prefer that one of course. I haven't checked it out, but there are probably some differences. Quickstart The key you use to cycle through maneuver nodes is by default O (as in Orange). Pressing this key opens the last node you had open before it closed. If no node was open before, it opens the first node in the node list. If a node was already open, it opens the next node in the list. So if you accidentally close the node you were editing, just hit O to bring it back open. Using the window, you can adjust the universal time when the node happens. Pgd stands for prograde (green buttons on the node gizmo), Rad stands for Radial (blue buttons on the gizmo) and Nml stands for Normal (purple buttons on the gizmo). You can edit the node values with your keyboard or by using mouse. If you use mouse, you should tick the "Keep open" toggle to ensure that the window doesn't close when your node closes (KSP feature, no can do!). There are four buttons: -, a number, + and S. Use - and + to adjust the number. Use S to flip the sign of the number (positive/negative). Click the number to add it to the node. The window also displays total Delta V required for the node and you can quickly change patched conics mode. Changing patched conics mode is very useful when you're trying to create an accurate encounter. You can set camera focus on the destination planet and change the conics mode to help you visualize the encounter. Screenshot Download Download from Spaceport! Source code

It's how computers often display really big numbers. 1E+09 means 1 * 10â¹ 10â¹ means 10 * 10 * 10 * 10 * 10 * 10 * 10 * 10 * 10 = 1 000 000 000 1 * 1 000 000 000 = 1 000 000 000 which is a rounded up version of your 999 999 999. Physics should handle it just fine as long as its just the maxTemp and crashTolerance. If you put it in maxThrust on the other hand.. not so sure about that!

Howdy folks, I've been gone for a while and I noticed my account lost all messages except the very first one I wrote, heh heh. I had an interplanetary Hohmann transfer guide written about one month ago, which I'll be restoring here as soon as possible. I'll be doing some proper formatting, for now it's just almost copy and paste from Google Cache. Some users provided some excellent feedback in the previous thread but unfortunately I lost it. Google Cache still shows Francescos tip: day/night terminator line can be used as planetary prograde/retrograde visual guide. Anyway, I'll work on this tutorial in the coming few days. ORIGINAL POST BELOW 1st April 2013, 17:38 There has been recently quite some questions about how to do interplanetary transfers properly and reliably. This tutorial focuses on Hohmann transfers. The tutorial explains the basic terms and goals, brief theory and provides two case examples: Kerbin-Duna and Kerbin-Eeloo Prerequisites: Ability to reach parking orbit with a vessel suitable for interplanetary travel Basic understanding on maneuver nodes Stuff to make life easier: Kerbal Alarm Clock (http://forum.kerbalspaceprogram.com/showthread.php/24786-Kerbal-Alarm-Clock) Maneuver node improvement plugin (http://kerbalspaceprogram.com/maneuver-node-improvement/) ksp.olex.biz (http://ksp.olex.biz/) or http://www.eiden.fi/ksp for phase angle data Smart A.S.S. of MechJeb. Don't warp through a sphere of influence change. This causes inaccuracy in your trajectory. Terms Picture 1: Basic terms explained. The picture shows a basic Hohmann transfer trajectory (dotted) between Kerbin and Duna. Position of Duna is shown at departure and arrival Apoapsis - The highest point of your orbit Periapsis - The lowest point of your orbit Prograde - Forward motion. Planetary prograde is counterclockwise motion when viewed from above. Retrograde - Backward motion. Normal - A normal points always up from the current orbital plane in prograde motion. (Down in retrograde) Anti-normal - Opposite of normal, this one points down in prograde motion. Transfer angle - This is the angle that the vessel travels between the departure and arrival point. In case of Hohmann transfer, the transfer angle is always 180 degrees. This means that whenever you plan a Hohmann transfer, the apoapsis of your trajectory should be exactly on the other side of Kerbol (the sun). Phase angle - This is the required angle between your departure planet and arrival planet at the time of departure that leads into a 180 degree transfer angle on arrival time. You can use various plugins to find out the phase angles. For example MechJeb shows them. So the first step of doing a successful Hohmann transfer is to know either your correct time of departure or the correct phase angle for the departure. Most of you probably are aware of a handy online tool ksp.olex.biz (http://ksp.olex.biz/). However I remind you, that this tool gives an average estimate for the correct phase angle. The phase angle is not a constant. It varies, depending on the eccentricities of the orbits of the planets. In case of Kerbin-Duna, the phase angle varies each year between 36-54 degrees. ksp.olex.biz gives a rough mean value of 44 degrees. If you always use this mean value, you'll end up with transfers that are not 180 degrees. You might encounter your destination earlier or later and your apoapsis is going to be higher than the destination too. It's doable, sure. But you're spending extra fuel. Kerbal Alarm Clock (forum.kerbalspaceprogram.com/showthread.php/43666-Kerbal-Alarm-Clock) is a handy tool for knowing the exact time. It will also in the future likely feature more accurate phase angles. These phase angles can be found from http://www.eiden.fi/ksp and used manually. The case examples in this tutorial rely on the accurate phase angles. Burn times Picture 2: Typical burn points illustrated. Departure (ejection burn), midcourse correction burn, and arrival (capture burn) Any planet can be reached easily with two maneuver nodes. In the departure burn you burn prograde. In the midcourse burn you burn prograde/retrograde as required and normal/antinormal if the destination planet is inclined. There is no need for radial burns, which are a waste of fuel. Instead of radial burns, it is vital to get the ejection burn and it's angle correct, which will be explained further in the case example. As you already saw in Picture 1, when you fly between two planets in a hohmann transfer, you don't fly straight at the destination planet. Instead, your transfer orbit is simply an ellipse, where the apoapsis is at your arrival and periapsis is at your departure. Below is a small animation to demonstrate how the transfer looks like when put in action. Picture 3: Kerbin-Duna Hohmann transfer orbit (http://i.imgur.com/mcJWDwX.gif) Case 1: Kerbin - Duna Alright, lets fly to Duna! I head over to http://eiden.fi/ksp/phaseangle-Kerbin-Duna.txt and pick the first Kerbin-Duna transfer window: UT 5087930s Phase angle 36.55 degrees. Now, to get to the right time, you can either fast forward to the right time with the help of Kerbal Alarm Clock, or open up your save game's persistent.sfs, find the line that reads UT = somenumber, and change the somenumber to 5087930. I did that :-) Don't do that if you have other important flights going on. Picture 4: Game loaded at the right time. MechJeb reports a phase angle of ~36.548. The game is now loaded at the right time. MechJeb reports the same phase angle as the text document, so we should be good. Set Duna as your target. The first step now is to determine the direction of planetary prograde and retrograde. Since all planets in Kerbal Space program orbit counterclockwise, the planetary prograde direction is also always counterclockwise. Picture 5: Kerbin zoomed out to show the blue planetary trajectory. You can zoom out to bring the planetary trajectory line visible. Try to memorize the direction of prograde motion before you zoom back in. Picture 6: The two escape directions. So, since we want to fly to higher orbit (to Duna), we want to launch in the planetary prograde direction. This means we will be departing Kerbin much faster than Kerbin itself is flying, causing us to meet up with Duna on the other side of Kerbol. Picture 7: Start by eyeballing a decent location of the departure maneuver node. Then pull the prograde marker on the maneuver node plenty. Picture 8: Keep pulling it until your apoapsis reaches the trajectory of Duna. Picture 9: Now zoom back in. Notice how we are not ejecting parallel to planetary prograde anymore? We need to correct that by moving the maneuver node slightly clockwise. You can drag the maneuver node from the middle circle. It's a bit difficult and probably quite shaky, but just try. Alternatively use the Maneuver Node Improvement tool to adjust the time of the node. Picture 10: Got it! Picture 11: Zoom out again, and adjust the maneuver node again like in Picture 8. If you're lucky, you get an encounter. (In case of Duna, you should) Picture 12: Next step is to place a midcourse maneuver node. You can do this now, or you can do this after your departure burn, up to you. Choose roughly a good middle point of your ellipse, like in Picture 2. Picture 13: Now begins the fun part. Change your camera focus to Duna, and use the maneuver node plugin to change Conics mode from 3 to 0. You should now see how the encounter looks like up close. In this picture, it looks like the red trajectory passes far below Duna. Picture 14: Pull the midcourse maneuver node normal/antinormal to bring the trajectory roughly level with the Duna system. As you can see, it only took 7.8m/s of delta-v. Picture 15: Add a tiny bit of prograde and bang! Looks perfect. You might wanna go even lower, but it might be easier to do that burn after entering the sphere of influence of Duna. Case 2: Kerbin - Eeloo Kerbin-Eeloo is slightly more complicated because Eeloo is a highly inclined planet. This time you really need to use the midcourse maneuver to even get the closest approach markers to appear. As with the Duna example, I chose the first date on the http://eiden.fi/ksp/phaseangle-Kerbin-Eeloo.txt list. Now this date is slightly tricky because Mun is aligned just so that it's sitting in the way of a prograde departure. So take care or depart slightly later. Picture 16: Funky angle. Proceed as usual, apoapsis to Eeloo trajectory Picture 17: Looking from the side we can see that we are far off.. Picture 18: So place a midcourse node Picture 19: Crank it until we get an intersection and the closest approach markers appear. Now how are we going to get an encounter without radial burns? Picture 20: By tweaking the ejection angle. This is the difference between departing now and.. Picture 21: Departing 20 seconds earlier. This does place pretty rough requirements for the ejection angle to be correct and the timing becomes very critical. Picture 22: Finally by tweaking the midcourse node tiny bit like in the Duna case you can get something similar to this. Discussion Correct ejection angle ensures there are no requirements for radial burns in interplanetary transfers. Correct phase angle ensures that there is no need to overshoot the destination. Feel free to ask questions in this thread and I will try to answer them and perhaps integrate with this guide.

The post below is based on assumptions. Feel free to correct me if I'm guessing wrong. 1) I can't verify this, but to me it seems aerospike part config file does not define the breakingTorque - this essentially means that Kerbal uses some default value for breakingTorque. The landing legs cause some torque on the aerospike, which I suppose, if the default value is very low, can make the aerospikes prone to tearing off like that. Might be a bug. 2) When under time acceleration, physics are not simulated. Not a bug. The next version 0.17 will feature (was it up to 4x?) physical time acceleration. This means also that you cannot switch crafts when flying in atmosphere, because the engine simulates precise newtonian physics only for the active vehicle (and its debris?). Other orbiting crafts are simulated simply through calculation of orbital elements. The reason why physics is not actively simulated, especially under time compression is basically a performance issue. If under 2x time compression you wish to maintain same mathematical accuracy as under normal game speed, you need to compute twice the amount of calculations during a given time. This might be still possible, but what about 100x time acceleration? If the computer can't keep up, one has to give up on mathematical accuracy. This quickly leads to unstable orbits that end up being hyperbolic. Bug reports go here