KSP Team
  • Content Count

  • Joined

  • Last visited

Everything posted by TriggerAu

  1. Thats not obnoxious, its good to chat. The changelog says that "from memory" because the repetition steps involved using the SetPosition "cheat". probably a bad choice when reading back from the changelog. apologies
  2. Yes 24871 is the bug that was fixed for helmets yes
  3. We are definitely still fixing bugs (and improving performance) from previous versions and constantly searching for the best fixes and feedback to add in each release. Not everyone agrees on what the best selection is, but we are always keeping an eye on the ones that people bring up, upvote, discuss and are concerned by in the various touch points we have with you the community and other interest groups. You can see called out some specific fixes in the changelog every release, and you can see items in the tracker and here/reddit/etc that people want fixed or addressed. I dont think I'd be speaking incorrectly to say that we all strive for the best release everytime, that may not meet everyones expectation every time, but do know we are always discussing what you all raise and feel is important to KSP and we are always around the forums, streams, reddit, etc, no less now than previously.
  4. From memory its the same logic that was used in the normal save loop previously, which is very much based on being "close" to the surface with respect to load protection - ie if you quicksave well a vessel is falling just above terrain, the quickload can put things under the surface. Perhaps the changelog shoudl have been more specific about the "about to crash" logic. Let me confirm it in the code andgive you specifics EDIT: The above is correct - dustance above terrain is the key. The default value is 500m above terrain level and you can adjust it in the settings if you want more/less safety - its called QUICKSAVE_MINIMUM_ALTITUDE
  5. 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
  6. There will be an update, but it will be a smidge as we work on other things KSP.
  7. 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?
  8. 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.
  9. 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
  10. 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
  11. 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 . the mean anomoly at UT 0 is listed there o you can see where on the orbit each planet starts at the "0" point
  12. Yes, can rotate and zoom the camera so you can select and configure
  13. Soo many amazing pictures in this thread. Thanks soo much for sharing what youve done, very appreciated
  14. The team are always willing to sacrifice (kerbals) for science
  15. 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.
  16. 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
  17. 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
  18. 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: Usually can find the cause in that one, or KSP.log in the game folder f cant find that one
  19. 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
  20. You can link an axis to the speed, but what your describing sounds like linking an axis to the playposition which is in the released version and it can play forwards/backwards based on the joystick postion You can do the same part in multiple KALs and play them independently yes. Currently the "last" one will win any setting
  21. 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