-
Posts
574 -
Joined
-
Last visited
Everything posted by 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.
-
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)
-
[WIP] Nert's Dev Thread - Current: various updates
Psycho_zs replied to Nertea's topic in KSP1 Mod Development
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
- 13 replies
-
- 1
-
- planet pack
- how do tags work?
-
(and 2 more)
Tagged with:
-
Cool. You might be interested in following this report: https://bugs.kerbalspaceprogram.com/issues/15826
- 69 replies
-
- module manager
- exampels
-
(and 1 more)
Tagged with:
-
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?
-
[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18
Psycho_zs replied to ferram4's topic in KSP1 Mod Releases
I had a similar problem just recently, the answer is here: -
[1.8.x] DMagic's Modlets - Most KSP 1.8 Updates [10-29-2019]
Psycho_zs replied to DMagic's topic in KSP1 Mod Releases
Aw hell, this is frustrating. I've increased maxRotate to 30, but it still won't bend enough... -
[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18
Psycho_zs replied to ferram4's topic in KSP1 Mod Releases
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. -
[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18
Psycho_zs replied to ferram4's topic in KSP1 Mod Releases
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] {} } -
[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18
Psycho_zs replied to ferram4's topic in KSP1 Mod Releases
Is there a way to exclude a part from FAR calculations? -
[1.8.x] DMagic's Modlets - Most KSP 1.8 Updates [10-29-2019]
Psycho_zs replied to DMagic's topic in KSP1 Mod Releases
Hi! DMagic, do you have any idea, why a flexible docking port would be voxelized by FAR into a giant ballute? -
[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18
Psycho_zs replied to ferram4's topic in KSP1 Mod Releases
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.