NathanKell

I looked into this, and per the issues I just updated it looks like the actual problem is the 0.43.0.10 tagged release on GitHub lacks an actual release zip (and thus lacks a dll, since the dll is not in the repo's GameData directory AFAICT), so I'm not sure it's compatible with any version of KSP. :] If you do plan to make changes that break compatibility with KSP 1.10 going forward, I would beg that you apply a version override to 0.43.0.8 and dot9 to let them, at least, be marked as 1.10 compatible, since I have neither experienced nor heard of any 1.10 issues with them.

Do want to clear up that I'm one of many, though my name remains on the OP.

And yet the cfg was unchanged from when you committed it. My guess is you did not test all cases (i.e. multiple upgrades in an active career where you create something in the editor, give it max MLI layers, save it, load it, exit scene, launch, quicksave/load, etc--the ordering of ConfigNode loading may change in those cases) and thus missed that you had set them to be additive upgrades incorrectly. EDIT: It is of course possible that how KSPFields load ConfigNode values has changed during your absence, and its prior behavior masked the incorrect use of IsAdditiveUpgrade, but what seems more likely is that you were not able to trigger the edge case in your testing. As to what IsAdditiveUpgrade does--as I wrote the feature in question (Part upgrades, not RF's use of them, to be clear), I feel I'm on pretty firm ground when it comes to understanding its use. Though it is on me if the demo I released regarding upgrades left that unclear.

v1.10.3: Avionics Lower the volume required by early-game science cores to allow matching the volume of the WAC Corporal telemetry unit. Deprecate most non-procedural avionics. No vessel will break, but the old non-procedural guidance rings, 20in X-Ray core, etc. will no longer appear in the tech tree and part list. KCT Fix issues with not stopping warp when another mod (like KCT) lowers warp rates. The Upgrades panel is now available in flight as well as space center view. Contracts Phobos and Deimos flybys now require having electricity remaining on the probe, not transmitting science from Phobos and Deimos; Kerbalism science is acquired too slowly to be able to complete that parameter in a flyby of Phobos or Deimos. Fix the resource consumption parameter on the First Solar Satellite and Station Power Module contracts. Parts Move the ROTanks Hollow Interstage to the Starting Parts node. Deprecate stock battery parts and the Procedural Battery; use Service Module tanks instead since they vary with materials science level. Hide the (unsupported) Procedural SRB. Other Kerbals may now bail out of aircraft even at the first level of Astronaut Complex, and their parachute is available from the start. CONTRIBUTORS Thank you to everyone who contributed to this release!

Nothing to see here, see below for changelog.

Thanks folks!

Looks like CKAN still has 3.4.3 as `ksp_version_min 1.8.0` though. https://github.com/KSP-CKAN/CKAN-meta/blob/master/EditorExtensionsRedux/EditorExtensionsRedux-3.4.3.ckan

Fix released. v13.1.0 * Fix B9PS autoswitching when the part in question has resources (#268) * Ignore residuals requirements with ignoreForIsp propellants. * Fix bug with the implementation of MLI upgrades that led to the total MLI layers being broken on craft load in career. * Support showing rated continuous burn time as well as rated burn time in the module info text.

This is a bug from when the UPGRADES were introduced. They are set to additive, which means every upgrade gets added together, meaning you get multiple values in the ConfigNode of ` maxMLILayers = <whatever>`. So if you have multiple of these upgrades unlocked in the tech tree, you get multiple maxMLLayers lines in the module that MFT loads, meaning one of them (probably not the one you want) takes precedence on load. Fixed by removing the "IsAdditiveUpgrade" flag. You should only use that if the upgrade is additive on previous upgrade confignodes (i.e. say you have a module that has a bunch of OPTION nodes, and each upgrade adds another OPTION node. You use the flag then to say "don't remove previously added OPTION nodes when you add this upgrade's.)

The new module inherits from the old so you may not have to change anything?

Ugh somehow I posted without refreshing the page and missed siimav already replied. Whoops.

Hey, awesome to see you back in the fray! Looking forward to seeing what you come up with. On the refactoring front, you might want to look at what siimav and DRVeyl have done with the fork of KCT that lives as part of RP-1 now. https://github.com/KSP-RO/RP-0/tree/master/Source/KerbalConstructionTime

yup!

v13.0 released. Changelog: Added ability to gate Tanks behind PartUpgrades. set partUpgradeRequired just like techRequired. Add B9PS integration to apply a switch when changing engine config. Add Animated Bimodal engine support so engines can have nozzles extending in flight, etc. Add support for enhanced variance in engine performance. Engines now vary from engine to engine, run to run (i.e. per ignition), and during a run. Engines vary in specific impulse, flow rate, and (if they only have two major propellants) mixture ratio. This defaults to off, and replaces the previous variance system. Add support for residuals. Engines can't burn all propellant in their tanks (or casings, if solid) and leave some behind unburnt. A predicted value for this is displayed on the PAW in the VAB/SPH and in flight, and it is a worst-reasonable-case estimate. NOTE: You must use the latest dev version of MechJeb (or KER, once KER accepts Butcher's PR) or the estimated delta V will be higher than what you actually get out of your stage. This defaults to off. (API integration: get the KSPfield predictedMaximumResiduals which is a multiplier to the total propellant the engine has access to that will be left unburnt. Variation and residuals have reasonable guesses at default values for pump-fed and pressure-fed liquid engines and various types of solid rocket motors. Support applying ECMs to PARTUPGRADEs.

1. Presumably the KSP-RO team, since it's a KSP-RO repo now. 2. Uh, you can't really run MM patches _backwards_. Who is to say what a part's original maxTemp was? If you just want to keep the parts, nuke everything in the DRE folder other than Parts, and rename the DRE folder to something else so it doesn't trip MM's NEEDS clause.

Oh, and I released the new AJE that has those features just now.

I've updated the head repo (from which this was forked) for KSP 1.10+ and sent a Netkan PR. https://github.com/KSP-RO/DeadlyReentry/releases/tag/v8.0.0

I wrote the propeller code to be specifically independent of piston engines, it just requires a ITorqueProvider module. Probably just need to tweak SolverJet a bit to make it output torque and only minimal thrust. @blowfishwill know better than I about that.

@linuxgurugamer Glad to see this getting organized! It was seriously worrying to see CKAN indexing multiple forks under the same mod ID. A quick question about the new org's repo: is it intentional there is no Issues category? I'd like to log an issue regarding craft size detection. The way craft size is computed it just merges the bounds of all MeshRenderers and SkinnedMeshRenderers on all parts. Since the reported bounds are wrong in some cases (check the engineer report), I think there must be a mesh that is not having RecalculateBounds run on it, or there is a SkinnedMeshRenderer with updateWhenOffscreen not set to true.

This is a truly amazing collection, kudos! I'm glad to see all the work I put in to modeling piston engines sees some good use. Let me know if any of the config options are weird (or you run into holes that should be covered / find bugs / etc). Also, there's two relevant updates coming that should be of interest. First, AJE is getting a new release shortly (fixes in master already). It includes two big changes. There were some lingering issues with piston engines (namely that they didn't cut out with next to no air, which was not great; and they didn't account for mach drag on the rotor disc, which I had turned off back in 1.1 or so in the expectation that FAR's transonic rewrite would account for it, but it turned out not to and I never turned it back on). Also, AJE didn't model centrifugal flow turbojets different from axial-flow. I've now added isCentrifugalFlow as a field you can set. That enables a couple curves, centrifugalFlowMachEtaCurve and centrifugalFlowMachTPRCurve which have (IMO) sensible values, but are of course settable. They are respectively a multiplier to compressor efficiency and of pressure recovery at compressor intake, each as a function of mach number. Second, last night I discovered a bug with FAR which @dkavoliskindly fixed immediately: prop rotor discs (and all other excluded transforms) were not in fact being excluded from voxelization. That's fixed in FAR's master, and will go out in the next release.

Happy to help, this is such a wonderful mod!

Added support for another module (see OP), released v2.0

@AlphaMensaeawesome! And my netkan PR got merged so it should be CKANable shortly.

This plugin adds a lightweight partmodule that, when the part it is on is staged, plays a defined animation. It's a drop-in replacement for ModuleAnimatedDecoupler except with no decoupling. The staging icon is still a decoupler though, just so you can see one. Based on animation-playing code by Starwaster in Animated Decouplers, full credit to them for that base. It also adds ModuleAnimateGenericExtra which extends ModuleAnimateGeneric to support deployLimitName which if set will be the name used by the Deploy Limit slider, and showToggle which, if set to False, will hide the "toggle" event even if Deploy Limit is allowed. I built it on 1.10 but it works on 1.8+. Why should you care? Because if you replace Modular Launch Pad's Animated Decouplers with ModuleStagedAnimation (you can just do the following in an MM patch), suddenly MechJeb's autostage-clamps feature will play nice with the pads. @PART[AM_MLP*]:FOR[RealismOverhaul] { @MODULE[ModuleAnimatedDecoupler],* { @name = ModuleStagedAnimation } } But I'm sure you part modelers will come up with all sorts of cool uses for this. PRs welcome of course! Thanks to @AlphaMensaefor a truly exceptional mod (it very much increased my enjoyment of KSP!) and thanks to Starwaster for a good simple implementation of playing an animation on activate. Source: GitHub License: CC-BY-SA 4.0 Download: Latest Release

IIRC, CB's GetTemp just gets the base temperature from the temperature curve (i.e. evaluate that float curve by altitude). You want CB.GetAtmoThermalStats(). It gives the offset to the (base) temperature at altitude, given a bunch of inputs. It calculates that offset by getting the dot product between the polar axis and the sunward vector, the latitude (acos of dot(upaxis, body polar axis) ), the sun's minimum and maximum height above the horizon given the body's position in its solar year (this is obvs less meaningful for stock with its lack of axial tilt ). From that it figures out how much of a day is in sunlight and how much not. It corrects max daytime temp to ~3pm (for a 12hr day--whatever ) since IRL max daytime temp is not at noon, but later (as more energy gets absorbed). Basically all that figures out a "normalized value" between minimum daily temperature and maximum daily temperature, which is used to multiply the offset given by the latitude sun mult curve, and the seasonal variation is added in (evaluating the sun bias curve), and finally eccentricity is taken into account if that curve is defined. The function also figures out how much flux is coming from the body if you're in orbit, but that's not what you're asking about. That's all I recall.