[1.8.1 - 1.9.1] Kopernicus Continued

[hemeac]

@R-T-B, not sure that the fix to your Solar Panel Config will end up with the expected behavior with parts with multiple solar panels. 

Going into the ModuleManager.ConfigCache, can see that parts with multiple solar panel modules will only have the first set a Kopernicus module, the rest will remain stock:

Spoiler

UrlConfig
{
	parentUrl = Luciole/Parts/Probes/_Luciole_cubesat_3u_03125.cfg
	PART
	{
		name = _Luciole_cubesat_3u_03125
		module = Part
		author = Well
		node_stack_top = 0.0, 0.090274, 0.0, 0.0, 1.0, 0.0, 0
		node_stack_bottom = 0.0, -0.090275, 0.0, 0.0, -1.0, 0.0, 0
		scale = 1
		rescaleFactor = 1
		CrewCapacity = 0
		TechRequired = engineering101
		entryCost = 1500
		cost = 150
		category = Pods
		subcategory = 0
		title = L3U "Ked" CubeSat
		manufacturer = Luciole Space Systems
		description = L3U "Ked" is the latest development in probe miniaturization. Despite it's diminutive size, the Ked is a fully-functional and incredibly lightweight command unit. The Ked's tiny enclosure means there is no room for internal reaction wheels, and battery capacity is pitiful at best.
		attachRules = 1,1,1,1,0
		mass = 0.005
		dragModelType = default
		maximum_drag = 0.1
		minimum_drag = 0.05
		angularDrag = 1
		crashTolerance = 15
		maxTemp = 1200
		explosionPotential = 0
		vesselType = Probe
		bulkheadProfiles = size00
		tags = command control (core cube kerbnet probe sas satellite space steer
		MODEL
		{
			model = Luciole/Parts/Probes/Luciole_cubesat_3u_03125
		}
		MODULE
		{
			name = ModuleCommand
			minimumCrew = 0
			hasHibernation = True
			defaultControlPointDisplayName = Default
			RESOURCE
			{
				name = ElectricCharge
				rate = 0.001
			}
			CONTROLPOINT
			{
				name = forward
				displayName = Forward
				orientation = 90,0,0
			}
			CONTROLPOINT
			{
				name = reverse
				displayName = Reversed
				orientation = 0,0,180
			}
		}
		MODULE
		{
			name = ModuleReactionWheel
			PitchTorque = 0.001
			YawTorque = 0.001
			RollTorque = 0.001
			RESOURCE
			{
				name = ElectricCharge
				rate = 0.001
			}
		}
		RESOURCE
		{
			name = ElectricCharge
			amount = 30
			maxAmount = 30
		}
		MODULE
		{
			name = ModuleSAS
			SASServiceLevel = 3
		}
		MODULE
		{
			name = ModuleKerbNetAccess
			MinimumFoV = 13
			MaximumFoV = 40
			AnomalyDetection = 0.1
			DISPLAY_MODES
			{
				Mode = Terrain,#autoLOC_438839
			}
		}
		MODULE
		{
			name = ModuleDataTransmitter
			antennaType = DIRECT
			packetInterval = 1.0
			packetSize = 2
			packetResourceCost = 1.0
			requiredResource = ElectricCharge
			antennaPower = 250
			packetFloor = .1
			packetCeiling = 5
		}
		MODULE
		{
			name = KopernicusSolarPanels
			isTracking = false
			secondaryTransformName = suncatcher1
			pivotName = suncatcher1
			isBreakable = false
			resourceName = ElectricCharge
			chargeRate = 0.05
			extendActionName = Extend <<1>>
			retractActionName = Retract <<1>>
			extendpanelsActionName = Toggle <<1>>
		}
		MODULE
		{
			name = ModuleDeployableSolarPanel
			isTracking = false
			secondaryTransformName = suncatcher2
			pivotName = suncatcher2
			isBreakable = false
			resourceName = ElectricCharge
			chargeRate = 0.05
			extendActionName = Extend <<1>>
			retractActionName = Retract <<1>>
			extendpanelsActionName = Toggle <<1>>
		}
		MODULE
		{
			name = ModuleDeployableSolarPanel
			isTracking = false
			secondaryTransformName = suncatcher3
			pivotName = suncatcher3
			isBreakable = false
			resourceName = ElectricCharge
			chargeRate = 0.05
			extendActionName = Extend <<1>>
			retractActionName = Retract <<1>>
			extendpanelsActionName = Toggle <<1>>
		}
		MODULE
		{
			name = ModuleDeployableSolarPanel
			isTracking = false
			secondaryTransformName = suncatcher4
			pivotName = suncatcher4
			isBreakable = false
			resourceName = ElectricCharge
			chargeRate = 0.05
			extendActionName = Extend <<1>>
			retractActionName = Retract <<1>>
			extendpanelsActionName = Toggle <<1>>
		}
		MODULE
		{
			name = ModuleScienceExperiment
			experimentID = StudentExperiment
			experimentActionName = Run Student Experiment
			resetActionName = Delete Data
			useStaging = False
			useActionGroups = True
			hideUIwhenUnavailable = False
			xmitDataScalar = 1
			dataIsCollectable = True
			collectActionName = Take Data
			interactionRange = 1.5
			rerunnable = True
			usageReqMaskInternal = 1
			usageReqMaskExternal = 8
		}
		MODULE
		{
			name = ModulePartVariants
			baseVariant = 1U
			VARIANT
			{
				name = 1U
				displayName = 1U
				primaryColor = #999999
				GAMEOBJECTS
				{
					Luciole_1U = true
					Collider_1U = true
					SolarPanel_1U = true
					structural_Grey_1U = true
					Luciole_2U = false
					Collider_2U = false
					SolarPanel_2U = false
					structural_Grey_2U = false
					Luciole_3U = false
					Collider_3U = false
					SolarPanel_3U = false
					structural_Grey_3U = false
				}
			}
			VARIANT
			{
				name = 2U
				displayName = 2U
				primaryColor = #999999
				cost = 10
				mass = 0.005
				GAMEOBJECTS
				{
					Luciole_1U = false
					Collider_1U = false
					SolarPanel_1U = false
					structural_Grey_1U = false
					Luciole_2U = true
					Collider_2U = true
					SolarPanel_2U = true
					structural_Grey_2U = true
					Luciole_3U = false
					Collider_3U = false
					SolarPanel_3U = false
					structural_Grey_3U = false
				}
				NODES
				{
					node_stack_top = 0.0, 0.156217, 0.0, 0.0, 1.0, 0.0, 0
					node_stack_bottom = 0.0, -0.156216, 0.0, 0.0, -1.0, 0.0, 0
				}
			}
			VARIANT
			{
				name = 3U
				displayName = 3U
				primaryColor = #999999
				cost = 30
				mass = 0.01
				GAMEOBJECTS
				{
					Luciole_1U = false
					Collider_1U = false
					SolarPanel_1U = false
					structural_Grey_1U = false
					Luciole_2U = false
					Collider_2U = false
					SolarPanel_2U = false
					structural_Grey_2U = false
					Luciole_3U = true
					Collider_3U = true
					SolarPanel_3U = true
					structural_Grey_3U = true
				}
				NODES
				{
					node_stack_top = 0.0, 0.222158, 0.0, 0.0, 1.0, 0.0, 0
					node_stack_bottom = 0.0, -0.222158, 0.0, 0.0, -1.0, 0.0, 0
				}
			}
		}
		MODULE
		{
			name = KOSNameTag
		}
		MODULE
		{
			name = ModuleDockingAid
		}
		MODULE
		{
			name = ModulePartInfo
			originalPartName = _Luciole_cubesat_3u_03125
		}
	}
}

 

 

[hemeac]

Going back to 1.9.1-7, you can see the issue with the Near Future Solar, your solar code still patched the solar module:

Spoiler

UrlConfig
{
	parentUrl = NearFutureSolar/Parts/SolarPanels/deploying-advanced/nfs-panel-deploying-advanced-1x1-ikonos-1.cfg
	PART
	{
		name = nfs-panel-deploying-advanced-1x1-ikonos-1
		module = Part
		author = ChrisAdderley
		rescaleFactor = 1
		TechRequired = advSolarTech
		entryCost = 240
		node_attach = 0.001, 0.0, 0.0, 1.0, 0.0, 0.0
		cost = 95
		category = Electrical
		subcategory = 0
		title = K0x7-FR 'Imager' 1x1 Advanced Photovoltaic Panels
		manufacturer = Kerbal Techsystems
		description = An advanced non-pivoting panel that folds out from the body of the spacecraft. Not sun-tracking.
		attachRules = 0,1,0,0,1
		mass = 0.02
		dragModelType = default
		maximum_drag = 0.2
		minimum_drag = 0.2
		angularDrag = 1
		crashTolerance = 8
		maxTemp = 1200
		thermalMassModifier = 2.0
		emissiveConstant = 0.95
		heatConductivity = 0.04
		bulkheadProfiles = srf
		tags = charge deploy e/c elect energ extend  generat (light panel photo power sun track unfold volt watt nearfuture advanced ikonos fold retract
		MODEL
		{
			model = NearFutureSolar/Parts/SolarPanels/deploying-advanced/nfs-panel-deploying-advanced-1x1-ikonos-1
			scale = 1.0,1.0,1.0
		}
		MODULE
		{
			name = KopernicusSolarPanels
			animationName = PanelsExtend
			sunTracking = false
			raycastTransformName = Suncatcher
			pivotName = B_Ikonos_Base
			isBreakable = true
			resourceName = ElectricCharge
			chargeRate = 0.7
			retractable = true
			extendActionName = Extend <<1>>
			retractActionName = Retract <<1>>
			extendpanelsActionName = Toggle <<1>>
		}
		MODULE
		{
			name = ModuleB9PartSwitch
			moduleID = cellSwitch
			switcherDescription = Cell Type
			affectDragCubes = False
			affectFARVoxels = False
			SUBTYPE
			{
				name = Basic
				title = Basic Cells
				descriptionSummary = 
				descriptionDetail = Basic cells deliver a good balance of power at a reasonable mass and cost.
				primaryColor = #5d7682
				secondaryColor = #5d7682
				addedCost = -34
				addedMass = -0.0015
				TEXTURE
				{
					baseTransform = B_IkonosPanel
					texture = NearFutureSolar/Parts/SolarPanels/deploying-advanced/nfs-panel-deploying-advanced-4-basic
					shaderProperty = _MainTex
				}
				TEXTURE
				{
					baseTransform = B_IkonosPanel
					texture = NearFutureSolar/Parts/SolarPanels/deploying-advanced/nfs-panel-deploying-advanced-4-basic-s
					shaderProperty = _SpecMap
				}
				MODULE
				{
					IDENTIFIER
					{
						name = ModuleDeployableSolarPanel
					}
					DATA
					{
						chargeRate = 0.5
					}
				}
			}
			SUBTYPE
			{
				name = Advanced
				title = Advanced Cells
				descriptionSummary = <color=#00ff0c>+30% power</color>, <color=#ff0000>+25% mass, +35% cost</color>
				descriptionDetail = Advanced cells deliver more power per area at a higher cost.
				primaryColor = #2d373c
				secondaryColor = #2d373c
				defaultSubtypePriority = 1
				addedCost = 0
				addedMass = 0
				TEXTURE
				{
					baseTransform = B_IkonosPanel
					texture = NearFutureSolar/Parts/SolarPanels/deploying-advanced/nfs-panel-deploying-advanced-4
					shaderProperty = _MainTex
				}
				TEXTURE
				{
					baseTransform = B_IkonosPanel
					texture = NearFutureSolar/Parts/SolarPanels/deploying-advanced/nfs-panel-deploying-advanced-4-s
					shaderProperty = _SpecMap
				}
				MODULE
				{
					IDENTIFIER
					{
						name = ModuleDeployableSolarPanel
					}
					DATA
					{
						chargeRate = 0.7
					}
				}
			}
			SUBTYPE
			{
				name = Concentrating
				title = Concentrator Cells
				descriptionSummary = <color=#00ff0c>+75% power</color>, <color=#ff0000>+85% mass, +110% cost</color>
				descriptionDetail = Concentrator cells deliver maximum power in a small area, but weigh more.
				primaryColor = #000000
				secondaryColor = #000000
				addedCost = 72
				addedMass = 0.0036
				TEXTURE
				{
					baseTransform = B_IkonosPanel
					texture = NearFutureSolar/Parts/SolarPanels/deploying-advanced/nfs-panel-deploying-advanced-4-concentrator
					shaderProperty = _MainTex
				}
				TEXTURE
				{
					baseTransform = B_IkonosPanel
					texture = NearFutureSolar/Parts/SolarPanels/deploying-advanced/nfs-panel-deploying-advanced-4-concentrator-s
					shaderProperty = _SpecMap
				}
				MODULE
				{
					IDENTIFIER
					{
						name = ModuleDeployableSolarPanel
					}
					DATA
					{
						chargeRate = 1
					}
				}
			}
		}
		MODULE
		{
			name = KOSNameTag
		}
		MODULE
		{
			name = ModuleB9PartInfo
		}
		MODULE
		{
			name = ModulePartInfo
			originalPartName = nfs-panel-deploying-advanced-1x1-ikonos-1
		}
	}
}

 

The culprit happened in JNSQ as that disables Kopernicus solar panels at the part level which disables the B9 patch BUT

You have

@PART:HAS[@MODULE[ModuleDeployableSolarPanel]:HAS[~useKopernicusSolarPanels[false]]]:FINAL
{
    @MODULE[ModuleDeployableSolarPanel],*
    {
        @name = KopernicusSolarPanels
    }
}

Which will convert all moduledeployablesolarpanels to Kopernicus unless the modder has ALSO specified useKopernicusSolarPanels = false within the module of the solar panel part.

This is my suggested config which also incorporates elements of Zorg's BDB Patch to hopefully make it a bit more failsafe.  I have tested this with 60+ part mods in both JNSQ as well as multi-sun setup: Stock + GEP with no B9 Warnings in 1.9.1.

// If any modder adds useKopernicusSolarPanels = false to a module instead of a part, add it to the part:
@PART:HAS[@MODULE:HAS[#useKopernicusSolarPanels[?alse]]]:FINAL
{
	%useKopernicusSolarPanels = false
}

// Uses regular expressions to convert any case variants like FalSe to false
@PART:HAS[#useKopernicusSolarPanels[*]]:FINAL
{
    // This cfg will enable KopernicusSolarPanels
    // to allow support for multiple lightsources
    // 
    // If you want to avoid this, add "useKopernicusSolarPanels = false" to the PART node
    // That will stop Kopernicus from changing the behaviour of SolarPanels
    @useKopernicusSolarPanels,* ^= :F:f:
    @useKopernicusSolarPanels,* ^= :A:a:
    @useKopernicusSolarPanels,* ^= :L:l:
    @useKopernicusSolarPanels,* ^= :S:s:
    @useKopernicusSolarPanels,* ^= :E:e:
}

// Converts all ModuleDeployableSolarPanel modules within a part to KopernicusSolarPanels unless the part has useKopernicusSolarPanels = false
@PART:HAS[@MODULE[ModuleDeployableSolarPanel],~useKopernicusSolarPanels[false]]:FINAL
{
    @MODULE[ModuleDeployableSolarPanel],*
    {
        @name = KopernicusSolarPanels
    }
}

//B9PartSwitch support, changes the identifier to a generic identifier, just to be safe, but only runs if the part does not have useKopernicusSolarPanels = false ... 
@PART:HAS[@MODULE[ModuleB9PartSwitch],~useKopernicusSolarPanels[false]]:FINAL
{
    @MODULE[ModuleB9PartSwitch],*
    {
        @SUBTYPE,*
        {
            @MODULE:HAS[@IDENTIFIER[ModuleDeployableSolarPanel]]
            {
				@IDENTIFIER[ModuleDeployableSolarPanel]
				{
					@name = *SolarPanel*
				}
            }
        }
    }
}

// clean up
@PART:HAS[#useKopernicusSolarPanels[*]]:FINAL
{
	!useKopernicusSolarPanels = delete
}

@PART:HAS[@MODULE:HAS[#useKopernicusSolarPanels[*]]]:FINAL
{
    @MODULE,*:HAS[#useKopernicusSolarPanels[*]]
	{
		!useKopernicusSolarPanels = delete
	}
}

 

Edited October 6, 2020 by hemeac
Updated suggested patch after testing

[R-T-B]

2 hours ago, hemeac said:

@R-T-B, not sure that the fix to your Solar Panel Config will end up with the expected behavior with parts with multiple solar panels. 

Going into the ModuleManager.ConfigCache, can see that parts with multiple solar panel modules will only have the first set a Kopernicus module, the rest will remain stock:

  Reveal hidden contents

UrlConfig
{
	parentUrl = Luciole/Parts/Probes/_Luciole_cubesat_3u_03125.cfg
	PART
	{
		name = _Luciole_cubesat_3u_03125
		module = Part
		author = Well
		node_stack_top = 0.0, 0.090274, 0.0, 0.0, 1.0, 0.0, 0
		node_stack_bottom = 0.0, -0.090275, 0.0, 0.0, -1.0, 0.0, 0
		scale = 1
		rescaleFactor = 1
		CrewCapacity = 0
		TechRequired = engineering101
		entryCost = 1500
		cost = 150
		category = Pods
		subcategory = 0
		title = L3U "Ked" CubeSat
		manufacturer = Luciole Space Systems
		description = L3U "Ked" is the latest development in probe miniaturization. Despite it's diminutive size, the Ked is a fully-functional and incredibly lightweight command unit. The Ked's tiny enclosure means there is no room for internal reaction wheels, and battery capacity is pitiful at best.
		attachRules = 1,1,1,1,0
		mass = 0.005
		dragModelType = default
		maximum_drag = 0.1
		minimum_drag = 0.05
		angularDrag = 1
		crashTolerance = 15
		maxTemp = 1200
		explosionPotential = 0
		vesselType = Probe
		bulkheadProfiles = size00
		tags = command control (core cube kerbnet probe sas satellite space steer
		MODEL
		{
			model = Luciole/Parts/Probes/Luciole_cubesat_3u_03125
		}
		MODULE
		{
			name = ModuleCommand
			minimumCrew = 0
			hasHibernation = True
			defaultControlPointDisplayName = Default
			RESOURCE
			{
				name = ElectricCharge
				rate = 0.001
			}
			CONTROLPOINT
			{
				name = forward
				displayName = Forward
				orientation = 90,0,0
			}
			CONTROLPOINT
			{
				name = reverse
				displayName = Reversed
				orientation = 0,0,180
			}
		}
		MODULE
		{
			name = ModuleReactionWheel
			PitchTorque = 0.001
			YawTorque = 0.001
			RollTorque = 0.001
			RESOURCE
			{
				name = ElectricCharge
				rate = 0.001
			}
		}
		RESOURCE
		{
			name = ElectricCharge
			amount = 30
			maxAmount = 30
		}
		MODULE
		{
			name = ModuleSAS
			SASServiceLevel = 3
		}
		MODULE
		{
			name = ModuleKerbNetAccess
			MinimumFoV = 13
			MaximumFoV = 40
			AnomalyDetection = 0.1
			DISPLAY_MODES
			{
				Mode = Terrain,#autoLOC_438839
			}
		}
		MODULE
		{
			name = ModuleDataTransmitter
			antennaType = DIRECT
			packetInterval = 1.0
			packetSize = 2
			packetResourceCost = 1.0
			requiredResource = ElectricCharge
			antennaPower = 250
			packetFloor = .1
			packetCeiling = 5
		}
		MODULE
		{
			name = KopernicusSolarPanels
			isTracking = false
			secondaryTransformName = suncatcher1
			pivotName = suncatcher1
			isBreakable = false
			resourceName = ElectricCharge
			chargeRate = 0.05
			extendActionName = Extend <<1>>
			retractActionName = Retract <<1>>
			extendpanelsActionName = Toggle <<1>>
		}
		MODULE
		{
			name = ModuleDeployableSolarPanel
			isTracking = false
			secondaryTransformName = suncatcher2
			pivotName = suncatcher2
			isBreakable = false
			resourceName = ElectricCharge
			chargeRate = 0.05
			extendActionName = Extend <<1>>
			retractActionName = Retract <<1>>
			extendpanelsActionName = Toggle <<1>>
		}
		MODULE
		{
			name = ModuleDeployableSolarPanel
			isTracking = false
			secondaryTransformName = suncatcher3
			pivotName = suncatcher3
			isBreakable = false
			resourceName = ElectricCharge
			chargeRate = 0.05
			extendActionName = Extend <<1>>
			retractActionName = Retract <<1>>
			extendpanelsActionName = Toggle <<1>>
		}
		MODULE
		{
			name = ModuleDeployableSolarPanel
			isTracking = false
			secondaryTransformName = suncatcher4
			pivotName = suncatcher4
			isBreakable = false
			resourceName = ElectricCharge
			chargeRate = 0.05
			extendActionName = Extend <<1>>
			retractActionName = Retract <<1>>
			extendpanelsActionName = Toggle <<1>>
		}
		MODULE
		{
			name = ModuleScienceExperiment
			experimentID = StudentExperiment
			experimentActionName = Run Student Experiment
			resetActionName = Delete Data
			useStaging = False
			useActionGroups = True
			hideUIwhenUnavailable = False
			xmitDataScalar = 1
			dataIsCollectable = True
			collectActionName = Take Data
			interactionRange = 1.5
			rerunnable = True
			usageReqMaskInternal = 1
			usageReqMaskExternal = 8
		}
		MODULE
		{
			name = ModulePartVariants
			baseVariant = 1U
			VARIANT
			{
				name = 1U
				displayName = 1U
				primaryColor = #999999
				GAMEOBJECTS
				{
					Luciole_1U = true
					Collider_1U = true
					SolarPanel_1U = true
					structural_Grey_1U = true
					Luciole_2U = false
					Collider_2U = false
					SolarPanel_2U = false
					structural_Grey_2U = false
					Luciole_3U = false
					Collider_3U = false
					SolarPanel_3U = false
					structural_Grey_3U = false
				}
			}
			VARIANT
			{
				name = 2U
				displayName = 2U
				primaryColor = #999999
				cost = 10
				mass = 0.005
				GAMEOBJECTS
				{
					Luciole_1U = false
					Collider_1U = false
					SolarPanel_1U = false
					structural_Grey_1U = false
					Luciole_2U = true
					Collider_2U = true
					SolarPanel_2U = true
					structural_Grey_2U = true
					Luciole_3U = false
					Collider_3U = false
					SolarPanel_3U = false
					structural_Grey_3U = false
				}
				NODES
				{
					node_stack_top = 0.0, 0.156217, 0.0, 0.0, 1.0, 0.0, 0
					node_stack_bottom = 0.0, -0.156216, 0.0, 0.0, -1.0, 0.0, 0
				}
			}
			VARIANT
			{
				name = 3U
				displayName = 3U
				primaryColor = #999999
				cost = 30
				mass = 0.01
				GAMEOBJECTS
				{
					Luciole_1U = false
					Collider_1U = false
					SolarPanel_1U = false
					structural_Grey_1U = false
					Luciole_2U = false
					Collider_2U = false
					SolarPanel_2U = false
					structural_Grey_2U = false
					Luciole_3U = true
					Collider_3U = true
					SolarPanel_3U = true
					structural_Grey_3U = true
				}
				NODES
				{
					node_stack_top = 0.0, 0.222158, 0.0, 0.0, 1.0, 0.0, 0
					node_stack_bottom = 0.0, -0.222158, 0.0, 0.0, -1.0, 0.0, 0
				}
			}
		}
		MODULE
		{
			name = KOSNameTag
		}
		MODULE
		{
			name = ModuleDockingAid
		}
		MODULE
		{
			name = ModulePartInfo
			originalPartName = _Luciole_cubesat_3u_03125
		}
	}
}

 

 

The current fix is more a fallback to old behavior.  It won't cover all cases but it will function as it did before for at least near future solar and most major mods.  I obviously botched the first patch and was just looking for quick fix (still a modularmanager noob in terms of understanding syntax). 

I was planning on looking at it in more detail tomorrow but I appreciate you beating me to it.  That will likely ship to bleeding edge tomorrow and then to stable very soon thereafter.  I just need to test it, which I will probably do tomorrow morning.  Thanks.  You'll get credit in next release's release notes.

Edited October 6, 2020 by R-T-B

[hemeac]

3 minutes ago, R-T-B said:

The current fix is more a fallback to old behavior.  It won't cover all cases but it will function as it did before for at least near future solar and most major mods.  I obviously botched the first patch and was just looking for quick fix (still a modularmanager noob in terms of understanding syntax). 

I was planning on looking at it in more detail tomorrow but I appreciate you beating me to it.  That will likely ship to bleeding edge tomorrow and then to stable very soon thereafter.  I just need to test it, which I will probably do tomorrow morning.  Thanks.

It definitely took my lunch break+ to diagnose why it was failing.

[R-T-B]

Kopernicus 1.9.1-9

R-T-B released this 1 minute ago · 1 commit to master since this release

New in this version (1.9.1-9)

1.) Contributions to SolarPanels.cfg from forum user hemeac to help avoid errors in third party packs.

New in major release (1.9.1)

1.) Planet pack authors (or you) may now specify the packs target shader level by by setting config/Kopernicus_Config.cfg EnforcedShaderLevel. 3 = Ultra/Atlas, 2 = High, 1 = Medium, and 0 = Low. Planet pack authors may use this via modulemanager module if needed as well. Note that we encourage of the KSP Parallax shader project over use of Squad's ATLAS shader. It is both equally performant and more flexible.

2.) The longstanding ringshader bugs have been fixed.

3.) Performance Optimization and bugfixes enabling KittopiaTech support.

4.) JNSQ & other large world "Farm patch" bug fixed.

5.) Particle support restored.

6.) All 1.9.1 bugs that are known fixed. Full support for 1.9.1

7.) Multistar support. The math on ECs in single star may be slightly different than stock in some situations, but it should be similar in most and not enough to matter.

8.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable shader locking, as well as set preferred shader level. Easy to edit, just look inside!

Edited October 7, 2020 by R-T-B

[R-T-B]

This is a big release to the stable branch people, for both planet devs and players.  I strongly advise updating!  Highlighting some of the chief improvements below!

Kopernicus 1.9.1-10

R-T-B released this now

New in this version (1.9.1-10)

1.) Added a culling range to land scatters, by default at 10km, configurable by the Kopernicus_Config.cfg parameter ScatterCullDistance. This massively improves performance in scatter-heavy planet packs with land scatters on.

2.) We now support "Breaking Ground" anomalies out of the box, eliminating the need for "MyRocksAreBiggerThanYours."

3.) Material names have been simplified. You can still use the old ones, but there are simpler alternatives now. You can see https://github.com/R-T-B/Kopernicus/pull/28/files for details, or simply wait for the wiki to update. Remember, the old names still work and we have no plans to change that, this is just for usability.

New in major release (1.9.1)

1.) Planet pack authors (or you) may now specify the packs target shader level by by setting config/Kopernicus_Config.cfg EnforcedShaderLeve. 3 = Ultra/Atlas, 2 = High, 1 = Medium, and 0 = Low. Planet pack authors may use this via modulemanager module if needed as well. Note that we encourage of the KSP Parallax shader project over use of Squad's ATLAS shader. It is both equally performant and more flexible.

2.) The longstanding ringshader bugs have been fixed.

3.) Performance Optimization and bugfixes enabling KittopiaTech support.

4.) JNSQ & other large world "Farm patch" bug fixed.

5.) Particle support restored.

6.) All 1.9.1 bugs that are known fixed. Full support for 1.9.1

7.) Multistar support. The math on ECs in single star may be slightly different than stock in some situations, but it should be similar in most and not enough to matter.

8.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable shader locking, as well as set preferred shader level. Easy to edit, just look inside!

Edited October 10, 2020 by R-T-B

[Infinity and Beyond]

Where can i download this mod for KSP 1.9.0?

 

[AVaughan]

1 hour ago, Infinity and Beyond said:

Where can i download this mod for KSP 1.9.0?

I'm pretty sure there is no released version for 1.9.0. 

There is a link to the 1.9.1 version in the first post.  

[Guest]

I have a problem: KSP says that this mod is incompatible with version 1.10.1. Is there any compatible version?

[boribori]

3 minutes ago, gabo04 said:

I have a problem: KSP says that this mod is incompatible with version 1.10.1. Is there any compatible version?

 

 

[Guest]

13 minutes ago, boribori said:

 

 

Thank you.

[Poodmund]

The forum got updated but this thread wasn't deleted... @Thomas P.... what's going on?  

[OOM]

On 10/21/2020 at 12:08 AM, Poodmund said:

The forum got updated but this thread wasn't deleted... @Thomas P.... what's going on?  

What did you say?

[TARDIS Mapping]

On 9/19/2020 at 4:53 PM, R-T-B said:

Please be the exception.

Will do, I'll have it to you in a few days. My apologies about taking so long to reply, ngl, I forgot I signed up for the KSP forums.

[R-T-B]

2 hours ago, TARDIS Mapping said:

Will do, I'll have it to you in a few days. My apologies about taking so long to reply, ngl, I forgot I signed up for the KSP forums.

Thanks for getting back to me.  I hope I can help you out!  And no worries, the only cost of taking a long time with my requests is I can't help you until I get what I ask for, lol.

On 10/24/2020 at 10:28 PM, OOM said:

What did you say?

I think he's surprised the internet didn't eat our thread, is all.  Forum updates here do weird crap a lot.

[Maple Kerman]

Don't know if this is the right place to ask this, but...

Regarding configs for bodies, are timewarpAltitudeLimits values still needed? Or is that redundant?

[OhioBob]

5 hours ago, Maple Kerman said:

Regarding configs for bodies, are timewarpAltitudeLimits values still needed? Or is that redundant?

Still needed.

[Maple Kerman]

@OhioBob Thanks.

[OhioBob]

[snip]

Is there a question here?  If you're asking if there's a version of Kopernicus for 1.10.1, then yes.  It's experimental, however.

 

Edited October 30, 2020 by Vanamonde

[R-T-B]

Kopernicus 1.9.1-11

R-T-B released this 1 hour ago · 1 commit to master since this release

New in this version (1.9.1-11)

1.) Solarpanel.cfg fixes to support more third party solar panels with less work.

2.) Fixes for the colliders on land scatters (due to a small bug in the distance-culling system).

3.) Added an RGB+A parser (MapSOParserRGBA) for devs who requested it. Largely an under the hood change with no end-user impact immediately visible.

New in major release (1.9.1)

1.) Added a culling range to land scatters, by default at 10km, configurable by the Kopernicus_Config.cfg parameter ScatterCullDistance. This massively improves performance in scatter-heavy planet packs with land scatters on.

2.) We now support "Breaking Ground" anomalies out of the box, eliminating the need for "MyRocksAreBiggerThanYours."

3.) Material names have been simplified. You can still use the old ones, but there are simpler alternatives now. You can see https://github.com/R-T-B/Kopernicus/pull/28/files for details, or simply wait for the wiki to update. Remember, the old names still work and we have no plans to change that, this is just for usability.

3.) Planet pack authors (or you) may now specify the packs target shader level by by setting config/Kopernicus_Config.cfg EnforcedShaderLeve. 3 = Ultra/Atlas, 2 = High, 1 = Medium, and 0 = Low. Planet pack authors may use this via modulemanager module if needed as well. Note that we encourage of the KSP Parallax shader project over use of Squad's ATLAS shader. It is both equally performant and more flexible.

4.) The longstanding ringshader bugs have been fixed.

5.) Performance Optimization and bugfixes enabling KittopiaTech support.

6.) JNSQ & other large world "Farm patch" bug fixed.

7.) Particle support restored.

8.) All 1.9.1 bugs that are known fixed. Full support for 1.9.1

9.) Multistar support. The math on ECs in single star may be slightly different than stock in some situations, but it should be similar in most and not enough to matter.

10.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable shader locking, as well as set preferred shader level. Easy to edit, just look inside!

[R-T-B]

I apologize to release two releases in one day, but we had a logspam issue, so here's the hotfix.  Bleeding edge will also get the same fix in just a moment.

Kopernicus 1.9.1-12

R-T-B released this 39 seconds ago · 1 commit to master since this release

New in this version (1.9.1-12)

1.) This is a hotfix to address logspam issues that were otherwise mostly harmless (may hurt performance but not your game). Updating is still advisable.

New in major release (1.9.1)

1.) Solarpanel.cfg fixes to support more third party solar panels with less work.

2.) Fixes for the colliders on land scatters (due to a small bug in the distance-culling system).

3.) Added an RGB+A parser (MapSOParserRGBA) for devs who requested it. Largely an under the hood change with no end-user impact immediately visible.

4.) Added a culling range to land scatters, by default at 10km, configurable by the Kopernicus_Config.cfg parameter ScatterCullDistance. This massively improves performance in scatter-heavy planet packs with land scatters on.

5.) We now support "Breaking Ground" anomalies out of the box, eliminating the need for "MyRocksAreBiggerThanYours."

6.) Material names have been simplified. You can still use the old ones, but there are simpler alternatives now. You can see https://github.com/R-T-B/Kopernicus/pull/28/files for details, or simply wait for the wiki to update. Remember, the old names still work and we have no plans to change that, this is just for usability.

7.) Planet pack authors (or you) may now specify the packs target shader level by by setting config/Kopernicus_Config.cfg EnforcedShaderLeve. 3 = Ultra/Atlas, 2 = High, 1 = Medium, and 0 = Low. Planet pack authors may use this via modulemanager module if needed as well. Note that we encourage of the KSP Parallax shader project over use of Squad's ATLAS shader. It is both equally performant and more flexible.

8.) Performance Optimization and bugfixes enabling KittopiaTech support.

9. Particle support restored.

10.) All 1.9.1 bugs that are known fixed. Full support for 1.9.1

9.) Multistar support. The math on ECs in single star may be slightly different than stock in some situations, but it should be similar in most and not enough to matter.

10.) Added GameData\Kopernicus\Config\Kopernicus_Config.cfg file, with options to configure shader warnings and enable or disable shader locking, as well as set preferred shader level. Easy to edit, just look inside!

Edited November 1, 2020 by R-T-B

[Murdabenne]

Just so I am clear, when there is a stable, non-experimental ready release for 1.10.x:  Will it simply be a milestone in the RTB developmental thread? Or will there be a separate topic completely for just the 1.10.x Kopernicus? Or will this topic update and become the 1.10.x "stable release" thread of discussion?

[R-T-B]

1 hour ago, Murdabenne said:

Just so I am clear, when there is a stable, non-experimental ready release for 1.10.x:  Will it simply be a milestone in the RTB developmental thread? Or will there be a separate topic completely for just the 1.10.x Kopernicus? Or will this topic update and become the 1.10.x "stable release" thread of discussion?

I suspect we will continue to use this topic for stable 1.10.1 and all future builds, but have not discussed it with Prestja yet so that COULD change.  I don't think it will though.

When 1.10 is release btw, we won't be dropped support for 1.9.1.  The new unified build system I pioneered in the bleeding edge should allow us to continue to support 1.9.1 indefinitely (or at least until something really bad stops us).

Edited November 1, 2020 by R-T-B

[Murdabenne]

20 hours ago, R-T-B said:

I suspect we will continue to use this topic for stable 1.10.1 and all future builds, but have not discussed it with Prestja yet so that COULD change.  I don't think it will though.

When 1.10 is release btw, we won't be dropped support for 1.9.1.  The new unified build system I pioneered in the bleeding edge should allow us to continue to support 1.9.1 indefinitely (or at least until something really bad stops us).

Thanks for the information.  I agree with your intent to have a unified release and consequentially a unified topic message thread for all versions, based off this, the current 1.9.x topic.  Its simpler, and hopefully makes for less work for you and @prestjaas well, since this is a lot of stuff to do and you both are donating your free time.   Eric Raymond famously remarked "Every good work of software starts by scratching a developer's personal itch." I hope developing and maintaining this wonderful add-on keeps "scratching" whatever it does for both of you.

Edited November 2, 2020 by Murdabenne
typo

[infinite_monkey]

How many open issues are left to fix for a 1.10 release? Or is 1.10 still kinda alpha?