Sigma Dimensions

[Karamon]

0 resize same as your Resize parameter, 1 and more is size of buildings and resize does not matter . 1 is default stock size

Edited December 8, 2016 by Karamon

[Sigma88]

9 minutes ago, Akira_R said:

That is kind of what I assumed as well however looking at the documentation in the OP it says that "building size is multiplied by this parameter" not multiplied by the Resize parameter so a setting of 1 shouldn't resize anything? if I'm understanding that correctly that is.

this is correct, you would need resizeBuildings = 10 to increase the size of buildings as much as the planet.

I think I know where the problem is, I'll try to get a fix out as soon as possible

[OhioBob]

7 hours ago, Walker said:

Thanks, @OhioBob, those are really helpful tips. I play KSP with 6.4 rescale and I was setting Atmosphere parameter at 1.33. Reentry from Mun felt as you described it. Now I'm going to try Atmosphere = 1.14 and atmoTopLayer = 1.17, see if it will be better

Yes, I think settings of 1.14 and 1.17 should improve things - with those settings the transition from space to atmosphere should less abrupt than you got by setting Atmosphere = 1.33.

Of course users can experiment with the settings until they find what ever makes them happy.  There's no one right way to play KSP, if bizarre and unnatural is what you want, then by all means go for it.  However, if you want to resize an atmosphere so that it behaves as realistically as possible, my recommendations are:

• If you are upsizing a celestial body, then for Resize = 1 to 10, you should set Atmosphere = 1 to 1.25, and atomTopLayer > 1.
• If you are downsizing a celestial body, then for Resize = 1 to 0.1, you should set Atmosphere = 1 to 0.8, and atomTopLayer < 1.

How much greater than or less than 1 you make atmoTopLayer is entirely up to you.  It should be based on what feels right to you in the game.  For example, let's say you're resizing Kerbin to 10x its stock size.  If you just want to soften the edge of the atmosphere a little bit so it doesn't seem quite so abrupt, then you might try Atmosphere = 1.25 and atmoTopLayer = 1.2, for a final height of 105 km.  On the other hand, perhaps the goal is to force your spacecraft into higher more lifelike orbits, then you might try Atmosphere = 1.25 and atmoTopLayer = 2, for a final height of 175 km.  In either case, the extended upper part of the atmosphere will have lifelike pressures and densities.
 

Edited December 8, 2016 by OhioBob

[JoseEduardo]

I wonder what would happen with  atmoTopLayer =  5 and having a station inside the atmosphere... would it have negligible drag?

[Eklykti]

I think it will just disappear when you go to space center

[OhioBob]

1 hour ago, JoseEduardo said:

I wonder what would happen with  atmoTopLayer =  5 and having a station inside the atmosphere... would it have negligible drag?

Yes, the drag would be exceedingly small, but not zero.  Eventually it would still cause the orbit to decay.  At least that's the real life case.  I'm not sure how the game would handle it, perhaps there's some minimum value below which it just goes to zero.  I don't know. 

In KSP, however, I would never recommend setting the atmosphere so high.  The problem is that high speed time warp in disabled inside an atmosphere.  It would make for a very slow game if you had to orbit while still inside an atmosphere.  Also, when the station is not the active vehicle, it's on rails.  So in that case it will orbit indefinitely without any drag effect.  Drag is simulated only when it is the active vehicle.
 

Edited December 8, 2016 by OhioBob

[OhioBob]

1 hour ago, Eklykti said:

I think it will just disappear when you go to space center

I believe it disappears only if it passes below some minimum, but I don't recall if the minimum is an altitude or a pressure level.  As long as its orbit is above the minimum, it will continue to orbit on rails even if inside an atmosphere.  But as soon as it passes below the minimum, it disappears.
 

Edited December 8, 2016 by OhioBob

[Sigma88]

1 hour ago, OhioBob said:

I believe it disappears only if it passes below some minimum, but I don't recall if the minimum is an altitude or a pressure level.  As long as it's orbit is above the minimum, it will continue to orbit on rails even if inside an atmosphere.  But as soon as it passes below the minimum, it disappears.

Minimum is 20km but you can't change ship while moving inside the atmosphere so the game would revert to the last safe place when you go to the space center

[Sigma88]

I've released Sigma Dimensions v0.7.2 which contains a small fix that should solve the issue reported by @JoseEduardo

as always,  all the links are available in the OP

Edited December 8, 2016 by Sigma88

[JoseEduardo]

thanks @Sigma88, it is working perfectly now!



KK got rescaled, but I can live with that, no problem

[Sigma88]

2 hours ago, JoseEduardo said:

thanks @Sigma88, it is working perfectly now!



KK got rescaled, but I can live with that, no problem

You should get KK buildings of the same size but far apart on the surface

This is because each kk building is positioned on its own lon/lat coordinates, and on a bigger sphere those coords are more distant from each other.

Me and @Ger_space are working on a solution

[Benji13]

What should I set atmoTopLayer to if I want the atmosphere to end at 80,000m? I know what to set it to if I was scaling the entire atmosphere (1.066666666666667 if your interested) but I only want top (thin) part of the atmo to get bigger/longer. Thanks,

Benji13.

[Sigma88]

1 hour ago, Benji13 said:

What should I set atmoTopLayer to if I want the atmosphere to end at 80,000m? I know what to set it to if I was scaling the entire atmosphere (1.066666666666667 if your interested) but I only want top (thin) part of the atmo to get bigger/longer. Thanks,

Benji13.

depends on what the original planet's atmosphere is.

on stock kerbin it's 70000 so if you have Atmosphere = 1 you will need atmoTopLayer = 1.142857142857 to have the atmosphere reach 80km

[Benji13]

4 hours ago, Sigma88 said:

depends on what the original planet's atmosphere is.

on stock kerbin it's 70000 so if you have Atmosphere = 1 you will need atmoTopLayer = 1.142857142857 to have the atmosphere reach 80km

Thanks  

[Sigma88]

Sigma Dimensions v0.7.3

New feature that adds the possibility to define groups of PQSCity and PQSCity2

this feature allows to keep groups of buildings together when resizing a planet

How does the new feature work?

Spoiler

You need to create a cfg file and save it anywhere in GameData. In this cfg you will define all groups of PQSMods you wish to be considered "grouped" as well as an indication of which is the center of the group.

The coordinates for the center have to be chosen carefully otherwise the result might be different than what is expected.

Here is an exaple cfg:

PQSCity_Groups
{
	Group
	{
		name = 
		body = 

		CentralPQSCity = 
		CentralPQSCity2 = 
		CentralPosition = 
		CentralLAT = 
		CentralLON = 

		PQSCity = 
		PQSCity2 = 
	}
}

You can have as many PQSCity_Groups nodes and as many Group nodes as you wish.

here is a list of what each parameter does:

name	name of the group
body	name of the body where the group is

Groups with the same name will be merged, so different groups must have different names.
"body" uses the Kopernicus/Body/name not Kopernicus/Body/cbNameLater

CentralPQSCity	name of the central PQSCity
CentralPQSCity2	name of the central PQSCity2
CentralPosition	vector defining the central position
CentralLAT	Latitude of the central position
CentralLON	Longitude of the central position

only one of these is needed to define the center (except LAT and LON that have to be defined both in order to work

if more than one is present, the higher ones will take priority on the lower ones

PQSCity	name of the PQSCity to add to this group
PQSCity2	name of the PQSCity2 to add to this group

you can list as many "PQSCity" and "PQSCity2" mods as you want, all of them will be considered part of the group and will be moved accordingly when resizing the planet

Why this feature?

When resizing a planet keeping the buildings size unchanged, what happens is that the buildings get spread out on a wider area ( [Resize / resizeBuildings] > 1)  or get crunched together ( [Resize / resizeBuildings] < 1)

The only way around this is to tell SD which "buildings" are supposed to go together and where the center is.

Right now KerbalKonstructs is the only mod that adds buildings, and it has a similar feature, but I wanted something general since I expect Kopernicus will allow to move/add buildings in the future, so I want SD to be already set up to be compatible with any other mod will pop up in the future that adds buildings.

For now KK buildings have to be manually included into this feature, in the future I plan to make an automated loader, but I didn't want to wait before releasing this feature. I have no way to know how much time it will require for me make a compatibility patch.

Plus having the feature out allows me to start getting the first bug reports  which is always useful.

 

Downloads?

all the links are available in the OP

 

If you want to follow the development of my mods:  

If you want to buy me a cup of coffee:    

 

This mod would not be possible without the work of:

- sarbian (ModuleManager)	Donate to Sarbian here:
- Thomas P. (Kopernicus)	Donate to Thomas here:

 

Changelog:

v0.7.3

- Time warp limits and other parameters now account for atmoTopLayer
- Added the possibility to define groups of PQSCity and PQSCity2
  (allows to keep groups of buildings together when resizing a planet)
- Improved the debug options
  (still completely useless, see v0.7.1)

 

[Eklykti]

Yeah, now it's back on the ground!

[Eklykti]

Well, but now there's something wrong with the atmosphere again.

When I quit to main menu and reload, it seems to be applying that atmoTopLayer thing all over again. Here's what it looks like after 4 and 5 reloads with the following settings (based on original KScale64 and improved for the latest SigDim version):

SigmaDimensions
{
	// Base Settings

	Resize = 6.4
	Rescale = 6.4
	Atmosphere = 1.33
	dayLengthMultiplier = 4


	// Advanced Settings

	landscape = .50
	geeASLmultiplier = 1

	resizeScatter = 1
	resizeBuildings = 2

	CustomSoISize = 0
	CustomRingSize = 0

	atmoASL = 1
	tempASL = 1
	atmoTopLayer = 1.4
	atmoVisualEffect = 1

	scanAltitude = 1
}

And… just after that 5th reload, KSP just hanged when trying to main menu again, but this may be related to it's heavy memory consumption and only 4g available on my PC, and not to a particular mod.

[Sigma88]

13 hours ago, Eklykti said:

Well, but now there's something wrong with the atmosphere again.

When I quit to main menu and reload, it seems to be applying that atmoTopLayer thing all over again. Here's what it looks like after 4 and 5 reloads with the following settings (based on original KScale64 and improved for the latest SigDim version):

SigmaDimensions
{
	// Base Settings

	Resize = 6.4
	Rescale = 6.4
	Atmosphere = 1.33
	dayLengthMultiplier = 4


	// Advanced Settings

	landscape = .50
	geeASLmultiplier = 1

	resizeScatter = 1
	resizeBuildings = 2

	CustomSoISize = 0
	CustomRingSize = 0

	atmoASL = 1
	tempASL = 1
	atmoTopLayer = 1.4
	atmoVisualEffect = 1

	scanAltitude = 1
}

And… just after that 5th reload, KSP just hanged when trying to main menu again, but this may be related to it's heavy memory consumption and only 4g available on my PC, and not to a particular mod.

it shouldn't do that, I will check and push an update with a quick fix

it might take a while because I want to put a new feature in the next release, in the meantime avoid going back and forth from the mainmenu if that is possible

[MaxL_1023]

Hello,

Is there a way to change the scaling for asteroids? I am running a 10x setup, and just grabbed a class A which weighed 15000 tons. Since I was supposed to grab it and land it, this is a bit of a problem. I suspect the dimensions were scaled by 10, with the mass scaled by 1000 with constant density. I can work with this for class Es (mining centers) but I want something small which I can move around.

[Sigma88]

4 hours ago, MaxL_1023 said:

Hello,

Is there a way to change the scaling for asteroids? I am running a 10x setup, and just grabbed a class A which weighed 15000 tons. Since I was supposed to grab it and land it, this is a bit of a problem. I suspect the dimensions were scaled by 10, with the mass scaled by 1000 with constant density. I can work with this for class Es (mining centers) but I want something small which I can move around.

Asteroid classes are hardcoded as far as I know. I can change the probability of each class but I cannot change the relationship between class/size/mass

The recent addition of a plugin might offer more options but honestly I didn't look into it

[Sigma88]

Sigma Dimensions v0.7.4

I've made some changes to make it easier for plugins to give SD groups definitions, this will allow me to write a "bridge" plugin that gets the groups from KK and inputs them to SD. (I rather keep SD general and make an optional plugin to interface with KK)

this also fixes a bug with atmoTopLayer 

 

there is also a new feature, that hopefully will be removed soon to be integrated into kopernicus itself.

When defining a group centered on the stock position of the KSC, but the KSC is moved by Kopernicus (like some planet packs do) all the pqscity mods in the group will be moved to be centered around the new position of the KSC

 

all the links are available in the OP

 

If you want to follow the development of my mods:  

If you want to buy me a cup of coffee:    

 

This mod would not be possible without the work of:

- sarbian (ModuleManager)	Donate to Sarbian here:
- Thomas P. (Kopernicus)	Donate to Thomas here:

 

Changelog:

v0.7.4

- Fixed a bug that made atmoTopLayer apply multiple times
- Tweaked PQSCity_Groups loader for better compatibility
- PQSCity_Groups centered on the KSC will be moved if KSC is moved

Edited December 16, 2016 by Sigma88

[Zuthal]

So, I have decided to give it a try, with a 6.4x scale system. I have decided I want Kerbin's atmosphere to extend out to an even 100 km, and its day length to be 12 hours (since at the standard 6 hours, 6.4x scale would result in a tangential velocity at the equator of 1117 m/s. 12 hour day length results in a velocity half that, which is closer to the real-life value for Earth of ~440 m/s. Does this config look like it makes sense to you guys, or would you do anything differently?

SigmaDimensions
{
	// Base Settings

	Resize = 6.4
	Rescale = 6.4
	Atmosphere = 1.1
	dayLengthMultiplier = 2


	// Advanced Settings

	landscape = 0.5
	geeASLmultiplier = 1

	resizeScatter = 1
	resizeBuildings = 0

	CustomSoISize = 0
	CustomRingSize = 0

	atmoASL = 1
	tempASL = 1
	atmoTopLayer = 1.2987
	atmoVisualEffect = 1.4286

	scanAltitude = 1
}

Also, I was wondering if it would be possible to make a program that, given the resize, rescale and geeASLmultiplier parameters, automatically calculates a delta-V map for that resized and rescaled system.

[Sigma88]

@Zuthal the settings look fine, I would keep atmoVisualEffect = 1 for the first start and see what it looks like, you can increase it later if you find it should be higher

in addition to that I would suggest you to consider using different parameters for Resize and Rescale

for example you could choose a Rescale value that keeps the synchronous orbit around kerbin at the same relative distance between kerbin and mun

so try using this formula:

Rescale = (dayLenghtMultiplier*Resize)^(2/3)

which in your case gives  ~8.686

[Zuthal]

That is a good point with the KSO altitude thing - damn that nonlinear scaling.

Though, I probably won't adjust the rescale like that - since that would I think also change the delta-V needed for various maneuvers, and the only delta-V maps that are out there are for 1/1, 6.4/6.4 and 10/10  I'll just take the KSO altitude being a bit too low, comparably (and presumably the altitude of all synchronous orbits). And I also wouldn't want to adjust the day length scaling, since that would be an ugly number... though 2.5 would be quite close to it, for a day length of 15 hours.

Edit: Also, will Mechjeb's and KAC's transfer window calculators still work properly? I.e. do they actually calculate the windows from the orbital elements or do they have a built-in transfer window table?

Edited December 16, 2016 by Zuthal

[Sigma88]

2 minutes ago, Zuthal said:

That is a good point with the KSO altitude thing - damn that nonlinear scaling.

Though, I probably won't adjust the rescale like that - since that would I think also change the delta-V needed for various maneuvers, and the only delta-V maps that are out there are for 1/1, 6.4/6.4 and 10/10  I'll just take the KSO altitude being a bit too low, comparably (and presumably the altitude of all synchronous orbits). And I also wouldn't want to adjust the day length scaling, since that would be an ugly number... though 2.5 would be quite close to it, for a day length of 15 hours.

Your request gave me an idea about making a generator of delta-v maps, if I find someone that has already figured out the math I'll gladly take a shot at it