[1.12.x]Sigma Dimensions Public Adoption Notice

[Sigma88]

On 5/30/2024 at 3:47 AM, R-T-B said:

I'd think SigmaDimensions might be worth looking at yeah, it's a much more complete project.  Only issue is licensing, Sigma wants to keep it ARR and while that technically means you are signing off your rights to him, I talked with him and it's pretty clear he's not out to poach anyones work, he just wants to protect his stewardship as the lead if he ever wants to come back.  He's a chill guy, I'd worry little about it.

I don't think I will "ever want to come take SD back", my main worry is that by freeing up the license a bunch of low quality clones will pop up and ultimately destroy the mod, I would rather it die by being outdated and broken rather than it becoming a clown show

 

if someone I trust wants to pick this up I am willing to give them full access to the mod, even renaming it if they feel necessary

however it would need to be someone I know from back then or someone that has contributed a lot of good stuff to the mod after I have gone

 

@R-T-B you definitely qualify if you want

 

for anyone else, if you want to contribute and have questions about the code you can still contact me if you run into some issues and need pointers about the code, for what my memory still holds (best way would probably be discord or github)

 

On 7/2/2024 at 9:24 PM, R-T-B said:

If you like the mod, please feel free to donate to @Sigma88 on the main github page.

at this point I don't think anyone should donate to me, surely there are other active modders that are more deserving, I'm happy with what little I got back when I was working on SD

[R-T-B]

1 hour ago, Sigma88 said:

at this point I don't think anyone should donate to me, surely there are other active modders that are more deserving, I'm happy with what little I got back when I was working on SD

This was kept mainly just until I had a chance to ask you.  Thanks for the clarification, I'll probably replace it with something else soon.

  

1 hour ago, Sigma88 said:

I don't think I will "ever want to come take SD back", my main worry is that by freeing up the license a bunch of low quality clones will pop up and ultimately destroy the mod, I would rather it die by being outdated and broken rather than it becoming a clown show

Well, you have my word I'll curate it accordingly and not let "clown code" in (my own notwithstanding, but I'm getting better everyday... lol)

Edited July 10 by R-T-B

[Zaxxon]

Hi, thanks to those for making (and maintaining) this mod.  It might be just what I'm needing to make a RO/RP1 style play thru but with Kerbol solar system instead of RSS.  I've never made any module manager patch files before.  Would you mind telling me if I did this it the correct and most proper way?

What I did:
I did not change anything in the settings.cfg file in the SigmaDimensions folder.
I created a separate patch.cfg file and put it in its own directory under GameData.  Contents of that file I made are:

@Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim]
{
    @Body:HAS[#name[*]]
    {
        @SigmaDimensions
        {
            @Resize = 3
            @Rescale = 3
            @Atmosphere = 1.25
            @dayLengthMultiplier = 2
            @landscape = 0.6
        }
    }
}

Example to scale up all bodies and orbital distance by 3x size.  It seems to have worked, but just trying to make sure I'm doing it the "right practices" way.  Thanks!

And is the: @Body:HAS[#name[*]] approach the best way to define the global settings in the patch file for all things, or is there a different way that I should set globals? Thinking like if I want generic globals, but then later create custom tweaks for a few individual planets.

Thanks!

Edited July 26 by Zaxxon

[R-T-B]

On 7/26/2024 at 2:26 PM, Zaxxon said:

Hi, thanks to those for making (and maintaining) this mod.  It might be just what I'm needing to make a RO/RP1 style play thru but with Kerbol solar system instead of RSS.  I've never made any module manager patch files before.  Would you mind telling me if I did this it the correct and most proper way?

What I did:
I did not change anything in the settings.cfg file in the SigmaDimensions folder.
I created a separate patch.cfg file and put it in its own directory under GameData.  Contents of that file I made are:

@Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim]
{
    @Body:HAS[#name[*]]
    {
        @SigmaDimensions
        {
            @Resize = 3
            @Rescale = 3
            @Atmosphere = 1.25
            @dayLengthMultiplier = 2
            @landscape = 0.6
        }
    }
}

Example to scale up all bodies and orbital distance by 3x size.  It seems to have worked, but just trying to make sure I'm doing it the "right practices" way.  Thanks!

And is the: @Body:HAS[#name[*]] approach the best way to define the global settings in the patch file for all things, or is there a different way that I should set globals? Thinking like if I want generic globals, but then later create custom tweaks for a few individual planets.

Thanks!

Looks good to me, sorry for the slow reply just remembered to check this thread.

[Sahadara]

I've noticed that when using SD alongside Kcalbeloh, Suluco's orientation is changed such that it doesn't have it's hot, desert side facing the sun. Seems to only happen when an actual scale factor is applied, so it's something about the way the scaling works rather than the mod just causing it to happen. Also noticed that Celestial Rescale doesn't seem to cause the same issue. Though I'd prefer to use SD as it seems to do a better job of scaling terrain. Anyone encountered this behavior and know how to fix? Thanks for any help!

Edit: Didn't notice that Kcalbeloh has a built in rescale functionality that prevents the issue. No more problem.

Edited August 12 by Sahadara

[Sigma88]

On 7/26/2024 at 11:26 PM, Zaxxon said:

Hi, thanks to those for making (and maintaining) this mod.  It might be just what I'm needing to make a RO/RP1 style play thru but with Kerbol solar system instead of RSS.  I've never made any module manager patch files before.  Would you mind telling me if I did this it the correct and most proper way?

What I did:
I did not change anything in the settings.cfg file in the SigmaDimensions folder.
I created a separate patch.cfg file and put it in its own directory under GameData.  Contents of that file I made are:

@Kopernicus:BEFORE[SigDim2]:NEEDS[SigDim]
{
    @Body:HAS[#name[*]]
    {
        @SigmaDimensions
        {
            @Resize = 3
            @Rescale = 3
            @Atmosphere = 1.25
            @dayLengthMultiplier = 2
            @landscape = 0.6
        }
    }
}

Example to scale up all bodies and orbital distance by 3x size.  It seems to have worked, but just trying to make sure I'm doing it the "right practices" way.  Thanks!

And is the: @Body:HAS[#name[*]] approach the best way to define the global settings in the patch file for all things, or is there a different way that I should set globals? Thinking like if I want generic globals, but then later create custom tweaks for a few individual planets.

Thanks!

this uses the syntax from the planet specific changes, while this looks ok it might be simpler to just change the values once patching the SD node

 

something like this:

@SigmaDimensions
{
	// Base Settings

	@Resize = 3
	@Rescale = 3
	@Atmosphere = 1.25
	@dayLengthMultiplier = 2


	// Advanced Settings

	@landscape = 0.6
}

 

[OhioBob]

On 5/29/2024 at 5:55 PM, Sigma88 said:

the harcoded name "Kerbin" was because at the time the name of the homeplanet needed to be "Kerbin" (you could change the displayName but the actual name needed to be "Kerbin" for some reason)

 

as for the fix, I'm not sure if it was for ISP or for the atmospheres of other planets being calculated based on the home planet, (so if you change the atmospheric curve of kerbin to be identical to duna, both kerbin and duna would display atmosphere of 1 atm rather than whatever fraction of 1 atm duna's atmosphere is)

✔️

@R-T-B, @CashnipLeaf

I recall that problem rather vividly, though I'm not familar with the fixes to the code.  I don't really remember changes being made to Sigma Dimensions, but I do recall discussions regarding Kopernicus.  I was more concerned with Kopernicus at the time and brought these issues to Sigma88, who promptly implemented fixes.

Just to provide a little more history, the following describes the situation as it existed several years ago when the changes where made.  I can't guarantee things are today as they were then.

As I recall, KSP defines 1 atmosphere as being equal to Kerbin's staticPressureASL, which is a setting in Kerbin's config and is normally equal to 101.325 kPa.  This comes into play in couple of places, (1) when determining engine ISP and (2) when displaying a planet's atmospheric pressure in the Tracking Station.

The first of these is an issue because the curves that look up engine ISP do so using pressure in atmospheres, but those curves are calibrated such that 1 atmosphere = 101.325 kPa.  Let's say we change the atmospheric pressure of the home world to 202.65 kPa (i.e. staticPressureASL = 202.65).  As far as KSP is concerned, 1 atmosphere now equals 202.65 kPa, but the ISP curves are not recalibrated accordingly.  So if a rocket engine is operating in a condition where the ambient pressure is 101.325 kPa, KSP is going to compute this as 101.325/202.65 = 0.5 atm and look up the ISP for that pressure.  But the ISP curves are calibrated so that 101.325 kPa is 1 atm, not 0.5 atm, therefore we'll get an ISP that's too high for the condition.

The second issue is as Sigma has already described.  Without any fix, the Tracking Station will always display Kerbin's atmospheric pressure as 1 atmosphere regardless of what the value is in kPa, and other planets' pressure will be relative to this.  In stock KSP Kerbin's pressure is displayed as 1 atm and Eve's pressure is 5 atm.  But if we change Kerbin's staticPressureASL to 202.65, then Kerbin's pressure would be displayed as 1 atm and Eve's as 2.5 atm, which is confusing.

The fixes implemented where intended to always define 1 atmosphere as 101.325 kPa.  This would fix the engine ISP problem and assure that the Tracking Station always displays atmospheric pressures in the familiar "earth standard atmospheres", rather than having the definition change from planet pack to planet pack.

[Sigma88]

On 8/23/2024 at 6:44 PM, OhioBob said:

@R-T-B, @CashnipLeaf

I recall that problem rather vividly, though I'm not familar with the fixes to the code.  I don't really remember changes being made to Sigma Dimensions, but I do recall discussions regarding Kopernicus.  I was more concerned with Kopernicus at the time and brought these issues to Sigma88, who promptly implemented fixes.

Just to provide a little more history, the following describes the situation as it existed several years ago when the changes where made.  I can't guarantee things are today as they were then.

As I recall, KSP defines 1 atmosphere as being equal to Kerbin's staticPressureASL, which is a setting in Kerbin's config and is normally equal to 101.325 kPa.  This comes into play in couple of places, (1) when determining engine ISP and (2) when displaying a planet's atmospheric pressure in the Tracking Station.

The first of these is an issue because the curves that look up engine ISP do so using pressure in atmospheres, but those curves are calibrated such that 1 atmosphere = 101.325 kPa.  Let's say we change the atmospheric pressure of the home world to 202.65 kPa (i.e. staticPressureASL = 202.65).  As far as KSP is concerned, 1 atmosphere now equals 202.65 kPa, but the ISP curves are not recalibrated accordingly.  So if a rocket engine is operating in a condition where the ambient pressure is 101.325 kPa, KSP is going to compute this as 101.325/202.65 = 0.5 atm and look up the ISP for that pressure.  But the ISP curves are calibrated so that 101.325 kPa is 1 atm, not 0.5 atm, therefore we'll get an ISP that's too high for the condition.

The second issue is as Sigma has already described.  Without any fix, the Tracking Station will always display Kerbin's atmospheric pressure as 1 atmosphere regardless of what the value is in kPa, and other planets' pressure will be relative to this.  In stock KSP Kerbin's pressure is displayed as 1 atm and Eve's pressure is 5 atm.  But if we change Kerbin's staticPressureASL to 202.65, then Kerbin's pressure would be displayed as 1 atm and Eve's as 2.5 atm, which is confusing.

The fixes implemented where intended to always define 1 atmosphere as 101.325 kPa.  This would fix the engine ISP problem and assure that the Tracking Station always displays atmospheric pressures in the familiar "earth standard atmospheres", rather than having the definition change from planet pack to planet pack.

yes I remember now that this was the original purpose of the fix, I can't really say if the fix is still necessary or if with the new ksp updates it is no longer required