Tynrael

I had mine occur at about 74% reputation, which appears to fit with the distance from Kerbin speculation. In stock I believe I had my Duna missions pop up around 61% and Duna is closer than the closest to Sonnah body in NH (Laythe).

Right now I'm a very big fan of using a Nuclear tug. I think my next one will be 4x orange tanks of pure liquid fuel with 4 LVN rockets. Dock your actual vessel to it and use KIS/KAS to strut the 2 ships together and you can easily have enough fuel to bring your other ship wherever it needs to go and back home, then just refuel the tug and use it for the next mission. This is my first tug, no orange tanks but plenty of fuel. The central column the other ship docks to is pure oxidizer in case the lander vessel needs a fuel boost between missions, as there is plenty of liquid fuel. I also have a small manned ship in the bottom center to house my engineer, I decided to bring one with every long range mission so if needed they can affix spare parts to other craft or detach and rendezvous wherever they may be needed.

I've only had this issue once and it was more than just a Mun de-orbit, the velocities of every ship I had in play (6-7) was bumped up or down by several thousand dV. This happened when I updated both NH and Kopernicus at the same time. The change in velocities made me think that maybe the ships had been loaded from the persistent file and inherited the speed that they would have at that distance from the Sun (IE default config of Kerbol system), before Kopernicus might have rebuilt the files for the planets they had initially been orbiting (in an alternate system). I have a test save with probes orbiting bodies as well as in the same orbit as those bodies (IE orbiting Mun and also in the same orbit as Mun). The craft names are the orbital information, PE/AP/Velocity, so I can easily see if they have been changed at all. In a test install of KSP with just NH+Kopernicus I have not been able to break these orbits on purpose. I can cleanly update From NH 1.6.1 to 1.6.3 and/or Kopernicus 0.2.4 to 0.3.1 with any version in between and everything stays as it should. I even tried rolling back a version or two and it did not change my orbits. I can see why this issue still persists. My next test is to try updating older versions of NH+Kopernicus to newer versions on a Wednesday while standing on one foot and loading KSP onto my rightside monitor- it becomes difficult to account for all the variables. @Sigma88: I do not have any other planet or rescale packs.

I'm too lazy to do anything fancy to get to Aptur, I just escape Kerbin's SOI and then about 2/3 of an orbit around Sonnah tweak a maneuver radially to rotate to an encounter. Kerbin and Aptur are so close it doesn't take much fuel, but catching the encounter on the way back around Sonnah may take longer than you may like. TWP gives me values and of the 5-6 times I've tried to use them I was successful getting to Aptur that way once.

Greetings Distant Object Enhancement Users! If you updated to a version of DOE more recent than 1.5.5 you may have noticed that your large fuzzy flares (with the exception of Moh, 1 body) were no longer making an appearance. I tracked down the issue and the flares were never meant to be large and fuzzy (New Horizons isn't setup like your standard system)! In my image below you can see Arin which is very close to the sun had a small flare and that the further from the Sun you got, the larger the flares became- well that isn't right! This has been fixed in version 1.6.1 (thanks MOARdV!) and all of the bodies in New Horizons now have flare sizes that scale as intended. The image below depicts the changes and the final row at the bottom are my somewhat more subtle preferences.

You should always bring a Toroidal Fuel tank and wait half an hour after eating snacks before potential submersion. I am actually surprised I didn't find an edited image on the internet of a Kerbal inside a Toroidal using it like a live-saver.

That was my thinking as well, I tried some calculations of my own but the reality is that even though I scratch my head when looking at the formula the way it is now, the results are pretty well tuned and look very reasonable. Kerbin is indeed set at index 1 for New Horizons. I tried pushing a request for changes that worked for me in stock as well as NH, my first time using Github so I am not sure I did it correctly.

I believe I discovered the root cause of the missing flares and high brightness values for New Horizons. When kerbinSMA is set it assumes that Kerbin is parented to the Sun, New Horizons has Kerbin parented to a Gas Giant so this much smaller SMA resulted in rather high Brightness values which lead to clamping that negated them being set to a visible size. Adding some code to locate the body that has the Sun as its parent and Kerbin as a child (if the parent of Kerbin is not the Sun) sets the SMA to a more reasonable value. The range for Brightness changes to around -11 to +8 and any of the Celestial Bodies that are greater than 5 and would be clamped (only 4/35) are so small and far away that they would not be visible anyway. Everything looks as expected!

I was comparing the source code for FlareDraw in 1.5.5 to 1.6 and most of the changes appear to arrive at the same values or perform the same functions with just slightly different approaches using the same information. The FlightGlobals [0]/[1] are also being used in 1.5.5 where I see the flares so I'm not sure that is it. The luminosity and brightness values look like they are the same between versions (just done differently). I may try comparing 1.5.5 to 1.5.6 where there are less total changes and see if something jumps out. In New Horizons Laythe is closer to the Sun than Duna is in stock, though I do not see the flares I can move the cursor around and pick up the names when I hover over them with DOE =) I will check to see if I also see some of the inner planets, they are so close to the Sun I would probably have to have them at the right relative angles for them to show up if they do. Update: Did a bunch of debugging between Stock, New Horizons, and DOE 1.5.5 and 1.6.0. Brightness values for bodies (at the time I took them for their positions at that exact point) in Stock, regardless of DOE version range between -3.689 and 4.909. The 4.99 clamp ensures all values will be negative for the resizefactor which is THE most important thing in being able to actually see a flare (aside from it being enabled or not!). I know this is tailored for stock, and I do love the mod- it is great. Might it be possible to add a variable that can be altered in the configuration files to adjust this based on the system specs? Currently the brightness is the aspect of a celestial body that impacts how large the flare is, it being clamped at 4.99 results in 34/35 bodies in New Horizons having 4.99 brightness and also in 34/35 bodies having a resizefactor of 9.6 (because .01 becomes a very tiny adjustment to another static value. The stock planets range from 87 to 8,400). The closest direct comparison I have is Laythe in NH to Duna in Stock, the distances and size of the planets are fairly close. NH + DOE 1.5.5 --- BODY: Laythe _Brightness: 10.1437403346722 _SizeVector: -4968.3020482575 _SizeDegrees: 0.00157614408022995 Stock + DOE 1.6.0 --- BODY: Duna_Brightness: -0.948638744077973 _SizeVector: 5745.74767262817 _SizeDegrees: 0.000988599838010948 NH + DOE 1.6.0 --- BODY: Laythe_Brightness: 4.99 _SizeVector: 9.65915 _SizeDegrees: 0.00163158446547681 The 1.5.5 NH has a negative size vector, but that just means the texture is upsidedown which doesn't actually affect it and it can be clearly seen. It should probably have a magnitude greater Duna which is almost 40% smaller in size (on screen) - the SizeDegrees would also probably be a good factor to be in the calculations for the ResizeFactor. A config variable that could go in like, (brightness - 5.0f * systemScale), for the ResizeFactor could also be useful for custom systems that are beyond the stock size. The stock system had brightness ranging from -3.6 to 4.9, New Horizons was in the 2.59 to 18.96 brightness range. This hard coded value could also possibly become redundant if the SizeDegrees had an impact on the calculations. I hope that I do not come off as criticizing, I absolutely love that this mod exists and continues to be updated! The version I use also does everything I want to let me see that when my ships are in certain locations that there is the hint of something out in the vast open space. I saw this as a mystery I just wanted to dig into! It is also likely I am misinterpreting something, I just looked into this today and it is a little foreign. I tried my hand at some calculation adjustments but intelligent maths is way beyond me. Keep up the great work!

They spent 2 years on Aptur with nothing to pass the time and they (conveniently) practiced holding their breath! With their mouths open in giant happy Kerbal smiles. You may think the helmets are for breathing, but the primary function is preventing them from eating things they find during IVA. Speaking of which... I look forward to plants and other misc things being around on the surfaces.

Sold! I will add Laythe to my list of breathable atmospheres. I think the default value TR used for breathable pressure was 50, which tracks with your earlier statement. I will probably change mine to 35 to add some wiggle room beyond what is reasonable. If Serran is 45 at sea level than my desire for a photo opportunity minus the helmets at 7,200 elevation could have been... bad for their health. Thanks for the insight cantab!

I believe it is just Kerbin, Serran, and Titanus with breathable atmospheres. I think Laythe used to have a breathable atmosphere but now the wiki indicates a salt content may be responsible for that no longer being the case. These can be added in Texture Replacer configs so that you can have your helmet off when doing IVA but you also have to set the pressure levels to make the switch, I'm not familiar enough with how the pressure changes so I have mine set to 0.01. This means if I IVA on Serran at 60,000 meters I probably wont have my helmet on, but I don't know what a smart value to set would be. The default pressure setting from Texture Replacer was too high for anything off Kerbin (though I didn't try Titanus, that pressure is so high it would probably have worked). The default configs also have Erin and Sanctum flagged but I'm not sure what packs those are from for sure.

If you have airbrakes they help a lot, it is a little more on the fuel expensive side but depending on what kind of engine you are sporting you can fire them off at an appropriate height to reduce your speed enough for drogue chutes. You can then throttle down on the engines to make the most use of the chutes and the airbrakes so they get maximized until it is safe to use the regular chutes but saving that extra fuel will be more risky and everything goes pretty quick. The added benefit is that if you land at 5-7k elevation it saves you a few thousand meters of flight on your ascent off Serran! Airbrakes by 61K, engine assist down to below 500m/s to deploy drogues, combination drogue+engine down below 200m/s for the blue chutes. In the VAB I changed the deployment settings for all my parachutes to be half the time of the defaults. Depending on when you start burning in the atmosphere to green light the drogues, your distance between greenlighting the first chutes and when you land could be 1500m or less... You will most likely want engines going all the way until you land, regardless of how your chutes get setup. If you use a mod like SafetyChuteIndicator you can more easily see when it is safe to deploy the chutes so you can more accurately judge what you should be throttling your engines to on your descent. With 3 airbrakes, 3 drogues and 9 side mounted blue chutes- I spent 1.4kdV to land the last time I went for the blue side of Serran (which means my lower throttle all the way down cost more fuel because I was scared, could probably have spent half the dV going for a suicide burn around 8-10K elevation). I have done some testing and there is a limit to how many chutes you can use and still gain any speed reduction at all so it will probably always cost a good amount of fuel to land on the blue side. Though it was mentioned that the height could get trimmed a little, a few thousand meters more of lower atmosphere would go a long way for passive speed reduction.

Thanks for the tip Malah! That does free up 4FPS for me during the countdown before it hides. For further testing I made 2 new Career games to see if the contracts or variable buildings could be causing lost FPS (as those are big differences that do not exist in Sandbox). In 1 Career save I upgraded all of the buildings to the max level and left the other as it started. If I put a capsule+flea into orbit around the Mun for each of the Career saves (far enough away that the proximity to the buildings in the Space center shouldn't matter for rendering/whatever reasons) - the one with the upgraded buildings has 15FPS more than the one with non fully upgraded buildings. That arbitrary things like this have such a large impact on FPS makes no sense to me, but it makes me want to investigate converting my save from Career to Sandbox after I have upgraded all the buildings and unlocked all the science in the tech tree.

Updated original thread. No crashes and not seeing any real errors. Regardless of the mods I see this in a minor way with a fresh install just by changing modes.

I was noticing that my in game FPS was half of what it was compared to my stock Kerbal test environment, I initially assumed it was due to my persistence file becoming larger as my game progressed but then with additional testing I noticed that it was actually due to my game being Career mode and my test environment being Sandbox. In both 64-bit and 32-bit (with openGL or directx11) I see FPS decrease 10-15 from Sandbox to Science and an additional 10-15 from Science to Career. On average I see Career 25FPS lower than Sandbox with the same vessel. In un-modded it is hard to say that this is also happening 100%, but it appears that I am seeing a decrease in FPS for stock but the range from Career to Sandbox is only 4-5FPS. Does anyone else experience this, or have an idea why mods may affect this by about 500%? [TABLE] [TR] [TD=bgcolor: #d9ead3]AnomalySurveyor (Contract Pack)[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Astronomer's Visual Pack[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Better Atmospheres[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Better Time Warp[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Chatterer[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Chute Safety Indicator[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]CollisionFX[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Contract Configurator[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Contracts Window +[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Custom Asteroids (for Better Atmospheres)[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Distant Object[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]DMagic Orbital Science[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Editor Extensions[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Enhanced NavBall[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]EnvironmentalVisualEnhancements[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Heat Management[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Hot Rockets[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Infernal Robotics[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Kerbal Alarm Clock[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Kerbal Attachment System[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Kerbal Engineer Redux[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Kerbal Inventory System[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Kittopia Tech (for Better Atmospheres)[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Kopernicus[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]KW Rocketry[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Navball Docking Alignment Indicator[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3, align: center]New Horizons[/TD] [/TR] [TR] [TD=bgcolor: #D9EAD3, align: center]New Horizons - Custom Cloud Layers (above link- all planets minus Kerbin)[/TD] [/TR] [TR] [TD=bgcolor: #D9EAD3, align: center]New Horizons - Stock Planet Overhaul (new textures for original planets, see above link)[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]PlanetShine[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Precise Node[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]QuickGoTo[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]QuickHide[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]RealPlume[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]SCANsat[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Simple Science Fix[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]SmokeScreen[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Soundtrack Editor[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Stage Recovery[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Stock Bug Fix Modules[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Stock Fuel Switch[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Surface Lights[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]TAC Fuel Balancer[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Texture Replacer[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Transfer Window Planner[/TD] [/TR] [TR] [TD=bgcolor: #d9ead3]Waypoint Manager[/TD] [/TR] [/TABLE] 32-bit Output: output_log.txt

I have seen several Threads about launch clamps following rockets into space, it sounds like there is a bug in the tracker that may be tied to the launch clamps being over the edge of the launch pad. It also sounds like some people experience this even if their craft is within those limits. http://forum.kerbalspaceprogram.com/threads/117344-Launchclamps-crash-into-rocket-and-follow-into-space?p=2034329&viewfull=1#post2034329

I am not seeing vessel flares either. I do notice with 1.5.5 that the planetary flares I do see change from white to color and back to white based on my orbit around another body as well. Some things I know about New Horizons that could be relevant: A) The Sun has been modified to reflect the up-scaling of the system The spacing and distances of the bodies are larger than stock C) The entire system is at a tilt relative to the Sun and not in the original horizontal plane Perhaps the flares are being eclipsed by some attributes of the new Sun settings, or perhaps some more recent changes don't play well with the larger scale of the system? If there is anything I could test or try out, I would be happy to do so.

For all versions after 1.5.5 I no longer have any flare rendering (at all) if I am using a planetary mod with Kopernicus. Tested against a fresh install of Kerbal with only Distant Object Enhancement, Kopernicus, and New Horizons. If I remove Kopernicus and New Horizons the flares return. With versions 1.5.3 and 1.5.4 I do get flares rendered when using Kopernicus and New Horizons.

Eddie, how high is your Reputation percentage? I'm up to 76% and have been getting contracts for Derso and Laythe- but LANDING tourists onto both Derso and Laythe for a combined reward of 25 reputation and 300,000 funds is not enough for me to accept something like that. 90% of my contracts are still in the Sonnah system unfortunately. I have been hoping that when I complete the "Return to Kerbin from Laythe" contract that I currently have it might open up the door for more things outside of Sonnah.

If you check out the whole NH system from the side in the mapview you can see the whole system is at a massive tilt, I think most porkchop calculations assume similar horizontal inclination for orbits and that is rarely the case with NH. I use TWP to let me know when I need to burn and give me rough estimates of the amount of dV required in which directions- it gets me 90% of the way there and saves most of the guess work. I also rarely circularize any orbits aside from my initial Kerbin one so I assume that counts for additional fussing I have to do. My Valentina has finally completed the "Sonnah System Tour", 8 other lucky Kerbals have been ferried around to plant flags on Aptur, the Mun, and now Serran! .....Valentina: "Blue shift is objects moving quickly toward you right?" <taps the pod window, everything looks very blue...> "These clouds are making it difficult to... O M G that's no blue shift, deploy the chutes deploy the chutes!" .....Valentina: "Piece of cake, was not worried for a second- would play chicken with Serran any day." Last time I panicked at 7k to deploy my chutes to land at 5k, this time I landed at 7,222! Had my blood pumping... I had to mess around with Texture Replacer configs to get the helmets off. The Serran description said it had a breathable atmosphere (so I wanted no helmets!) and it appears that in addition to the atmSuitBodies flag that it uses another setting where a certain amount of pressure is required, atmSuitPressure. I'm not sure what the pressure is here but I set it to 0.01 just to guarantee it would trigger- it could be something that gets added to the CFG already being used in the Stock Texture Overhaul CFG.

I have an observation that is missing the appropriate .craft file to reproduce because I didn't even consider saving it until now! I have been playing New Horizons for a few months and have had a ship glitch out and explode on the launch pad 1 time prior to my most recent session. I was testing a rocket by adding all the mass and some of KWs separators to the top of the rocket and when I initially loaded this at the launch pad I ended up with a scene that has been posted here earlier where the terrain is all giant planes slicing through Kerbin at extreme angles. The rocket was placed high above the launch pad, reloaded to the same location and then fell and exploded. Reverting to launch or going back to the VAB and launching again gave me just the launch pad (I only had the terrain glitch the 1 time) but the rocket would still explode 100% of the time. I was just testing dV variances based on weight for different situations and when I removed the test stage I had placed on top of my rocket everything fixed itself. The only thing that I can think of is that the bulk of my craft and mass was placed above the root part of my rocket, which is the opposite of how I build my actual ships. The separator was not placed upside-down so the bottom part of the rocket I wanted to keep would be considered the throwaway component, but I was just using it to divide a stage for dV purposes.

KSPTOT does let you load in all of the planets by connecting to KSP with a plugin, I did not have any luck with the porkchop plots for transfers however. My results were always 3-4x as expensive as what TWP would come up with- they were valid maneuvers but where TWP would give me a direct bounce to the Mun for example, KSPTOT would give me an encounter that shot out past Serran and then rendezvoused with the Mun on the way back for 3kdV versus TWPs 800 option. I do plead complete ignorance on using KSPTOT (IE I am sure it is my fault entirely) and while I meant to try the mission planner to see if it had better results I never found the time. It also did not like Aptur at all, it said Aptur had no sidereal year and a maneuver could not be calculated.

I think I am going into the probe crashing business! The trick is to use Kerbals to create a high risk high reward scenario... At least that way I would feel bad if something blew up, though I have a nagging feeling explosions may be wanted by some!! The problem with slingshots, can you work them into efficient transfer windows? I don't have a lot of experience with them myself but watching some Scott Manley he seems to be able to get anywhere for minimal fuel with them, but it takes a lot of orbiting and feels pretty dynamic and hard to plan.

If you poke around the Asset files to see what textures are being used you may find a large number of texture resources that you do not care about. Combining this with parts in the GameData\Squad location that you do not care about, you could use TextureReplacer to overwrite the unwanted textures with tiny blank textures that use bytes of RAM instead of kilo or megabytes. There are hundreds of textures used, many that I have never seen and some that exist 6-9 times as the same exact texture with different names. For a time I thought about brute force dialing in what I did not feel was needed to reduce the memory imprint by a few hundred MB so I could play 32-bit, but the reality is with mods I would still be adding more than I could free up and it would be a time intensive task to map out the textures to even see which ones I did not want. The nice thing about temporarily overwriting these files with TextureReplacer means that when the game updates you won't lose your changes, like if you manually culled the Squad folder. I never use IVA for example, I currently overwrite those textures and all of the stock planets (I'm using new textures for those). Given the option of playing with poor performance with midrange textures in openGL, spending unknown hours trimming the stock game, or using high resolution textures in x64-I went with 64-bit. I think with time I could cutout about 250MB from the stock game that would not impact my gameplay at all, but I'm using over 5GB of RAM now so that wouldn't balance the scales. It may be worth checking out the 64-bit version, it is labeled as unstable and not supported but it seems almost everyone who uses it has better performance and overlooks the few known inconveniences. It is probably assumed x64 is the problem if you are using x64, but if you also have a 32-bit install to check against many problems will end up being universal.