Jump to content

[1.8.1 - 1.9.1] Kopernicus Continued

prestja

By prestja
in KSP1 Mod Releases

 Share

Recommended Posts

hemeac

hemeac

Posted
Posted

@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
		}
	}
}

 

 

Link to comment
Share on other sites
hemeac

hemeac

Posted
Posted (edited)

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 by hemeac
Updated suggested patch after testing
Link to comment
Share on other sites
R-T-B

R-T-B

Posted
Posted (edited)
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 by R-T-B
Link to comment
Share on other sites
hemeac

hemeac

Posted
Posted
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.

Link to comment
Share on other sites
R-T-B

R-T-B

Posted
Posted (edited)

@R-T-B 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 by R-T-B
Link to comment
Share on other sites
R-T-B

R-T-B

Posted
Posted (edited)
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!

@R-T-B 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 by R-T-B
Link to comment
Share on other sites
R-T-B

R-T-B

Posted
Posted
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.

Link to comment
Share on other sites
R-T-B

R-T-B

Posted
Posted

@R-T-B 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!

Link to comment
Share on other sites
R-T-B

R-T-B

Posted
Posted (edited)

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.

@R-T-B 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.

  1. 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 by R-T-B
Link to comment
Share on other sites
Murdabenne

Murdabenne

Posted
Posted

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?

Link to comment
Share on other sites
R-T-B

R-T-B

Posted
Posted (edited)
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 by R-T-B
Link to comment
Share on other sites
Murdabenne

Murdabenne

Posted
Posted (edited)
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 by Murdabenne
typo
Link to comment
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...