Sigma Dimensions

[Sigma88]

7 hours ago, RocketRyleigh said:

Thank you very much for this information thunder175, it's much appreciated, especially that the 3.2x rescale calculations are included as I just decided to start there instead for my first scaled up career.

Glad this thread is so active; you're all very helpful.

Edit: Might as well just ask this in this post while I'm here.

From what I understand, this might not be necessary at this scale, but I like consistency; what settings for Atmosphere rescale and atmoTopLayer would be best for a "realistic" upper atmosphere (more gradual increase from space) and overall atmosphere height at 3.2x scale? 

iirc @OhioBob settled on:

(for 10x)

Resize = 10
Atmosphere = 1.25
atmoTopLayer = 1.4

 

so, for 3.2x it would be:

Resize = 3.2
Atmosphere = 1.08 1.061
atmoTopLayer = 1.128 1.098

 

I haven't tried these settings tho, so they might need a bit of tweaking

(EDIT: I goofed the interpolation)

Edited February 20, 2017 by Sigma88

[thunder175]

7 hours ago, RocketRyleigh said:

From what I understand, this might not be necessary at this scale, but I like consistency; what settings for Atmosphere rescale and atmoTopLayer would be best for a "realistic" upper atmosphere (more gradual increase from space) and overall atmosphere height at 3.2x scale? 

Before we got the atmoTopLayer setting, I always had atmosphere = 1.2857 which gave me 89.999km atmosphere for my 3.2x Kerbin. After finding some other posts on here (check the RealisticAtmosphere thread) I settled on atmosphere 1.14 and atmoTopLayer 1.153. With those settings, the atmospheric boundary is at just over 92km which I feel is 'right' for a 6.4x Kerbin. You'll get some drag but at those settings you won't start glowing and slowing until much deeper in the atmosphere. The biggest benefit to that is that you don't hit a wall of atmosphere. Ultimately its up to you what feels 'right' because in reality at low altitudes you'll be getting serious drag force effects. I like those settings since if you dip a satellite below 92km it won't immediately explode due to overheating but will have induced drag force causing a change in the semi-major axis.

[RocketRyleigh]

6 hours ago, Sigma88 said:

iirc @OhioBob settled on:

(for 10x)

Resize = 10
Atmosphere = 1.25
atmoTopLayer = 1.4

 

so, for 3.2x it would be:

Resize = 3.2
Atmosphere = 1.08 1.061
atmoTopLayer = 1.128 1.098

 

I haven't tried these settings tho, so they might need a bit of tweaking

(EDIT: I goofed the interpolation)

 

36 minutes ago, thunder175 said:

Before we got the atmoTopLayer setting, I always had atmosphere = 1.2857 which gave me 89.999km atmosphere for my 3.2x Kerbin. After finding some other posts on here (check the RealisticAtmosphere thread) I settled on atmosphere 1.14 and atmoTopLayer 1.153. With those settings, the atmospheric boundary is at just over 92km which I feel is 'right' for a 6.4x Kerbin. You'll get some drag but at those settings you won't start glowing and slowing until much deeper in the atmosphere. The biggest benefit to that is that you don't hit a wall of atmosphere. Ultimately its up to you what feels 'right' because in reality at low altitudes you'll be getting serious drag force effects. I like those settings since if you dip a satellite below 92km it won't immediately explode due to overheating but will have induced drag force causing a change in the semi-major axis.

Thanks a lot to both of you. I was leaning towards a higher atmosphere for the challenge so I'll check out the 92km settings and go from there. Between your suggestions I've definitely got enough info to work with.

[OhioBob]

I've done only minimal testing with it, but below are the settings that we're using for GPP.  The other suggestions you've received might work just as well, or maybe even better.  Just try them out an see what you like best.

Resize = 3.2
Rescale = 3.2
Atmosphere = 1.12
atmoTopLayer = 1.25
atmoVisualEffect = 1.12

 

Resize = 6.4
Rescale = 6.4
Atmosphere = 1.2
atmoTopLayer = 1.333333333
atmoVisualEffect = 1.2

 

Resize = 10
Rescale = 10
Atmosphere = 1.25
atmoTopLayer = 1.44
atmoVisualEffect = 1.25

 

These changes result in the overall atmosphere height being changed by factors of 1.4, 1.6 and 1.8 respectively.
 

Edited February 20, 2017 by OhioBob

[RocketRyleigh]

5 hours ago, OhioBob said:

I've done only minimal testing with it, but below are the settings that we're using for GPP.  The other suggestions you've received might work just as well, or maybe even better.  Just try them out an see what you like best.

Resize = 3.2
Rescale = 3.2
Atmosphere = 1.12
atmoTopLayer = 1.25
atmoVisualEffect = 1.12

 

Resize = 6.4
Rescale = 6.4
Atmosphere = 1.2
atmoTopLayer = 1.333333333
atmoVisualEffect = 1.2

 

Resize = 10
Rescale = 10
Atmosphere = 1.25
atmoTopLayer = 1.44
atmoVisualEffect = 1.25

 

These changes result in the overall atmosphere height being changed by factors of 1.4, 1.6 and 1.8 respectively.
 

Thanks very much for those numbers OhioBob! 

I'm just getting around to Kerbal now so I'm going to test out all of the suggestions I've gotten from this awesome thread! I'm glad that it's this active (and that Sigma88 is so present in the thread as well), as I really need SD for my rescaling because of its landscape scaling (even just retaining the geography; the other non-RSS rescale mod I tried was Harder Solar System, and it suffered from the stretched/flattened geography issue as well). Edit: Also it's just an amazingly configurable mod...

Now to launch a few sounding rockets to find my ideal settings!

Edited February 20, 2017 by RocketRyleigh
Not enough love

[eberkain]

So Kerbal Konstructs does seem to work alongside Sigma Dimensions fine, but the relative position of added buildings to one another is wrong, is there a way to fix that?

You can see all the added structures from Kerbinside in the distance

 

And the KSC floodlights are pushed way back

 

Its the same with other launch sites, the launch pads work, but nearby buildings are far off.   

I'm using the recently posted 6.4 settings, is there perhaps something I'm missing or is there just no fix? 

SigmaDimensions
{
	// Base Settings

	Resize = 6.4
	Rescale = 6.4
	Atmosphere = 1.2
	dayLengthMultiplier = 1


	// Advanced Settings

	landscape = 1
	geeASLmultiplier = 1

	resizeScatter = 1
	resizeBuildings = 0

	CustomSoISize = 0
	CustomRingSize = 0

	atmoASL = 1
	tempASL = 1
	atmoTopLayer = 1.3333333
	atmoVisualEffect = 1.2

	scanAltitude = 1
}

 

[Sigma88]

1 hour ago, eberkain said:

So Kerbal Konstructs does seem to work alongside Sigma Dimensions fine, but the relative position of added buildings to one another is wrong, is there a way to fix that?

You can see all the added structures from Kerbinside in the distance

 

And the KSC floodlights are pushed way back

 

Its the same with other launch sites, the launch pads work, but nearby buildings are far off.   

I'm using the recently posted 6.4 settings, is there perhaps something I'm missing or is there just no fix? 

SigmaDimensions
{
	// Base Settings

	Resize = 6.4
	Rescale = 6.4
	Atmosphere = 1.2
	dayLengthMultiplier = 1


	// Advanced Settings

	landscape = 1
	geeASLmultiplier = 1

	resizeScatter = 1
	resizeBuildings = 0

	CustomSoISize = 0
	CustomRingSize = 0

	atmoASL = 1
	tempASL = 1
	atmoTopLayer = 1.3333333
	atmoVisualEffect = 1.2

	scanAltitude = 1
}

 

the issue here is this:

KK buildings are positioned using "latitude and longitude"

when you change the size of the planet those points get farther apart (or closer, depending how you resize)

 

there are 2 solutions for this problem:

1- change the size of the buildings by the same factor as the planet. this way the relative proportions will be maintained

2- use the group feature of SD (described here) to "link" some statics together (this feature is still at a very early developmental stage)

[eberkain]

8 hours ago, Sigma88 said:

use the group feature of SD (described here) to "link" some statics together (this feature is still at a very early developmental stage)

I read everything from that point forward and didn't see any other talk, so I'm guessing noone has made groups for Kerbin Side yet?

[Sigma88]

2 minutes ago, eberkain said:

I read everything from that point forward and didn't see any other talk, so I'm guessing noone has made groups for Kerbin Side yet?

no you need to define the groups yourself. the feature is there to correctly move the building that are grouped together but you still need to tell it which buildings go with which

[eberkain]

13 hours ago, Sigma88 said:

no you need to define the groups yourself. the feature is there to correctly move the building that are grouped together but you still need to tell it which buildings go with which

So there isn't really any instructions for the layperson.   

I can see KSide buildings are defined like this.  

STATIC
{
	mesh = ksidecontroltower4.mu
	module = Part
	category = Airbases
	author = AlphaAsh
	static = true
	cost = 0
	title = Control Tower Type 4
	manufacturer = KashCorp
	description = Helps planes.
	pointername = ksidecontroltower4
	name = KSideBases_GreenBasin_ksidecontroltower4
	Instances
	{
		CelestialBody = Kerbin
		RadialPosition = -597423.3,-67159.97,-14281.13
		Orientation = 0,1,0
		RadiusOffset = 1472.91
		RotationAngle = 140
		RefLatitude = -6.412221
		RefLongitude = 181.3694
		VisibilityRange = 25000
		Group = GreenBasin
		LaunchSiteDescription = No description available
		Category = Other
		FacilityType = None
		CustomInstance = True
		LaunchSiteName = 
	}
}

My best guess is to do something like this...

PQSCity_Groups
{
	Group
	{
		name = KSide_GreenBasin_PCG
		body = Kerbin

		CentralPQSCity = KSideBases_GreenBasin_ksidemountainvabsmall
		CentralPosition = -597407.5,-67276.01,-13882.11
		CentralLAT = -6.423476
		CentralLON = 181.3312

		PQSCity = KSideBases_GreenBasin_ksidecontroltower4
		PQSCity = KSideBases_GreenBasin_ksidekashcorp
		PQSCity = KSideBases_GreenBasin_ksidevabsph2
		PQSCity = KSideBases_GreenBasin_ksidecawler1
	}
}

But that just made my rocket spawn way underground, and did nothing to put the buildings back at a correct relative distance. 

[Sigma88]

1 hour ago, eberkain said:

So there isn't really any instructions for the layperson.

I didn't have much time earlier that's why I didn't go in detail. Now I have some more time so here are some tips:

 

1- you only need to define the center once, you have defined the position of the center 3 times in your cfg, which is superfluous

2- you need to use the names of the PQS Mods, not the names of the statics (defined by KK)

 

to get the name of a PQS Mod you need to do the following:

add KittopiaTech to your mod list and run KSP

using Kittopia, select the planet you are working on (Kerbin) go to the page relative to PQS Mods, and look at all the PQSCity mods

when you select a PQSCity mod you can see its "name", that's what you need to use in the cfg

 

to make it easier for you to spot the correct pqscity mods I suggest you make a backup of your KK folder, then delete all the statics except for those in the same group.

so when you launch KSP you will have only the statics in the same group, making it easier to find out which names they have

 

DISCLAIMER 1

I have no idea what would happen if more than one PQSCity mod have the same name, I did not consider that possibility when coding so I have no idea what would happen in that case.

 

DISCLAIMER 2

if the group you are defining is made of statics that load around a stock building (eg. Kerbal Space Center), you will need to use that building as the central position for the group (for KSC you should use:

CentralPQSCity = KSC

[eberkain]

On 4/12/2016 at 11:47 AM, Sigma88 said:

ito get the mass of the rescaled planet you need to do this:

mass of the rescaled planet = mass of the old planet * (Resize ^ 2)

 

Thanks for this, I was starting to go crazy, turns out I was just calculating the scaled mass wrong. 

[Sigma88]

47 minutes ago, eberkain said:

Thanks for this, I was starting to go crazy, turns out I was just calculating the scaled mass wrong. 

why do you need to calculate the mass?

 

PS: did you manage to make the PQSCity groups work?

Edited March 2, 2017 by Sigma88

[eberkain]

Ultimately I had to pull Kerbal Konstructs from my install, it just seems to hit my performance too much, regardless of scale.  The other day I installed GPP which has a 6.4x scale bundled.  I played around in it for a while and decided that is what I want to do for my new career game.  There is no 6.4 scale delta v map that I am aware of right now.  I thought about it for a while and I decided to just add a sheet to my logbook about the planets.  

https://docs.google.com/spreadsheets/d/1JTfMDEn7UeBsPZoiL_CGK77bNoDUOTTpWvKRCWDN3gw/edit#gid=1275207847

Maybe you can tell me why my math on orbital velocity isn't coming out right.

[Sigma88]

1 hour ago, eberkain said:

Ultimately I had to pull Kerbal Konstructs from my install, it just seems to hit my performance too much, regardless of scale.  The other day I installed GPP which has a 6.4x scale bundled.  I played around in it for a while and decided that is what I want to do for my new career game.  There is no 6.4 scale delta v map that I am aware of right now.  I thought about it for a while and I decided to just add a sheet to my logbook about the planets.  

https://docs.google.com/spreadsheets/d/1JTfMDEn7UeBsPZoiL_CGK77bNoDUOTTpWvKRCWDN3gw/edit#gid=1275207847

Maybe you can tell me why my math on orbital velocity isn't coming out right.

EDIT: deleted old reply

 

new reply:

 

orbital speed is 6043m/s but if you account for the rotation of the surface (446 m/s) the orbital speed is reduced to 5597 m/s (which is closer to your empirical data)

Edited March 2, 2017 by Sigma88

[eberkain]

7 hours ago, Sigma88 said:

EDIT: deleted old reply

 

new reply:

 

orbital speed is 6043m/s but if you account for the rotation of the surface (446 m/s) the orbital speed is reduced to 5597 m/s (which is closer to your empirical data)

Dude, you are awesome.   

[eberkain]

So the game has two options for displaying time, either Kerbin Time (6 hour/day 426 days/year ) or Earth Time (24 hour/day 365days/year).  What I am finding is that regardless of the DayLengthMultiplier the timer will still turnover at that interval.  We need a third option for Local Time, where it would just do an hours per day and days per year cycle that was based on the home planets actual orbital parameters.  I'm not sure if that is even possible, so if I want the actual solar system movement to synchronize with the day counter I have to use one of the two time display options.   

So I was going to try and figure out what the rescale and day length multiplier need to be for Gael to exactly match a 24 hour day and 365 day year cycle in the solar system simulation.  With no scale applied Gael shows this in the tracking center.  

Orbit Altitude 13,913,379,719m

Rotation Period 5h 59m 9s

My math says that a rescale around 7.21 and a daylengthmultiplier of 4 should put me real close, but when I try a practical test.  Go to the tracking center, target the sun, zoom out and fix camera overhead, mark Gael's position with a UI element, timewarp 1 full year....   Gael passes the marked position around 320 days... 

Another wrench could be that I don't know if ksp is programmed for the Earth Time scale to be a rounded even 24 hours 365 days, or if it uses the actual numbers. 

Want to assist with another math problem?

Edited March 3, 2017 by eberkain

[Galileo]

28 minutes ago, eberkain said:

So the game has two options for displaying time, either Kerbin Time (6 hour/day 426 days/year ) or Earth Time (24 hour/day 365days/year).  What I am finding is that regardless of the DayLengthMultiplier the timer will still turnover at that interval.  We need a third option for Local Time, where it would just do an hours per day and days per year cycle that was based on the home planets actual orbital parameters.  I'm not sure if that is even possible, so if I want the actual solar system movement to synchronize with the day counter I have to use one of the two time display options.   

So I was going to try and figure out what the rescale and day length multiplier need to be for Gael to exactly match a 24 hour day and 365 day year cycle in the solar system simulation.  With no scale applied Gael shows this in the tracking center.  

Orbit Altitude 13,913,379,719m

Rotation Period 5h 59m 9s

My math says that a rescale around 7.21 and a daylengthmultiplier of 4 should put me real close, but when I try a practical test.  Go to the tracking center, target the sun, zoom out and fix camera overhead, mark Gael's position with a UI element, timewarp 1 full year....   Gael passes the marked position around 320 days... 

Another wrench could be that I don't know if ksp is programmed for the Earth Time scale to be a rounded even 24 hours 365 days, or if it uses the actual numbers. 

Want to assist with another math problem?

It is possible with kopernicus time. We plan on using it in the next update of GPP.  It does exactly what you want

[eberkain]

21 minutes ago, Galileo said:

It is possible with kopernicus time. We plan on using it in the next update of GPP.  It does exactly what you want

That is great to hear.  Ultimately its a minor thing, but I want to know a year is actually a year when I start logging my career game.  

[Sigma88]

6 hours ago, eberkain said:

Another wrench could be that I don't know if ksp is programmed for the Earth Time scale to be a rounded even 24 hours 365 days, or if it uses the actual numbers. 

earth time is:

1 day = 86400 s  (24 hrs)
1 year = 31536000 s  (365 days)

 

kerbin time is:

1 day = 21600 s  (6 hrs)
1 year = 9201600 s (426 days)

 

these are the numbers on the clock that are completely independent from the actual rotatio/revolution periods of the home planet

as Galileo mentioned there is a feature in Kopernicus that links the home planet rotation/revolution to the clock, which is what you were asking for.

 

regarding your math problem, since the standard rotation period of Gael is 6 hrs, to make it 24hrs you just need to multiply by 4

 

something worth noting is that for kerbin squad defines the rotation period by setting the "solar day length" rather than the "sideral day length"

this is important because you want the solar day to match the clock, and not the sideral day.

I've taken a look at GPP config and it uses the solar day as well, so there should not be issues if you set the daylengthmultiplier to 4

[ParasciHHO]

FPS drops a lot after installing this. Is it supposed to be that way or I installed it incorrectly?

[Jimmy Stiff-Fingers]

First of all I want to thank Sigma for this mod. I'm looking forward to start a 10x game. I'm a total noob in all of this, I entered these numbers. Is there anything I have missed to get a proper 10x system?

SigmaDimensions
{
    // Base Settings

    Resize = 10
    Rescale = 10
    Atmosphere = 1.25
    dayLengthMultiplier = 4

    // Advanced Settings

    landscape = 1
    geeASLmultiplier = 1

    resizeScatter = 1
    resizeBuildings = 0

    CustomSoISize = 0
    CustomRingSize = 0

    atmoASL = 1
    tempASL = 1
    atmoTopLayer = 1.44
    atmoVisualEffect = 1.25

    scanAltitude = 1
}

 

Stupid bonus question: could I use this tool of planet altering magick in some way to remove the ocean on Eve?

Edited March 18, 2017 by Jimmy Stiff-Fingers

[Sigma88]

@Jimmy Stiff-Fingers settings look fine, are you having problems with it?

 

and no, SD cannot remove oceans, you would need to work with kopernicus to do that, and probably export new maps for Eve using KittopiaTech

[Jimmy Stiff-Fingers]

1 minute ago, Sigma88 said:

@Jimmy Stiff-Fingers settings look fine, are you having problems with it?

 

and no, SD cannot remove oceans, you would need to work with kopernicus to do that, and probably export new maps for Eve using KittopiaTech

Ah okay, great. Thanks. At to moment I haven't encounterd any problems, yet.

 

Time to start a proper space program.

[Sigma88]

2 minutes ago, Jimmy Stiff-Fingers said:

Ah okay, great. Thanks. At to moment I haven't encounterd any problems, yet.

 

Time to start a proper space program.

the only issue I could see is that at 10x  mountains on Kerbin will be 80km high

you can change that by using the "landscape" parameter if you think they are too big