Psycho_zs

This config automatically sets throttle depth devised from Isp. It can be adapted to with ThrottleLimiterModule and act as a fallback. // find engines that use Oxidiser and have minThrust 0 @PART[*]:HAS[@MODULE[ModuleEngines*]:HAS[@PROPELLANT[Oxidizer],#minThrust[0]]]:FINAL { @MODULE[ModuleEngines*] { // set minThrust to maxThrust @minThrust = #$maxThrust$ // multiply by Isp(ASL): @minThrust *= #$atmosphereCurve/key,1[1, ]$ // divide by Isp(Vac): @minThrust /= #$atmosphereCurve/key,0[1, ]$ // Uncomment these for quad variant: // multiply by Isp(ASL) again: //@minThrust *= #$atmosphereCurve/key,1[1, ]$ // divide by Isp(Vac) again: //@minThrust /= #$atmosphereCurve/key,0[1, ]$ } // update description thrustPerc = #$MODULE[ModuleEngines*]/minThrust$ @thrustPerc *= 100 @thrustPerc /= #$MODULE[ModuleEngines*]/maxThrust$ @description ^= :$: Can be throttled down to #$thrustPerc$%.: } There are limitations: values from atmosphereCurve are extracted positionally. I haven't seen a config in my GameData that does funky things with atmosphereCurve, but if the first key isn't a vacuum value or the second isn't sea level value, things will go wrong. Maybe I will add filter for proper order in atmosphereCurve. The last bit about description update does not render the variable properly...

Is there a way to extract second value by first value, not by position, or is that an overkill? I mean, in case some mod somewhere assigns the curve positionally backwards: atmosphereCurve { key 1 290 key 0 315 } or has more keys in the curve: atmosphereCurve { key 0 315 key 0.5 301 key 1 290 } #$atmosphereCurve/key,1[1, ]$ would return undesired data.

Thanks! So, will this line get the key by it's first value (0) or by key's position (0)? I've looked at the configs in my GameData, key 0 comes first everywhere, but is it safe to assume that?

Hi! How can I use specific values from atmosphereCurve? Like get second value from the key where fist value=0. I want to do something like this: %minThrust = #$maxThrust$ @minThrust *= #$atmosphereCurve[key,0[1, ]]$ @minThrust /= #$atmosphereCurve[key,1[1, ]]$ (derive engine minThrust from its Isp drop, so vaccuum engines become more throttleable than lifter engines)

Returning to Throttle Limit. I want to find a fallback algorithm of autoassigning minThrottle via MM in relation to Isp. Here are a couple of ways to calculate a coefficient to apply to maxThrottle: engine Isp(ASL) Isp(Vac) Isp(Vac) / Isp(ASL) ( Isp(Vac) / Isp(ASL) )^2 Thud 275 305 0,90 0,81 Terrier 85 345 0,25 0,06 Puddle 90 350 0,26 0,07 Skipper 280 320 0,88 0,77 Mainsail 285 310 0,92 0,85 Reliant 260 310 0,84 0,70 Swivel 250 320 0,78 0,61 Vector 295 315 0,94 0,88 Rhino 205 340 0,60 0,36 Dart 290 340 0,85 0,73 I do not know how to extract data from atmosphereCurve.

Another batch of thoughts: Continuing burning when throttle is at 0 does not make sense gameplay-wise. Engines dynamically affecting behavior of other engines might not be handy predictablity-wise. You dock to some deeply throttleable craft while your throttle is not 0 and boom, unplanned blastoff. So proportional stretching should at least be optional. Flameout below minThrust can be set at part level. Sumarizing this we are left with 3 major variants: Proportional: Engine1: 0-----------------------------------------|maxThrust Engine2: 0mmmmmmmmmmm|minThrust--------------------|maxThrust Engine3: 0mmmmmmmmmmmmmmmmmmmmmmmmm|minThrust------|maxThrust Throttle: 0|not_0-----------------------------------|100 Stretched proportionally to deepest throttle: (Engine1 removed, otherwise it would be the same as proportional) Engine2: 0|minThrust-------------------------------|maxThrust Engine3: 0mmmmmmmmmmmmmmmmmmmm|minThrust-----------|maxThrust Throttle: 0|not_0-----------------------------------|100 Stretched full: Engine1: 0----------------------|maxThrust Engine2: 0------0|minThrust------------|maxThrust Engine3: 0------------------------------------------------0|minThrust------------|maxThrust Throttle: 0|not_0----------------|100 + an option at part level to flameout below minThrust, (default false)

Nice idea. I've updated the analysis in previous post and in bugreport

Things will get messy either way when engines with different throttle depth are used simultaneously. Combinations of things can be reduced down to three advanced tweakables: shutdown when throttle = 0 shutdown when current thrust < minThrust throttle mapping: proportinal, or stretched proportionally to deepest throttle, or stretched fully Out of 12 possible combinations only 7 make sense:

Thanks, I've updated the description.

Cool. You might be interested in this bugreport to tweak existing stock parameter to allow more sane native behavior: https://bugs.kerbalspaceprogram.com/issues/15826 I wonder if it is possble to use atmosphereCurve values in MM selectors. (To autoassign thrust limits based on the difference between ASL and VAC Isp values)

PXL-10 may be a bit too light

Who would have thought that in this universe SBURB would be spawned from a KSP mod... So, what is your grand concept for translating these bodies into a physical plane? (Since the Incipisphere is a metaphysical medium and all (multiple puns intended)). Also, you might want to place a big spoiler alert at the beginning of your post, in case anyone here takes interest in the source material

Cool. You might be interested in following this report: https://bugs.kerbalspaceprogram.com/issues/15826

It worked, thanks!

I also tried '%' before that, which is 'edit or add' OK, will try this variant

I'm trying to tilt the skybox with this: @SigmaReplacements { @SkyBox { @CubeMap { @rotate = True } } } Nothing happens. Is something else needed to tilt stock skybox, or the randomness just decided something close to initial orientation?

That will do, i guess. But a bit more control would be great, in case the chosen rotation ends up being equally ridiculous

Hmm... The thing I always wanted to do is to just tilt the stock skybox, so it won't be aligned with the ecliptic. Is that possible?

I had a similar problem just recently, the answer is here:

Aw hell, this is frustrating. I've increased maxRotate to 30, but it still won't bend enough...

Thanks! I think I'm going to just nuke these ports, they aren't going to spend any significant time flapping in the wind outside of fairings anyway.

I've tried these variants, but it didn't work: @PART[dmFlexoTubeJr|dmFlexoTube|dmFlexoTubeSr]:FINAL { @MODULE[FARAeroPartModule] { @isEnabled = false } @MODULE[FARPartModule] { @isEnabled = false } } @PART[dmFlexoTubeJr|dmFlexoTube|dmFlexoTubeSr]:FINAL { !MODULE[FARAeroPartModule] {} !MODULE[FARPartModule] {} }

Is there a way to exclude a part from FAR calculations?

Hi! DMagic, do you have any idea, why a flexible docking port would be voxelized by FAR into a giant ballute?

Hi! I've caught some weird stuff. Today my Mun Tanker Truck persistently refused to go to space. It turned out to be a hilarious voxelization of flexible docking port jr. I've also left a message in DMagic's thread.