TriggerAu

New version recompiled against 1.8.x Download from GitHub or Download from Curse or Download from SpaceDock Ive not seen/looked at bugs yet for nodes, still getting over the 1.8.1 rush

There will be an update, but it will be a smidge as we work on other things KSP.

JPG and PNG and a minimum size of 1280*720 - Ill get that added to the changelog/notes From your previous posts it sounds like the settings reset people are finding with some locales that use , for the decimal sepaerator. Could that be it?

Here’s some notes and details from the team with regards to the changes that come with KSP 1.8.0 Unity Upgrade Summary KSP now runs on Unity 2019.2.2f1. DX11 support. DX9 no longer supported. .NET 3.5 is deprecated. So we switch it up to .NET4.x. .NET 4 full API. Now supporting C# 7.3 with Roslyn Compiler. Though we recommend you consider performance and Garbage generation within Unity when writing your code. GPU instancing support. PhysX 3.4.2 upgrade. New Incremental Garbage Collector implemented. Legacy particle system is gone. Unity no longer supports DXT3 compressed DDS format Project Plugin Upgrades This is probably just for info, unlikely to be much direct correlation with mod authoring TextMeshPro is now 1.2.2 in the main project, still not Unity native TMP VPP is now SDK V6 Things to look out for when Updating C# Plugin DLLs Change Target framework for your Mod application to .NET framework 4.x (any .NET > 4.x). References: UnityEngine.DLL is now split across several DLLs. You should at least add UnityEngine.DLL and UnityEngine.CoreModule.DLL to your project references. There will be other references required depending on what the mod needs. add UnityEngine.IMGUIModule.DLL - for any IMGUI mods. add UnityEngine.InputLegacyModule.DLL - if you are references Input. add UnityEngine.AnimationModule.DLL - if you reference Animations/AnimationState. Texture2D.LoadImage - moved to ImageConversion.LoadImage - add UnityEngine.ImageConversionModule.DLL reference. add UnityEngine.AudioModule.DLL for any audio mods. If your automating builds using csc directly, nostdlib:, nosdkpath and direct refs to mscorlib, System.Core and System are recommended. Notes about Part Tools New part tools will be made available that contains latest part shaders for DX11 support. Other than that, the same processes apply as always. Specific Changes to KSP Unity Changes Coroutines returned from a MonoBehaviour while its GameObject is being disabled or destroyed are no longer started and Unity will report them as an error in the log. DXT3 DDS formatted textures are not supported by Unity or KSP any more. You must convert to DXT5 You should not call the Log or log messages in class constructors. Shaders New shader variants for the PQS terrain have been added. Low quality shaders are equivalent to the old shaders. Medium quality materials use the "Terrain/PQS/PQS Main - Optimised With Fast Blend" shader. High quality materials use the "Terrain/PQS/PQS Triplanar Zoom Rotation" shader. The new PQS shaders require that the tangents be built for the PQS quads. Please turn on the setting for the PQS if you’re going to be using them. The new shader for the KSC terrain is called "KSP/Scenery/Diffuse Ground KSC" If your "Shader.Find" call does not find your old shader you can try to add "Legacy Shaders/" to the name. LIke "Legacy Shaders/Particles/Additive" A number of shaders have been moved to legacy by Unity. However, a number of these have been made available by us in the distribution. Particularly particle shaders that are now marked as Legacy. Performance Changes A number of tweaks were made to remove unnecessary, or massively repeated processing. Some of these you’ll find in the changelog as they are simply and should have no concern to modding. The below ones are unlikely to have an impact, but here's some extra detail that could be useful from what we have seen in code and mod testing We’re caching the list of render meshes when parts are first created instead of “finding” them as the time as the meshes don’t change during flight in stock game. If you’re dynamically creating meshes which are then added to the vessel (or removing meshes), they might not be included in the mesh cache. Please call the following methods as appropriate when changing the meshes on a part: `part.ResetModelMeshRenderersCache()` `part.ResetModelRenderersCache()` `part.ResetModelSkinnedMeshRenderersCache()` Tooltips are now cached and re-used for performance reasons. If you have some information that is left over from a previously displayed tooltip, please make sure to overwrite it. Also, please clear any listeners that you might have on them when they’re finished being used as the methods will continue to be called in the future. If you want to refresh the PAW for a part, please use MonoUtilities.RefreshPartContextWindow(part) as it has better performance than MonoUtilities.RefreshContextWindows(part) Instead of using gameObject.GetComponentUpwards<Part>(), please use FlightGlobals.GetPartUpwardsCached(gameObject) instead for performance reasons. This gets the Part component that on this object or its parents, the first call stores that as a cached value and then returns the cache until the scene changes or the cache is cleared. Similar to the mesh renderer components above, if you are changing the hierarchy of the GOs and the parent Part has changed then there is a reset method you can call to reset the cache: `FlightGlobals.ResetObjectPartUpwardsCache().` The value property of the VesselValues class now calculates the value only on the first “get” per frame (eg `vessel.AutopilotSkill`). The result is cached and the same result will be returned for the rest of the frame. If you require an uncached version then there is a valueUncached property. If you want to force the value to be updated so that the rest of the code uses it, please call the ResetValueCache() method so the next get call will recalc it. The ProtoModuleSnapshot constructor does not create the confignode string at all times any more. As the configNode should only be used once the part is packed or the vessel is onrails or when making a backup of an existing protomodulesnapshot this was generating massive garbage and CPU hit for no purpose. If your code is accessing the snapshots when the partmodule is active then the suggestion is ensuring to only check that for unloaded vessels) Other Info KerbalPortraitGallery.ActiveCrew is obsolete. Please use KerbalPortraitGallery.ActiveCrewItems. Any mods that have KSPedia slides will likely have to recompiled the slides, please check your slides.

Not currently in this mod no

The 1.7/Breaking ground one twisted the average a bit, but if you reconsider yoru time line with 1.7.3 in that calendar (which we do) I think youll find a nice pattern

I nerd out a bit each time I go back to it for modding or stock. . That braeunig site is a really good place for sure and theres a few others. I also have two books I use when I need to get my "head outta the screen" sometimes: "orbital mechanics for engineering students" and "Fundmentals of Astrodynamics" . Ive found them quite useful the first one has a good section on the eject/insert math

From the Mod code we read the values directly from each CelestialBody. If you wanna do em by hand then the wiki has all the details youd need to of the CB orbits in the orbital characteristics frame on the right, for example https://wiki.kerbalspaceprogram.com/wiki/Kerbin . the mean anomoly at UT 0 is listed there o you can see where on the orbit each planet starts at the "0" point

Yes, can rotate and zoom the camera so you can select and configure

Soo many amazing pictures in this thread. Thanks soo much for sharing what youve done, very appreciated

The team are always willing to sacrifice (kerbals) for science

I think Id have to do a lot of playing with principia to do that . Almost all the flight tools with KSP rely on the pched conics model thats used in most teaching, so from a pointA->pointB model I think it should be relatively close, but if principia is taking control of the CBs and their orbits as well ten it depends on if its updating the conics of the bodies and how far into the future your plotting - ie the further away in time s the further the conics and n-body models will diverge. Im pretty sure I recall from a while ago that taking teh actual Kerbin solar system orbits and switching directly to n-body physics means things can come apart fairly quickly depening on the accuracy and calculations.

New version recompiled against 1.7.x with various fixes from helpful community peeps is now available Recompiled for 1.7.3 (Issue #225) Dont report missing vessel if there isnt one (Issue #222) - Thanks ReeseGlidden Fix Drop-dows and scaling (Issue #228) - Thanks Kerbas-Ad-Astra update some urls/uris (Issue #229) - thanks zatricky and neilser Download from GitHub or Download from Curse or Download from SpaceDock

A new version of this is ready here that fixes the Camera breakage, took me a while to pin down where Id messed up, apologies. Download from GitHub or Download from Curse or Download from SpaceDock

thanks all Ill difin tonight afer work