Tonas1997

You mean the Sun.cfg that comes with scatterer? It *is* commented, but it doesn't specify the meaning of each value: //Flare and spikes: Centered on the sun // // //sunFlare.png flareSettings = 0.45,1,0.85 //sunSpikes.png spikesSettings = 0.6,1,1 At this point, I'm not sure there exists something like an "offset" property for scatterer sunflares. Would love to be proven wrong, though! Also keep in mind that, so far, I only saw this happening on scaled space (tracking station/map view); going to Proxima to test the problem in-situ is still a bit beyond my skills

I'm having a problem tweaking a sunflare; while the size of the sunspikes/sunflare is correct, it appears offset from the actual star. These are my current settings: ... flareSettings = 0.675, 1.0, 1.47 spikesSettings = 0.425, 1.0, 4.41 ... Now, I know the last value concerns the size - which is now correct - but what are the other two values? Are they related to the spatial offset of the flares? Or do I need to tweak something else?

Hey! Is there interest in custom CTT nodes for DeepFreeze stuff (something like "Cryonics" and "Advanced Cryonics")? I could draw the icons.

Neat! I'll contact CTT's author(s) to know which deboss level they used and I'll get back to you in a few days.

A few weeks ago, I opened this issue on Kerbalism's GitHub page regarding a compatibility problem with that mod. It has since been reopened as it had allegedly been fixed on SSTU's latest update. Can someone confirm both mods are working correctly? If yes, would 0.11.48.160 work on KSP 1.6.1?

I'm having a problem trying to use a 1.3.1 planet pack on 1.6.1-9 Kopernicus, due to outdated variable names. The body in question is a "ghost" barycenter which, on the config files, has the following properties: Properties { ... hiddenRnD = True RnDVisibility = SKIP ... } Apparently, the RnDVisibility enumerate doesn't have a 'SKIP' value anymore. What should it be replaced by? EDIT: as per the Kopernicus wiki, the value seems to still exist. Is it now case-sensitive?

Heyo! Would you be interested in a custom "Faster Than Light" node icon?

Thanks for the reply! Just checked the files and that node is added by KSPI-E; to be honest, I was not aware that those nodes were *added* by other mods EDIT: Is there a tool for designing/readjusting the tech tree, or do I have to eyeball node positions with just numeric coordinates? EDIT EDIT: Did you make the icons in Photoshop? I'd like to replicate the emboss/deboss effect you use for the sake of uniformity.

I have an idea for a custom icon for the "Faster Than Light" node, and for a new "Cryonics" node for DeepFreeze. Would you be interested in me making them, @Nertea?

Thanks for the reply! I've been looking for the specific config but can't seem to find it. I asked because 1.4.5 RO seems to have a problem configuring engine propellants. Engines like SSTU's J-2 do have Hydrolox configs, but the default one - the one that appears on the part tooltip - still uses LqdHydrogen (I reckon from CRP) and Oxidizer. As a comparison, here are the final configs from different MM caches: 1.3.1 ... MODULE { name = ModuleEnginesRF engineID = J-2 runningEffectName = running_closed thrustVectorTransformName = J-2-ThrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 423 heatProduction = 250 powerEffectName = Hydrolox-Upper shieldedCanActivate = True exhaustDamageMultiplier = 20 exhaustDamageFalloffPower = 1 exhaustDamageMaxMutliplier = 1.0 exhaustDamageSplashbackMult = 0.1 exhaustDamageSplashbackMaxMutliplier = 0.1 PROPELLANT { name = LqdHydrogen ratio = 15 DrawGauge = True } PROPELLANT { name = LqdOxygen ratio = 1 resourceFlowMode = STACK_PRIORITY_SEARCH } ... MODULE { name = ModuleEngineConfigs configuration = J-2 origMass = -1 modded = false type = ModuleEnginesRF CONFIG { name = J-2-200klbf minThrust = 676.66 maxThrust = 889.325 heatProduction = 100 massMult = 1.02 ullage = True pressureFed = False ignitions = 3 PROPELLANT { name = LqdHydrogen ratio = 0.7454 DrawGauge = True } PROPELLANT { name = LqdOxygen ratio = 0.2546 } ... 1.4.5 ... MODULE { name = ModuleEnginesRF engineID = J-2 runningEffectName = running_closed thrustVectorTransformName = J-2-ThrustTransform exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 423 heatProduction = 250 powerEffectName = Hydrolox-Upper shieldedCanActivate = True exhaustDamageMultiplier = 20 exhaustDamageFalloffPower = 1 exhaustDamageMaxMutliplier = 1.0 exhaustDamageSplashbackMult = 0.1 exhaustDamageSplashbackMaxMutliplier = 0.1 PROPELLANT { name = LqdHydrogen ratio = 15 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1 } atmosphereCurve { key = 0 421 key = 1 200 } } ... MODULE { name = ModuleEngineConfigs configuration = J-2 origMass = -1 modded = false type = ModuleEnginesRF CONFIG { name = J-2-200klbf minThrust = 676.66 maxThrust = 889.325 heatProduction = 100 massMult = 1.02 ullage = True pressureFed = False ignitions = 3 PROPELLANT { name = LqdHydrogen ratio = 0.7454 DrawGauge = True } PROPELLANT { name = LqdOxygen ratio = 0.2546 } ... As shown, the engine is left with a ModuleEnginesRF and a ModuleEngineConfigs. However, the parameters for the RF engine module are different from the first - and, in most cases, only - available config. The extraordinary part is that the RO patches from both 1.3.1 and 1.4.5 are exactly the same!

On my previous 1.3.1 modpack, every engine lacking a proper RF config and using LiquidFuel and Oxidizer resources was patched by RealFuels so as to use Kerosene and LqdOxygen as propellants (by default). This no longer seems to be the case for RealFuels version 12.7.2. For instance, the engine from B9 HX still uses LiquidFuel and Oxidizer. Am I missing something?

Is this compatible with 1.4.5? EDIT: Sorry for the necrobump

A bit off-topic, but is there any advantage in using DX11 for x64 KSP in the first place?

Would the 1.6.1 release work on a 1.4.2 install? The v16.0 fixes look really attractive.

Would the 1.4.4 version be compatible with 1.4.2?

What's the difference between SSTUSolarPanelDeployable and DeployableSolarPanel in terms of functionality? I'm asking because a couple of mods - Kerbalism and AmpYear - don't seem to recognize SSTU's panels as power-generating parts. The obvious solution would be to replace that module with an equivalent DeployableSolarPanel config, but I don't know how that could be done (I'm not that experienced with MM patches :P) EDIT: I thought about doing something like this, which is inspired on SSTU's RO configs: @PART[SSTU-ST-GEN-DSP-SMB-L]:AFTER[SSTU] { %RSSROConfig = True %rescaleFactor = 1.750 @title = SM Solar Panels Lv.4 (12.3 m^2) @description = SM Solar Panels Lv.4 (12.3 m^2). 2.5953 kW @tags ^=:$:, solar, station, power, tracking, array, saw @mass = 0.0467 @MODULE[SSTUSolarPanelDeployable] { @resourceAmount = 0 // was 2.5953 !powerCurve {} } @MODULE[ModuleDeployableSolarPanel] { @chargeRate = 2.5953 } } This effectively "disables" SSTU's module, but I'm a bit worried about how both modules handle deployment animations... although some field names are strikingly similar.

I know this (mostly) question concerns Kerbalism, but it does involve SSPX parts. The mod's inflatable habitats are pressurized by default on the editor, and since Kerbalism inflatable habitats are, also by default, set as "disabled", enabling a Kerbalism/SSPX habitat will cause it to deflate. This doesn't happen with Tokamak Industries - which I also use - whose habitat models are deflated by default. Example: I've been banging my head on Kerbalism's side trying to fix this, but to no avail. So I thought about doing the opposite and to try and fix things on SSPX's side. TL;DR: is there a way to "invert" the default inflatable habitat states? Keep in mind I can't use the DeployableHabitat module, since it is deleted by Kerbalism*. Playing on 1.3.1, btw. *although it could be kept if needed... also, I lost count of the number of times I wrote "default".

I know, but I have a gut feeling that this can be easily fixed - if only I knew exactly how the Habitat module works. Apparently, this bug happens because the default SSPX habitat state on the editor is "expanded". This is unlike mods such as Tokamak Industries, whose habitats are deflated by default (although this "state" can be set by the DeployableHabitat module, which is disabled by Kerbalism). EDIT: SSPX devs said it could be fixed if the Habitat module had some flag that indicated what's the default state of an inflatable habitat. Is there such a thing?

Sadly, that doesn't seem to have any effect. Mind you I'm still playing on 1.3.1 and that bug might have been fixed since then, but the config seems to be the same on more recent versions.

Thanks! Also, is there an easy way to reduce the size of a sunflare? I tried using the one from RSS's Sun on Proxima Centauri but, needless to say, it looks huge.

Another shenanigan concerning inflatable habitats: for some reason, the enabled/disabled states are inverted (tested on the SSPX inflatables): Notice both the Habitat: enabled/disabled flags on the part submenu and the volume/surface values. This might be a problem on the part's side, so what should I fix? EDIT: is it just a matter of changing the state to "enabled"? MODULE { name = Habitat inflate = Expand state = disabled animBackwards = True crewCapacity = #$../MODULE[ModuleDeployableHabitat]/DeployedCrewCapacity$ } (this is from Kerbalism's own SSPX compatibility patch file).

How does sunGlareFadeDistance work compared with Kopernicus brightnessCurve? Does it override its behaviour? I'm asking because, with Scatterer, distant stars are not visible from Earth, whereas Kopernicus brightnessCurve allowed for a fully configurable curve - and, consequently, for a non-zero minimum "size" (in this case, flare) to be set. Is there any way to limit the sunglare fading to a specific value at extreme distances?

The thing is, inflatable habitats with a Habitat module of this "type" MODULE { name = Habitat inflate = InflatoFlatInflate state = disabled animBackwards = False toggle = true } have volume/surface area values of 0, meaning they're not being calculated by Kerbalism. Since other habitats (from Tokamak, Squad, SSPEX and so on) with explicitely defined volume/surface values DO contribute to the vessel's total, I thought it might have something to do with the way the Habitat module is being implemented by Tokamak. In hindsight, I understood why the two pieces of code on my OP look different - as in one is a part definition and the other is a MM patch - but I still don't understand why Kerbalism is being prevented from assigning those values to a part which does feature a Habitat module. It should be done automatically, right?

I noticed the inflatable habitats I have from other mods (SSPEX and Tokamak) don't seem to contribute to the total available volume, making them somewhat useless. So I went to have a look at the config files and, to no surprise, they lack the appropriate module... to my understanding, that is. A typical Habitat module from those fixed-size parts looks like this (excluding the other stuff like resources and shielding): @MODULE[Habitat] { volume = 22.08 surface = 23.56 } Inflatable habitats, however, look like this: MODULE { name = Habitat inflate = InflatoFlatInflate state = disabled animBackwards = False toggle = true } Are these different? Since volume/surface area is calculated by Kerbalism, could I just add this @MODULE[Habitat] {} to the inflatable habitat config files?

Any chance the 1.4.5 release could work on a 1.3.1 modpack? The amount of fixes since the last 1.3.1 compatible version is a bit worrying to me, especially since I'm playing in RSS with Kerbalism