Sigma Dimensions

[Sigma88]

15 minutes ago, davidy12 said:

The main problem I'm seeing are the clouds are at 30,000m!!!!!

clouds get rescaled with planet size, so they are always at the same relative distance from the center of the planet

I don't know on which system you are playing, but:

30000/ResizedRadius = NormalCloudsAltitude/NormalRadius

[davidy12]

6.4K. 

They seemed lower in 1.0.5.

[Sigma88]

10 minutes ago, davidy12 said:

6.4K. 

They seemed lower in 1.0.5.

maybe EVE has changed the config structure?

where did you download the clouds you are using?

[davidy12]

Just now, Sigma88 said:

maybe EVE has changed the config structure?

where did you download the clouds you are using?

SVE. But it was the same with the default EVE.

[Napoleon440]

1 hour ago, Sigma88 said:

yeah I never understood why exactly that was a problem, since in stock the atmosphere altitude is 70k and the inverseRotThreshold is 100k

I will try to test the issue and see if I can find a solution

Yep, just doing some trial and error checking the results in the Module Manager cache, I've been able to confirm that with both lines commented out, it defaults to 100k, and then with an Atmosphere value of 1.285, it moves to 128.5k. In fact, it looks like it's 100k for all bodies. I changed line 8 to:

@inverseRotThresholdAltitude = #$../Atmosphere/atmosphereDepth$

This sets the warp threshold at the height of each planet's atmosphere. So far, it seems to be working, and looks like it is correct for the other planets with atmospheres in the Module Manager cache. I'll keep testing and let you know if anything weird comes up, but that may do the trick.

[Sigma88]

1 hour ago, davidy12 said:

SVE. But it was the same with the default EVE.

SVE has the altitude set at 4000 so on 6.4x the altitude gets increased to 25.6 km

A lower altitude would mean the clouds could clip through the terrain

[Sigma88]

1 hour ago, Napoleon440 said:

Yep, just doing some trial and error checking the results in the Module Manager cache, I've been able to confirm that with both lines commented out, it defaults to 100k, and then with an Atmosphere value of 1.285, it moves to 128.5k. In fact, it looks like it's 100k for all bodies. I changed line 8 to:

@inverseRotThresholdAltitude = #$../Atmosphere/atmosphereDepth$

This sets the warp threshold at the height of each planet's atmosphere. So far, it seems to be working, and looks like it is correct for the other planets with atmospheres in the Module Manager cache. I'll keep testing and let you know if anything weird comes up, but that may do the trick.

yes, that's what I wanted to try myself, I'm glad to hear it works

btw, all stock bodies have inverseRotThresholdAltitude = 100k

except jool which has inverseRotThresholdAltitude = 1000k

(yes, even the sun has 100k)

[Sigma88]

@Napoleon440 I think I know what your problem was

what did you set the "dayLengthmultiplier" to?

if you set it at "1" like @GreenWolf suggested that might be too low (you have a 6.4x size kerbin rotating in 6 hours) you should bring that up to about ~4ish

that might be the reason why you were getting those "cannottimewarp" issues

[Napoleon440]

That seems to have done the trick as well. Any idea why rotational period would cause the problem?

[Sigma88]

51 minutes ago, Napoleon440 said:

That seems to have done the trick as well. Any idea why rotational period would cause the problem?

do you mean "any idea why rotation period would cause issues with a shift from a rotating reference frame to a fixed reference frame?"

 

jokes aside, I don't know why it would, but it seems reasonable

Edited May 2, 2016 by Sigma88

[Napoleon440]

I used to think I was smart until I started playing KSP. I guess the only question I have left is, should the daylengthmultiplier value be tied to one of the other multipliers since leaving it as-is causes the problem, or is the workaround with atmo height a better fix. Seems like messing with day length could have some [un]intended consequences for synchronous orbits among other things.

[Sigma88]

50 minutes ago, Napoleon440 said:

I used to think I was smart until I started playing KSP. I guess the only question I have left is, should the daylengthmultiplier value be tied to one of the other multipliers since leaving it as-is causes the problem, or is the workaround with atmo height a better fix. Seems like messing with day length could have some [un]intended consequences for synchronous orbits among other things.

I've decided to let it be a different parameter because people can get pretty nitpicky about that kind of stuff and there are many ways to approach rotation period modifications.

but you definitely need to change it when you rescale a planet. if you use 6.4x resize a 4x dayLengthMulti should work just fine

[HansB]

Also posted this in RSS

 

I'm using Sigma and now it throws some errors :
Applying node Sigma/Dimensions/Configs/ReDimension/setKSCSwitcher/@KSCSWITCHER:FOR[SigDim2] to KSCSwitcher/LaunchSites/KSCSWITCHER
[ModuleManager] Error - Failed to do a maths replacement: @PQSMod_MapDecalTangent : original value="80E" operator=* mod value="0.9255"
[ModuleManager] Error - Failed to do a maths replacement: @PQSMod_MapDecalTangent : original value="0" operator=+ mod value="80E"

When i search for that 80E it's here:

name = jp_tanegashima
            displayName = JP - Tanegashima
            description = The Tanegashima Space Center (種子島宇宙センター, Tanegashima Uchū Sentā) (TNSC) is a Japanese space development facility. It is located on Tanegashima, an island located 115 km south of Kyushu. It was established in 1969 when the National Space Development Agency of Japan (NASDA) was formed, and is now run by JAXA. The activities that take place at TNSC include assembly, testing, launching and tracking of satellites, as well as rocket engine firing tests. It is Japan's largest space development center.
            PQSCity
            {
                KEYname = KSC
                latitude = 30.39096
                longitude = 130.96813
                repositionRadiusOffset = 71
                repositionToSphereSurface = false
                lodvisibleRangeMult = 6
                reorientFinalAngle = -221
            }
            PQSMod_MapDecalTangent
            {
                radius = 5500
                heightMapDeformity = 80E
                absoluteOffset = 0
                absolute = true
                latitude = 30.39096
                longitude = 130.96813
            }

I guess it's a typo????

 

Is it also possible to change the versioning to 1.1.2,  KSP-AVC always pops up, pfffffff

Edited May 3, 2016 by HansB

[Sigma88]

33 minutes ago, HansB said:

Also posted this in RSS

 

I'm using Sigma and now it throws some errors :
Applying node Sigma/Dimensions/Configs/ReDimension/setKSCSwitcher/@KSCSWITCHER:FOR[SigDim2] to KSCSwitcher/LaunchSites/KSCSWITCHER
[ModuleManager] Error - Failed to do a maths replacement: @PQSMod_MapDecalTangent : original value="80E" operator=* mod value="0.9255"
[ModuleManager] Error - Failed to do a maths replacement: @PQSMod_MapDecalTangent : original value="0" operator=+ mod value="80E"

When i search for that 80E it's here:

name = jp_tanegashima
            displayName = JP - Tanegashima
            description = The Tanegashima Space Center (種子島宇宙センター, Tanegashima Uchū Sentā) (TNSC) is a Japanese space development facility. It is located on Tanegashima, an island located 115 km south of Kyushu. It was established in 1969 when the National Space Development Agency of Japan (NASDA) was formed, and is now run by JAXA. The activities that take place at TNSC include assembly, testing, launching and tracking of satellites, as well as rocket engine firing tests. It is Japan's largest space development center.
            PQSCity
            {
                KEYname = KSC
                latitude = 30.39096
                longitude = 130.96813
                repositionRadiusOffset = 71
                repositionToSphereSurface = false
                lodvisibleRangeMult = 6
                reorientFinalAngle = -221
            }
            PQSMod_MapDecalTangent
            {
                radius = 5500
                heightMapDeformity = 80E
                absoluteOffset = 0
                absolute = true
                latitude = 30.39096
                longitude = 130.96813
            }

I guess it's a typo????

 

Is it also possible to change the versioning to 1.1.2,  KSP-AVC always pops up, pfffffff

Yes that is a typo, I blame @KillAshley

The version is not yet 1.1.2 because I still need to change some configs before updating the mod

[KillAshley]

2 minutes ago, Sigma88 said:

Yes that is a typo, I blame @KillAshley

The version is not yet 1.1.2 because I still need to change some configs before updating the mod

wasnt me, thats a new typo by someone else

Edited May 3, 2016 by KillAshley

[Sigma88]

Just now, KillAshley said:

wasnt me, thats an old typo

I still blame you

[Sigma88]

Ok guys, I've finished updating SD to 1.1.2

if no bugs are reported I should be able to release the new version today

so, if you have seen bugs, now would be the best moment to report them

[Napoleon440]

The only other issue I've had is re-entry is absolutely killing me. Ablator is burning up (200 units on the procedural heat shields) on re-entry just from low orbit on my 6.4x scale while still pulling almost lethal G's with Deadly Re-Entry. I was digging through RO-Mini to see how it's handled there since I wasn't having the issue when I tinkered with RSS recently. I was going to try and add something like this to see if it helped:

// Heat shields
@PART[*]:HAS[@MODULE[ModuleAblator]]
{
    @MODULE[ModuleAblator]
    {
        @lossConst *= 0.1 //I'm thinking should be 1/x where x is one of the SD config values
    }
}

Haven't had a chance to actually test it yet, but was going to check it out later tonight.

 

[blowfish]

@Napoleon440 You could also try reducing re-entry heat in the settings.  Stock heating is tuned to provide an interesting experience in the stock solar system.  In 6.4x you're going a lot faster on re-entry so heat is going to be unmanageable.  You could also try RealHeat (realistic heating will be slightly easier than real life in a 6.4x system).

[Sigma88]

6 minutes ago, Napoleon440 said:

The only other issue I've had is re-entry is absolutely killing me. Ablator is burning up (200 units on the procedural heat shields) on re-entry just from low orbit on my 6.4x scale while still pulling almost lethal G's with Deadly Re-Entry. I was digging through RO-Mini to see how it's handled there since I wasn't having the issue when I tinkered with RSS recently. I was going to try and add something like this to see if it helped:

// Heat shields
@PART[*]:HAS[@MODULE[ModuleAblator]]
{
    @MODULE[ModuleAblator]
    {
        @lossConst *= 0.1 //I'm thinking should be 1/x where x is one of the SD config values
    }
}

Haven't had a chance to actually test it yet, but was going to check it out later tonight.

 

I've added  new cfg in the dev version to change reentry heating

Try to use that one, you should find it works better than the release version

[Napoleon440]

Yeah, I've got Real Heat and have been running off the dev version of SD. I was hoping to find a way that felt a little less "cheaty". I've been looking for way to raise the max amount of ablator on heat shields so they just hold more, or reducing the rate it burns off. In both instances, mass would be added proportionally to offset the change making it "not cheaty". Anyway, that's just me. I'm one of the types that likes the added challenge of a 6.4x scale, but isn't quite ready to tackle RSS/RO. Plus, I really do like the stock system and parts. 

Edited May 3, 2016 by Napoleon440

[Akira_R]

I'm using the 64k rescale and SVE and the clouds are really high up there as some people have said, will changing the atmoVisualEffect parameter affect the height of the clouds? Or is the only way to fix it to go into the SVE cfgs and adjust all of the cloud heights?

 

EDIT: NVM did more searching and found my answer, thank you!

for those that are lazy, only way to change eve cloud heights is by editing the eve cloud cfg, this can be done with a MM patch

Edited May 4, 2016 by Akira_R

[Norcalplanner]

8 hours ago, Napoleon440 said:

Yeah, I've got Real Heat and have been running off the dev version of SD. I was hoping to find a way that felt a little less "cheaty". I've been looking for way to raise the max amount of ablator on heat shields so they just hold more, or reducing the rate it burns off. In both instances, mass would be added proportionally to offset the change making it "not cheaty". Anyway, that's just me. I'm one of the types that likes the added challenge of a 6.4x scale, but isn't quite ready to tackle RSS/RO. Plus, I really do like the stock system and parts. 

I've been using SMURFF with my 6.4x Sigma Dimensions game with a 0.5 lever.  It helps a lot with everything, but reentry in particular because it reduces the weight of both capsules and heatshields.  With less weight to slow down, heating isn't as bad.  I will note that I've adjusted heating with the stock slider down to 80 or 90%, and the combination of the slider and SMURFF means you don't have to worry about Real Heat or anything else which is more in depth.

[Sigma88]

5 hours ago, Akira_R said:

for those that are lazy, only way to change eve cloud heights is by editing the eve cloud cfg, this can be done with a MM patch

Sigma Dimensions changes the altitude of clouds using "Resize" as a multiplier

this way the clouds are always the same relative distance from the center (and surface) of the planet

 

to anyone having reentry problems:

I'm still learning how to properly tweak those parameters but, I have tested reentry on flat 10x resize / 10x Atmosphere comparing it with a similar reentry on 1x Size 1x Atmosphere and this is the result:

both test are done using a 3 part vessel

1. Mk1-2 Command Pod
2. Mk16-XL Parachute
3. 2.5 meter heat shield

in stock:

1. hyperedit the ship to a 100x25 orbit
2. reentry consumes about 1/3 heat shield

in 10x resize:

1. hyperedit to a 1000x250 orbit
2. reentry consumes about 2/3 heat shield

 

max temperature experienced are comparable

as far as I can tell any additional difficulty on reentry is caused by the setup (for example using an Atmosphere parameter lower than the Resize parameter)

this is kinda the whole point of using a resize, so I think it's a good balance.

I don't think I will introduce changes in the parts, since doing that would result in conflicts in other part mods like SMURFF

Edited May 4, 2016 by Sigma88

[ThorBeorn]

I am trying to import Earths atmosphere from RSS to a 10 x Kerbin using Sigma. However, I still get the scaled atmosphere from Sigma (using factor 1.5 in "Sigma/Dimensions/settings.cfg").

What am I doing wrong here?

@Kopernicus:Final
{	
	@Body[Kerbin]
	{
		@Properties
		{
			radius = 6371000 // 1/10:th of earth, later rescaled x10 by Sigma
		}
		@Atmosphere
		{
			AtmosphereFromGround
			{
				innerRadius = 6307290 // 0.99 	radius = 6371000 m
				outerRadius = 6530280 // 1.025	radius = 6371000 m
				waveLength = 0.65, 0.58, 0.5, 1.0
			}
			ambientColor = 0.05,0.05,0.05,1
			lightColor = 0.65, 0.58, 0.5, 1.0
			
			maxAltitude = 140000.0
			
			pressureCurve
			{
				key = 0 101.325 0 -0.0119728
				key = 1000 89.9533 -0.0107930 -0.0107930		
				key = 2000 79.7002 -0.00972796 -0.00972796
				key = 3000 70.4681 -0.00875299 -0.00875299
				key = 4000 62.1611 -0.00787622 -0.00787622
				key = 5000 54.6878 -0.00708318 -0.00708318
				key = 6000 47.9713 -0.00636065 -0.00636065
				key = 7000 41.9464 -0.00569841 -0.00569841
				key = 8000 36.5557 -0.00509245 -0.00509245
				key = 9000 31.7442 -0.00453808 -0.00453808
				key = 10000 27.4653 -0.00402673 -0.00402673
				key = 12000 20.3414 -0.00312263 -0.00312263
				key = 14000 14.8737 -0.00237047 -0.00237047
				key = 16000 10.7635 -0.00176010 -0.00176010
				key = 18000 7.75613 -0.00126803 -0.00126803
				key = 20000 5.60721 -0.000901039 -0.000901039
				key = 22000 4.07935 -0.000642531 -0.000642531
				key = 24000 2.98525 -0.000462105 -0.000462105
				key = 26000 2.19595 -0.000334419 -0.000334419
				key = 28000 1.62339 -0.000243181 -0.000243181
				key = 30000 1.20625 -0.000177515 -0.000177515
				key = 35000 0.587912 -8.24999E-05 -8.24999E-05
				key = 40000 0.296475 -3.95921E-05 -3.95921E-05
				key = 45000 0.154505 -1.96895E-05 -1.96895E-05
				key = 50000 0.0823932 -1.02964E-05 -1.02964E-05
				key = 55000 0.0438116 -5.63015E-06 -5.63015E-06
				key = 60000 0.0226627 -3.07308E-06 -3.07308E-06
				key = 65000 0.0112639 -1.62393E-06 -1.62393E-06
				key = 70000 0.00535122 -8.22379E-07 -8.22379E-07
				key = 75000 0.00242788 -3.93412E-07 -3.93412E-07
				key = 80000 0.00106419 -1.78176E-07 -1.78176E-07
				key = 85000 0.000456540 -7.80320E-08 -7.80320E-08
				key = 90000 0.000192994 -3.33998E-08 -3.33998E-08
				key = 95000 8.14506E-05 -1.38984E-08 -1.38984E-08
				key = 100000 3.54530E-05 -5.71581E-09 -5.71581E-09
				key = 105000 1.63277E-05 -2.42049E-09 -2.42049E-09
				key = 110000 8.14746E-06 -1.04679E-09 -1.04679E-09
				key = 115000 4.54713E-06 -4.77713E-10 -4.77713E-10
				key = 121920 2.39321E-06 -1.98618E-10 -1.98618E-10
				key = 140000 0 0 0
			}	
		}
	}
}

Edit: To be precise, this patch doesn't change Kerbins atmosphere. It remains at 70km x 1.5 = 105 km height. But I want it to be equal to Earths atmosphere, same height, same pressure at any given altitude etc. Oh and radius doesn't apply either, it remains at 6000 km after Sigma scales it.

Edited May 5, 2016 by ThorBeorn