JPLRepo

it was due to the website being upgraded and refreshed. Should be there again now.

KSP does not use N-Body physics. All planets are on rails. As stated above. Therefore it does not need G in any orbit calculations. It stores a gravParameter for each CelestialBody in their Unity prefabs. So, if you want to know what it is you can divide CelestialBody.gravParameter by CelestialBody.mass for any given planet. It's 6.67408e-11 btw.

PhysicsGlobals.GravitationalAcceleration https://kerbalspaceprogram.com/api/class_physics_globals.html#a0a62cc361f9d2388bfb6dc43e192ce50

What's being missed is the Resources is a collection dictionary.. and your mod is changing the resource definition. which I think is exposing a bug (which can only occur if a mod changes the resources on a part). It looks like the collection dictionary key is incorrectly set to the old Resource hash instead of the new Resource hash. - Probably due to the fact that in stock - this never changes when instantiating a copy of a part. I'd recommend resetting the Resources list after any part copied events in the Editor scene would resolve the issue.

The root cause was a combination of ModuleManager and mods that add parts to the game which then exposed a bug in the way KSP generates the partdatabase.cfg file if it finds it missing, which when playing stock - can only happen if the user manually deleted it. However, when playing with ModuleManager and mods that add parts - ModuleManager would force KSP to rebuild the partdatabase.cfg by removing it - or forcing it to rebuild it via code based on ModuleManager code logic (not stock KSP code logic). This bug also only created a problem for parts that use procedural drag cubes - such as the new stock MK2 landercan.

Only guessing. Because no logs.

you have the prerequisite mods installed?

There are others. KPBS and roverdudes mods and there were others. I wouldn’t be relying on the CKAN mod for this information.

Or .... he could be on holidays....

You’re certainly entitled to your opinion. But what new highly objectionable bugs are you referring to? looking at the public bug tracker. There are 5 bugs reported for 1.6.0. Four are low and one is normal priority. The light on the water tower

The API docs have been updated for 1.6. Link in the OP

You have the temp checking feature on in your DF game settings; and your part temperature is > the temperatures set in your settings. So they part cannot freeze any kerbals until it cools down. Temperature Checking function (switch on and off via config settings: RegTempReqd = true/false). If switched on the Freezer Part temperature must be < the RegTempFreeze value (in settings)to be able to freeze a kerbal. If switched on you must maintain the Freezer part temperature BELOW the RegTempMonitor (in settings) value. If you do not, then there is a good chance the freezer will fail and your kerbals WILL start dying if you have the EC fatal option turned on. If switched on Freezing/Thawing and Holding Frozen Kerbals will cause the freezer parts to produce Heat which you will then need to manage. - This function only operates on the active vessel as Temperature control on unloaded vessels is too risky in the current KSP version. If you wish to use this function, do so at your own risk.. (or rather the Kerbals) and use a heat control mod and parts like this one.

There are several settings a player can change as well as ways mods can disable all aspects of the DV feature There are several changes and additions to the API over what you may have found in 1.5 API.

That’s highly possible.

Of course there is an API interface for the helmet and neck ring feature.