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. GUISkin changes may require specifying ExpandWidth(true) GUIOption in some GUILayout calls - like GUILayout.Toggle to maintain visual appearance with 1.7.3 styles 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

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

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

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

Darn, thats no fun, and yes saw the bit about reading the docs The log file moved a while ago, you can findit on windows in this path C:\Users\username\AppData\LocalLow\Squad\KerbalSpaceProgram\Player.log or very close to that. If your not on windows the other OS paths arelisted in this article: https://docs.unity3d.com/Manual/LogFiles.html Usually can find the cause in that one, or KSP.log in the game folder f cant find that one

A new version of this recompiled against 1.7.x with various fixes from myself and helpful community peeps is now available Download from GitHub or Download from Curse or Download from SpaceDock Recompile for 1.7.x Fixed display issues when transfer was impossible - result was NaN (Issue #53) Fixed up some Date Formatting (Thanks to @Aelfhe1m - Issue #51) Fixed up some altitude swapping (Thanks to nanathan - Issue #50) Fixed up some issues with the anglerendering (Thanks to codesquid - Issue #49) Fixed up some issues with drawing angles when not in the right scene Fixed issues with clamptoscreen for window Updated KACWrapper Added some ClickThrough locks for TS scene Fixed updated version check

Im working on it today

Thanks Steve, Ill dig into whats involved in changing those vs new fields vs other plans, etc. For the second one - TryGetFieldUIControl simply replaces the "am I in flight - therefore grab the uiControlFlight logic" casue we us ethe fields in all scenes. Your probably grabbing the right thing already then from above. the minValue/maxValue/stepIncrement of the UI_FloatRange will be the correct values for the range of the UI field, but they can/are modified in game at various points. My guess would be that kOS is scraping the attributes of the Field, or scraping the values before all the partmodules start/setup and its getting the default attrib values. Maybe have a look for that timing? from the description above sounds like how we read/write and use the UI_FloatRange fields in many scenes, those min/max/step values are not "non-changing" by design so the attrib/initial values may not always be the same. As an extra wrinkle/feature, the robotics things like targetExtension are actually KSPAxisFields - this has its own min/max which actually defines the valid range for controller input of the field and you could use those regardless of the UI configuration - we matched all of ours to the UI ones, but no guarantees everyone will do that - and that would involve changes that might not be the greatest for you. See how you go with the timing and Ill get back to you on the others. Can you do me a favor and log a "feedback" in the tracker and list any fields you know are not good for you - like currentExtension on the piston - and I can bundle any work up in one go. Poke the link back here with the number. Ta

I'm pretty sure I understand both of these Problem 1: Is going to be because that is a string field for display and is only worked on when the PAW is open to cut down on the string formatting work, Garbage and processing. My suggestion will be that we expose a "value" that's always updated (if there is not already). Is it easier if these are fields or methods or irrelevant? Problem 2: This one is more interesting, I can understand the use of the UI fields to help with the limits, but it appears that what you've got there is the attributes on the field definition and not the range of the UI Controls themselves. This would be especially common in the robotics parts as the player can change the limits in edit mode. The way we do this in the stock code is to grab the UI_FloatRange control and read its values. Its not a new problem for range controls im sure, but much more obvious with the way they share modules. So a simple method to demonstrate how you could read that sorta stuff is below /// <summary> /// Get the Min Value from a fields UI Control /// </summary> /// <param name="p">PartModule containing the field</param> /// <param name="fieldName">the name of the field</param> /// <param name="minValue">the min Value from the UI_FloatRange</param> /// <returns>True if the field exists</returns> private bool GetRangeMinValue(PartModule p, string fieldName, out float minValue) { UI_FloatRange rangeControl; if (p.Fields.TryGetFieldUIControl(fieldName, out rangeControl)) { minValue = rangeControl.minValue; return true; } minValue = 0; return false; }

Whats the method that kOS etc use to try and read these values? eg. if we exposed the values as Properties, vs fields, vs KSPFields would it make a difference or usage in kOS, etc?

For each of the parts we moved out we implemented an UpgradePipeline script to swap the part to its replacement and adjust the vessel on load of the save or craft. If you do want them specifically then copying/moving the files back into gamedata will restore them and the save/craft pre upgrade is stored with a .original extension when the upgradepipeline handles it

Yes sir.

Not sure I'm across the entirety of the above, there's a few bits that feel like assumptions that I can expand on. There wasn't any call during the development cycle aside from using the in-place term - its been that for a super long time and no previous feedback, there's no apparent need for consistency, we aim for consistency as much as we can and the core devs have a significant ratio of native-English speakers (unless Australian English doesnt count ). That expanded, I too like the term intercept as it includes the temporal component better than intersect. It's not been raised before, but hopefully others feel strongly about it and the feedback entry, I know I'll vote for it.

The text in the Maneuver Mode tool was set to match the existing one on the map nodes, if you'd like a change to the text a feedback would be the best way to proceed as we would change all for consistency if we did - I didnt find one for this request in a quick search.

yupp, thats why i mentioned it cause I have vis of extra info I cant find any ref to the PJ comments so cant add on that one

Thanks for the new report and visibility I recall the discussions last time and Sals meaning there was reworked, not revoked (from text I cant share) - which has a slightly different context.

You should be able to just drop in the new DLL, none of the other content changed. In the bigger picture the alarms are in the sfs as LatoMacciato mentioned and settings.cfg is not in the download, so you should be able to just install the new one in your usual ways and not lose settings or alarms - do the usual make a backup and give it the beans I say