Padishar

Hehe, thanks. As soon as I manage to create the vertices with the correct edge angles (and get a faster machine ) I'll try putting the rest together. The cube will only be 700+ parts but the others get silly, the icosahedron will be around 1500 and the dodecahedron will be around 1800...

Mine too... Each "vertex" and "edge" piece is a separate craft. The tetrahedron has 4 vertices and 6 edges all launched on one rocket. The octahedron is 6 vertices and 12 edges, split into two launches. All the pieces are undocked from the launcher and docked together to form the correct structure. I discovered fairly quickly that I needed to be very accurate with the rotation when docking the second vertex (I use NavyFish's docking port alignment indicator as it displays the port rotation to 0.1 degree) but after that was done, if I do the rest in a sensible order, they go together quite easily... Oh, each piece has around 30 - 35 parts so the total part counts of the finished craft are 308 and 642. My framerate (on this rather slow laptop) is around 4 or 5 for the octahedron at 180km and even lower for the tetrahedron because it is at 140km (and rendering more planet detail)...

Thanks for the excellent info in this thread and for the experimental evidence to support it. Great job... I am currently trying to fix some issues in the vessel simulation code used by KER. I have a station that causes the existing KER code to get stuck in an infinite recursion and this completely disables KER's simulation code until you restart KSP. There are also potential threading issues as KER now runs the simulation in a background thread and the part tree could be modified by the core engine while the simulation is running. I am also pretty sure that it isn't exactly following all of these rules, or, if it is, it's doing so in a way that is not very obvious in the code. So far I have modified the code to run the preparation phase that creates the simulation data structures in the main thread and expanded the simulation data structures to contain everything needed to run the simulation without having to access the real parts from the background thread. I have also written a handy function that dumps out the entire simulation part tree in a tree view listing all the important info about the parts. I am now trying to tidy up the simulation code to make it easier to understand and fix the recursion issues. Would you be willing to share the craft files of your various test craft so that I can ensure the simulation is as accurate as possible? Many thanks, Pad.

Yep, that's a nice way to have it visual and would also make it easy to match inclination with the slope before touchdown. It appears that getting the surface normal is trivial (Vessel.terrainNormal) so it should be very easy to add this to KER or the alternative navball mods but Squad could just add it in stock...

I'm not sure offhand if the mass of Kerbals in seats is included during flight. Cybutek may know but I'll take a look when I get a moment. I suspect it definitely isn't included when in the VAB so a way of forcing it to do so during editing might be very handy. This thread has given me an idea for another new feature. A display of the surface inclination and heading of the up/down slope would make it easier to avoid landing on steep slopes (and give you an idea of which way to go to get to a better spot). Would this be considered "too helpful" for KER? Edit: It would be pretty trivial to implement as the terrain normal is directly accessible in the Vessel object. Just needs to be converted to useful numbers for display.

Hmmm, that gives me another idea for a handy KER feature. If a we can read the normal vector of the surface below the craft (we can find the surface altitude so probably, but I haven't checked) then KER could easily tell you the angle the ground is at (and the heading of the up/downhill direction) so it would be much easier to pick a decently flat landing site.

Can you let us have the craft file? It must be a very small rocket if the mass of one Kerbal puts the calculation out by that much. I suspect there may be something else going on. Does it use a mod engine or any other mod parts?

Errr, surely you mean the low gravity makes the landing easier (assuming you have designed your lander with a sensible amount of thrust so that a single notch of throttle doesn't shoot you back up into orbit). Also, Minmus has large, totally flat areas that are very easy to hit by setting up a retrograde node that shows you coming down to slightly overshoot a flat. Then, when you are definitely above the flat, kill all your horizontal speed and just let it drop, braking as necessary. It isn't the most efficient way but the difference won't be very much and you'll still need far less deltaV than you would for Mun. To do multiple biome hits from a single landing you should try to land as close to the edge of a flat as possible so you can climb into the surrounding hills. After a few landings you should get the hang of it and try landing on less flat areas. Minmus is better for this as the lower gravity is more likely to allow you to right your ship just using the reaction wheels and/or rcs if you happen to fall over on the landing.

I think he might mean when you have attached a part using symmetry it would then let you remove just one of the set. I would also find it useful if there were various alignment features for aligning multiple parts on a parent part similar to the alignment options you get in vector graphics and 3d model editors. So you could select several parts (that are attached radially) and it would allow you to select different options for vertical and radial position. Vertical would allow to either align them by top, middle and bottom or distribute them equally in the space they occupy (top, middle, bottom, gaps). Radially would allow you to either align them all at the same radial angle or distribute them symmetrically around the parent part. This would allow you to throw parts onto your craft roughly and then ensure they are exactly lined up later. However, this would require you to be able to select multiple parts in the editor and this may not be possible (or be so difficult it is effectively impossible) without changes in the core editor code. Maybe it could use the tweakable window being open as the part being selected. Does anyone know if there is any useful documentation on the core editor interface? I have experience of writing vector graphics editors (among other things) so have quite a good understanding of the various traps and pitfalls to avoid when writing this sort of code. Another thing that really bugs me about the VAB is that you can only attach a sub-assembly to your craft by the root part of the sub-assembly. This is most unhelpful and I don't see why the sub-assembly shouldn't allow you to attach it by any of its (unconnected) nodes. It may need to re-root the sub-assembly part tree before attaching it to the main tree but there are several plugins around that can do this so it shouldn't be very hard to do it in the core editor code.

I've spent some time looking into this now and my conclusions are as follows: 1. The code that calculates the deltaV (runs a simulation of burning the rocket until completely out of fuel) was recently moved from running in the main thread to running in a worker thread. 2. If there is a problem in the simulation code then it can get stuck in a state where the simulation didn't complete successfully and new simulations do not get run because the plugin thinks the previous simulation is still running. 3. My problem where it hanged when displaying the vessel tab (in 0.6.1.5) is caused by the simulation code getting stuck in an infinite loop. When this was in the main thread the whole game locked up but now it is in a worker thread the rest of the game continues (but the simulation never finishes and never gets run again because it is already running). 4. I believe that various issues where it stops updating or rendering the window properly are caused by an unhandled exception in the simulation code triggered by a race condition with the main game code. E.g. if the simulation is busy scanning the part tree to build its own data structures (in the background thread) when the main game code makes a change to the part tree then this could potentially cause all manner of horrible bugs. I am currently in the process of fixing these issues: 1. Modify the recursive functions in the simulation code so they correctly track the parts that have already been visited so if there are cycles in the part tree (e.g. with my station where you have loops of parts docked together) then it doesn't get stuck. This will also improve the efficiency of the simulation code. 2. Move the initial phase of the simulation code that builds the data structure from the part tree to run in the main thread and only run the actual simulation (that only uses its own data structures) in the worker thread. 3. Modify the exception handling so that if there are exceptions in the simulation code (probably most likely with mods that create new types of engine and/or fuel resources) then the simulations won't be left in the disabled state. Hopefully I will get these three bits done sometime over the weekend and they will fix most (if not all) of the major issues. Then I'll submit the changes to cybutek for hopeful inclusion in his version. Pad.

If you are using Visual Studio then you can put the cursor on the word PartModule and hit f12 (Go to definition) and it will show you the whole class declaration (not the actual guts of the code but the data and function signatures of all the class members). You can use f12 on any variable, function, class or type name and it will show you the definition in context, e.g. if you put the cursor on the "part" of "this.part" and hit f12 it will show you the PartModule class (as that is where part is defined) and it will highlight the "public Part part { get; set; }" line. So the part member variable is of the Part class. Doing f12 on "Part" shows you the definition of the Part class allowing you to find all the handy functions...

<pedantic>Not orbiting a star doesn't mean its "stationary". Everything in the galaxy is orbiting around the galactic centre and even extra-galactic rogues are still moving (and constantly being accelerated by gravity).</pedantic>

This doesn't allow for the velocity you gain as you descend (your gravitational potential energy is converted to kinetic energy). You would need 126.7m/s to "stop" in your orbit but that still leaves you 50km above the ground. If you then fall vertically to the ground you will be going at a substantial speed and will need that much extra deltaV to actually land. This is why your number has come out way too low. I believe that for the theoretical best landing from a circular orbit you need to lower your periapsis to 0 by burning retrograde at apoapsis and then stop all your orbital speed when you are at periapsis. So, you need to be able to calculate the burn required to drop your periapsis from 50km to 0km (this is just half of a hohmann transfer so the equations are explained in lots of places) and then add the orbital speed at the surface (this needs a different equation to the above as the orbit is not circular, you will be going faster then you would for a circular 0km orbit, but it basically amounts to the other half of the hohmann transfer and then killing your circular orbit speed of 171.5m/s) . This will come out to a value much closer to the values given in the deltaV maps. In practice the actual value you will need to land is quite a bit higher than this as your burns will not be instantaneous and you generally burn more to come in at a steeper angle (otherwise mountains can ruin your day real quick) meaning you are still descending quite quickly when approaching the surface...

Some indication of who you are replying to would be really helpful...

<understatement> Stationary planets aren't actually very common, you know... </understatement>

Actually I was still using 0.6.1.5 for some reason. With 0.6.2.3 the game doesn't freeze immediately but instead gives the broken window display which stays that way until you restart the game.

Nice... Is that Jeb and did he grin through the whole process? I guess you could probably do it with a small ship attached to the end too. Set up an action group to decouple the docking port so you can time it right. May need to spin for a few revolutions to get up enough speed with more mass on the end...

I have come across what appears to be a bug in the deltaV or TWR calculations (probably deltaV). If you build a complex station that has loops of parts all docked together then KSP will hang with 100% cpu if you open the "vessel" tab. Zipped save file with "bad" station Just load it up and switch to the "Tetrahedron" craft. Then click the VES button in the KER window. This doesn't happen if the station doesn't have any engines, e.g. if you undock the RCS tanker from the station first then the problem wont happen. I guess this is some infinite loop bug either in the KER code or in KSP/Unity... Pad. P.S. The octahedron is harder to put together accurately, I need to redo it, docking the sections in a different order, so everything lines up. P.P.S. My mods (other than KER) are alarm clock, editor extensions, NavyFish's docking alignment indicator and the toolbar thing included with that. P.P.P.S. It looks like fixing this may turn out to be quite tricky (it might require some serious changes to the algorithm for scanning the part tree/graph) so it might be an idea to add a simple check based on how long the code runs, number of parts totalled or anything else that could be tested very quickly so if it does keep going for a very long time then it would just abort and show <fail> in any appropriate readouts. This should allow the vessel tab to be closed again without having to kill KSP. The framerate would probably drop through the floor while in this bad state so a flag that simply disables the calculation and the fields in the vessel tab until the tab is closed and reopened might be an idea...

Thanks for this mod. I really needed the 5 way symmetry for something and the vertical snap is also very useful. There are a couple of other features that would come in handy (for me, at least). First, a display of the angles the selected part is at (and also possibly a part which is mouse-overed). Second, some way of changing the amount that the wasdqe keys rotate the item by (possibly only the shift-keys that currently do 5 degrees). I would like to be able to accurately set angles down to 0.1 degrees, possibly better, so cycling through 5, 1 and 0.1 (and maybe 0.01) degrees for it would be ideal. I don't know if either of these is possible through KSP's editor interface. I am a programmer but have done very little C# and nothing with Unity. I've taken a look at the source for this plugin (and some others) and it looks pretty simple as long as we have access to the part angles and angle increment properties. If anyone knows the minimal setup I need to be able to build the source for this plugin and can point me at any appropriate documentation of the editor then I'd be happy to add the features myself (and maybe address some of the other issues/requests that have come up). Pad.

I saw something similar just before Christmas. Kerbal Engineer Redux is the only mod I have installed though I am running on a pretty low spec laptop (Core Duo T2600 2.16Ghz, NVidia Quadro 110M graphics, 32bit windows, 3GB RAM)... http://forum.kerbalspaceprogram.com/threads/29533-What-did-you-do-in-KSP-today?p=860980#post860980

I assume you mean for a conventional rocket/lander type of vessel. A plane (unless it is a glider or out of fuel) can be quite sloppy as it should be able to fly a considerable distance once in the atmosphere. If you use Kerbal Engineer (or something else that gives a deltaV readout) then you can set up a de-orbit burn node using an appropriate amount of deltaV and then move it on the orbit until it comes down a bit past your target. You have to account for both the slow down in the atmosphere making you drop short and the rotation of the planet (also making you drop short for the usual eastward orbit but making you go long for an opposite orbit). You can (if your ship design allows and you don't mind exploiting the lack of re-entry simulation) also keep a reasonable amount of deltaV in reserve so that you can kill off your residual horizontal speed if you overshoot the target (after the atmosphere has done most of the braking for you) or compensate if it looks like you are falling short. Just have a quicksave ready and if you miss by further than you can compensate for then reload and move your deorbit burn a bit and try again. After a number of goes you should be able to judge how far you need to overshoot to only require minimal correction. If you don't have KER then you have to be more approximate with your deorbit burn but the principle is the same, aim to overshoot by enough to compensate for the drag slowing you down and the rotation of the planet. The rotation of the planet should be the same as it should always take (very nearly) the same time to cover the vertical distance to the ground but the drag will depend on how steep your re-entry is. A steep entry will be affected less than a shallow one so the more you burn the less you need to overshoot. Edit: Doh! Multi-ninja'd. That'll teach me to go make a cuppa in the middle of writing a post.

No, a rhumb line is a course of constant compass heading, which is not what you get if you drive in a "straight" line. You can see this easily if you put a ship in an inclined orbit and keep the ship pointing prograde with the horizon on the navball horizontal for a complete orbit. You will see your compass heading change as you go around the orbit, e.g. if, at the start of the orbit you are going north east (45 deg) then a quarter of the way round you will be going due east (90 deg) and on the other side of the planet you will be going south east (135 deg). Exactly the same thing happens if you "orbit" by driving a "straight" line on the surface... The point of rhumb lines is that, in practice, you can't fly or sail in a straight line due to wind and currents etc. and all you have to measure your direction is a compass so a course that requires the same compass heading throughout the journey is much easier to do. These days, autopilot systems are easily capable of following great circle routes at variable compass headings though I believe commercial flights usually still use rhumb lines as it is easier for communicating course requirements from the ground.

That equation is based on the spherical law of cosines which has accuracy problems when the distance between the two points is very small (or very large, i.e. nearly opposite on the planet). This is a well known problem and the usual solution is to use the Haversine formula instead.

The great circle route is what passes for a "straight line" on the surface of a sphere. If you drive in a straight line in any direction you will do a great circle you just need to pick the initial direction so that you arrive at your target. This may be obvious, but, as long as your destination isn't too far around the other side of the planet/moon you can simply set the target to your destination and then steer to put the target marker on your navball vertically below the center spot. If you have to detour around a terrain feature then just put the target marker back under the center when you are past it. Edit: This is also a useful when flying planes though if your plane is stable and flies a nice straight course you only really need to set the initial direction...

Thanks, I'm well aware of all that as I thought the winking smiley, the pathetic system spec and the P.S. indicated. It isn't actually as bad as I made out, I was making a joke... I run with every performance related setting tweaked to give optimal performance on my machine (without seriously upsetting the physics by setting the time per frame too high) and have "fixed" the water rendering. While I'm not exactly happy about the performance I get on this machine, I do understand that this is >90% the fault of the machine rather than KSP. I will be getting a significantly higher spec machine soon which I fully expect to stay locked in the green with any craft I have built so far...