quietghost

Hmm, strange that you can load it, perhaps I have a weird bodies.ini file issue. I am using the one packaged with the tutorial. Anyway, here is a link to the screenshot. This happened after I opened a new mission, then went straight to loading my Sarnus mission, but it happens after I load any mission. Sorry for the tiny log text. Screenshot Also, I posted an edit above that seems to indicate this has nothing to do with OPM. Edit: The pre-release seemed to solve the issue. It loads fine for me too! I guess all is well then. Thanks for your help!

Forgive me if I am missing something, but I seem to be unable to load saves when the planets for OPM are involved in my trajectories. Otherwise it loads just fine when the trajectories do not involve the OPM planets. Is there any workaround for this besides replotting the mission? Luckily I have it saved right up until the final maneuver so its not too big a hassle. The specific behavior of TOT is to not show anything when the file is loaded, but in the status window it says it loaded the file with no error. I have attached the 2 mission files: the first is with a Sarnus intercept, the second is without, just in case you would like to take a look. Mission with Sarnus Encounter Mission without Sarnus Encounter Edit: I have done some further testing and figured out that it doesn't have anything to do with Sarnus or OPM, because I have created missions that will load with Sarnus in the trajectory. I have uploaded a file that works for more information. Mission with Sarnus that Works Hopefully this additional file helps. Thanks!

After some searching, I realized there was no repository of Kerbin's highest peaks. Lots of people have summited the highest peak at 6764m, but I wanted to find them all. Here is my list: A listing of the ten 6000m peaks of Kerbin Rank Height (m) Latitude (DMS) Longitude (DMS) 1 6767 61 35 54 46 20 17 2 6566 -74 23 43 -17 31 47 3 6433 -14 26 44 71 57 24 4 6432 -6 35 54 113 37 21 5 6143 -13 49 48 71 17 37 6 6142 -30 09 19 -13 27 20 7 6119 46 04 45 139 32 01 8 6067 -68 33 12 -27 13 12 9 6041 -17 12 15 73 38 30 10 6009 42 33 10 135 50 45 Please note that negative latitudes are in the southern hemisphere, negative longitudes are in the western hemisphere. I acquired the locations by pinpointing high points on a hyper-res map of kerbin, then flew to the location, landed near the summit, and placed a flag on the summit. For some reason the height of the peak varies slightly from load to load, so each value is +/- 3 meters, which means that 3 & 4 are a tie, as are 5 & 6. Screenshots If I have missed any, please put them in the comments below, complete with location information. Insofar as I am aware, this is all the 6000m peaks of Kerbin

Goodbye Felipe! Thank you for making what I consider one of the best games out there, certainly my favorite. Hope those future projects turn into near-equal successes!

Which mods do you have installed? It could be that you have too many, or maybe one is bugged. If you can list the mods you have selected in CKAN we will be able to help better

That is the 32bit memory limit, exactly. There is little you can do to fix the problem besides removing mods. Planetshine is a nasty one, but any other graphical modifications will also be RAM intensive. You may wonder where the other 0.4GB goes, the answer is that we don't exactly know, but we think it is due to system allocation processes that make KSP run with windows on a binary level. Sorry that there is currently no better fix. Ghost

My rule of thumb is that when it comes to orbital maneuvers, it is always better to burn late than early. So if you know what the angle between Duna and Kerbin should be from the tools mentioned above, a good strategy is to wait an extra day or 2 before actually ejecting. The added dV is minimal compared to adjusting the departure angle. Normally in life people say early is better than late, but in space late is always better than early

The big thing with NERVAs is that because they only use LF, there is far less mass as fuel to burn. Since dV is based on the mass of the fuel (more is better, but with diminishing returns) by the lack of oxidizer (which reduces fuel mass) there is less dV. The exact mechanism by which this happens is the flow rate for LF is much greater now, not because NERVAs were nerfed, but because previously flow rate was split between the LF and the Oxidizer. If the whole tank were just LF (i.e the oxidizer storage converted to LF storage) the performace metrics of the NERVA would be similar to 0.90. Of course they are also heavier, which only compounds the perceived nerfing.

Is this physical timewarp? (Physical timewarp only goes up to x4 and is the only option for timewarp in atmospheres) If it is physical timewarp, the reason the ships look all disjointed and glitchy is because your computer cannot handle all the physics calculations so quickly, so in essence it "skips" frames, allowing parts to separate and occasionally rip off the ship entirely. The only solution to the physical timewarp glitching is just to avoid it altogether on large ships.

No, the issue has nothing to do with your computer. It is a unity issue where the location and velocity values have only 6-7 digits of precision. At 30 fps going 2200 m/s, those errors add up to cause the slow decay. Your hardware is operating perfectly fine.

If you have any parts that were placed with radial symmetry, then the symmetry indicator will automatically switch over to radial when you mouse over with the new part. The same happens with parts placed in mirror symmetry, radial will switch over to mirror. To solve, just avoid mousing over the parts placed in radial symmetry when placing the next part.

How quickly do your orbits decay? Is it happening rapidly (like a meter from the AP/PE every second) or is it more drawn out? Floating point errors only decay orbits slowly, it would take a couple hours to decay a 100km orbit down to the atmosphere at least.

Welcome to the forums Kornet! With a clean install of 1.0.4 on the exact same distro, all the effects are applied properly for me. I think the problem is because of the updates to the thermal system and because of the broken patcher. Currently, the patcher is dysfunctional, so any updates to the thermal and AeroFX system likely went unpatched and/or are corrupted. (Edit: I also am pretty sure the patcher does not update linux 64bit anyway) What I recommend to fix the problem is: Obtain a clean install of KSP 1.0.4 from the store (or steam) Check to see if the aeroFX work there If they do: - Move all your mods over, they should be completely compatable If still no aeroFX: - There is likely an install-specific issue that requires more information about your system Hope this helps, Quietghost

Part of this bug is the result of the speed of the vessel being measured from the controlling part, not the vessel center of mass. Therefore any minor rotational changes (which happen with SAS, especially with large vessels) result in adjustments of the AP/PE. This effect tends to be more pronounced if the orbit is really close to circular. To get around the issue, if you are trying to place a manuever node, make the orbit have a small eccentricity rather than as-close-to-circular-as-I-can-get. For a manuever node, just adding some delta-V to it will solve the problem of it moving around, however small dV of <1m/s will still suffer from the movement. The other issue is with floating point errors. Overtime the errors from the maths will start to add up, and degrade the orbits. Either way, the problems can be solved by entering non-physical timewarp, which stops rotation and locks the vessel in a keplarian defined orbit which remains unchanged until you go back to 1x simulation. Hopefully I addressed this, or perhaps missed the jist? Quietghost

Mess around with the manuever planner to see what gets you closer. Make only tiny adjustments. If you have matched planes with your target, then you dont need the normal and antinormal The other option is to wait until you get closer, then plan out another manuever.