Sigma Dimensions

[TheAurora]

I have a quick question. Do the planet specific changes work for none stock planets? I believe I correctly followed the procedure, trying to change Titanus' atmosphere in New Horizons, but it did not seem to change anything. 

[Sigma88]

18 minutes ago, TheAurora said:

I have a quick question. Do the planet specific changes work for none stock planets? I believe I correctly followed the procedure, trying to change Titanus' atmosphere in New Horizons, but it did not seem to change anything. 

could you upload the file you created?

also, which version of SD are you using?

[TheAurora]

I believe I am using the latest version. I'll link the document I made to drive and show you. I just copied and pasted the code you put on the first page and changed the variables. 

https://drive.google.com/file/d/0B5cgMsu9X-c5VTBsMU9jaC1TZHM/view?usp=sharing

Above is the link to see the document. 

 

Edited July 17, 2016 by TheAurora

[Sigma88]

23 minutes ago, TheAurora said:

I believe I am using the latest version. I'll link the document I made to drive and show you. I just copied and pasted the code you put on the first page and changed the variables. 

https://drive.google.com/file/d/0B5cgMsu9X-c5VTBsMU9jaC1TZHM/view?usp=sharing

Above is the link to see the document. 

 

ok, so here are some guesses:

1- the patch works fine, but the tracking station shows the wrong numbers (because 1.1.3 changed how those numbers are defined)

2- the patch didn't work because you are using one of the pre-releases (0.5.0.1 or 0.5.0.2)

3- something else is going wrong

 

I would need logs and mm cache files to give you more specific support, if 1 turns out to be the case, that's why SD is not updated to 1.1.3 yet

I'm working on that

[TheAurora]

2 minutes ago, Sigma88 said:

ok, so here are some guesses:

1- the patch works fine, but the tracking station shows the wrong numbers (because 1.1.3 changed how those numbers are defined)

2- the patch didn't work because you are using one of the pre-releases (0.5.0.1 or 0.5.0.2)

3- something else is going wrong

 

I would need logs and mm cache files to give you more specific support, if 1 turns out to be the case, that's why SD is not updated to 1.1.3 yet

I'm working on that

I'll look into it on my end. I can try to confirm if #1 is correct. I'll play around with it.

[Sigma88]

Just now, TheAurora said:

I'll look into it on my end. I can try to confirm if #1 is correct. I'll play around with it.

yeah so there's nothing you can do other than wait for the update to be released

I already know what I need to do to fix the tracking station, I just don't have enough time to spend on modding lately

[TheAurora]

Just now, Sigma88 said:

yeah so there's nothing you can do other than wait for the update to be released

I already know what I need to do to fix the tracking station, I just don't have enough time to spend on modding lately

Perfectly understood. I appreciate your help!

[OhioBob]

@Sigma88, I apologize if this question has already been asked and answered.

Do the Resize and Atmosphere multipliers do anything to the time warp altitude limits or the flying and space altitude thresholds?

Thanks.

 

[Sigma88]

1 hour ago, OhioBob said:

@Sigma88, I apologize if this question has already been asked and answered.

Do the Resize and Atmosphere multipliers do anything to the time warp altitude limits or the flying and space altitude thresholds?

Thanks.

 

yes

1. time warp limits

they are multiplied by Resize on atmosphereless bodies, and by Atmosphere on atmospheric bodies

2. flying thresholds

they are multiplied by Atmosphere on all bodies

3. space thresholds

the math is a bit more complex here.

newThreshold = ((oldThreshold + oldRadius) * Rescale) - newRadius

 

this is the cfg, if you are interested

[OhioBob]

41 minutes ago, Sigma88 said:

yes

1. time warp limits

they are multiplied by Resize on atmosphereless bodies, and by Atmosphere on atmospheric bodies

2. flying thresholds

they are multiplied by Atmosphere on all bodies

3. space thresholds

the math is a bit more complex here.

newThreshold = ((oldThreshold + oldRadius) * Rescale) - newRadius

I'm creating my own 10X solar system (stock planets + OPM) and I'm using Sigma Dimensions to resize and rescale by a factor of 10.  However, I'm creating my own atmosphere cfgs, so I'm setting atmosphere = 1.  Therefore, it sounds like I'm OK for time warp limits on atmosphereless bodies and for space thresholds; however, for bodies with atmospheres, it looks like I'm going to have to rescale the time warp limits and flying thresholds myself.  Thanks for the explanation.

[Sigma88]

25 minutes ago, OhioBob said:

I'm creating my own 10X solar system (stock planets + OPM) and I'm using Sigma Dimensions to resize and rescale by a factor of 10.  However, I'm creating my own atmosphere cfgs, so I'm setting atmosphere = 1.  Therefore, it sounds like I'm OK for time warp limits on atmosphereless bodies and for space thresholds; however, for bodies with atmospheres, it looks like I'm going to have to rescale the time warp limits and flying thresholds myself.  Thanks for the explanation.

yes, that would probably be the best choice since you are not using SD to change the atmospheres.

I don't know if you might have issues with other stuff tho, you'll just have to see

[OhioBob]

@Sigma88, I've gotten the new timewarpAltitudeLimits to work, but the new flyingAltitudeThreshold value isn't taking effect.  I haven't tested it in the game but, according to the Kopernicus logs, flyingAltitudeThreshold still equals the original stock value.  Below is a partial copy of one of my cfg files.  Any idea why it's not working?

@Kopernicus:FOR[10xSolarSytem]
{
	@Body[Kerbin]
	{
		@Properties
		{
			rotationPeriod = 43200
			timewarpAltitudeLimits = 0 135000 135000 135000 135000 1500000 3000000 6000000
			ScienceValues
			{
				flyingAltitudeThreshold = 25000
			}
		}
		@Atmosphere
		{
			........

Here is what the log shows:

[LOG 23:07:15]: --------- Science Values ------------
[LOG 23:07:15]: LandedDataValue = 0.3
[LOG 23:07:15]: SplashedDataValue = 0.4
[LOG 23:07:15]: FlyingLowDataValue = 0.7
[LOG 23:07:15]: FlyingHighDataValue = 0.9
[LOG 23:07:15]: InSpaceLowDataValue = 1
[LOG 23:07:15]: InSpaceHighDataValue = 1.5
[LOG 23:07:15]: RecoveryValue = 1
[LOG 23:07:15]: flyingAltitudeThreshold = 18000
[LOG 23:07:15]: spaceAltitudeThreshold = 2500000
[LOG 23:07:15]: --------------------------------------

I realize this may not be a Sigma Dimensions issue, but you seem to know a lot about this stuff and have been really helpful so far.  I appreciate your help.

[Sigma88]

6 hours ago, OhioBob said:

@Sigma88, I've gotten the new timewarpAltitudeLimits to work, but the new flyingAltitudeThreshold value isn't taking effect.  I haven't tested it in the game but, according to the Kopernicus logs, flyingAltitudeThreshold still equals the original stock value.  Below is a partial copy of one of my cfg files.  Any idea why it's not working?

@Kopernicus:FOR[10xSolarSytem]
{
	@Body[Kerbin]
	{
		@Properties
		{
			rotationPeriod = 43200
			timewarpAltitudeLimits = 0 135000 135000 135000 135000 1500000 3000000 6000000
			ScienceValues
			{
				flyingAltitudeThreshold = 25000
			}
		}
		@Atmosphere
		{
			........

Here is what the log shows:

[LOG 23:07:15]: --------- Science Values ------------
[LOG 23:07:15]: LandedDataValue = 0.3
[LOG 23:07:15]: SplashedDataValue = 0.4
[LOG 23:07:15]: FlyingLowDataValue = 0.7
[LOG 23:07:15]: FlyingHighDataValue = 0.9
[LOG 23:07:15]: InSpaceLowDataValue = 1
[LOG 23:07:15]: InSpaceHighDataValue = 1.5
[LOG 23:07:15]: RecoveryValue = 1
[LOG 23:07:15]: flyingAltitudeThreshold = 18000
[LOG 23:07:15]: spaceAltitudeThreshold = 2500000
[LOG 23:07:15]: --------------------------------------

I realize this may not be a Sigma Dimensions issue, but you seem to know a lot about this stuff and have been really helpful so far.  I appreciate your help.

Exact same issue as before

Kopernicus already gives kerbin a "ScienceValues" node, so you need to add an @ before your node

[OhioBob]

5 hours ago, Sigma88 said:

Exact same issue as before

Kopernicus already gives kerbin a "ScienceValues" node, so you need to add an @ before your node

Of course, I should have know that.  I was copying the syntax for an OPM cfg, but those are new planets, not revisions to existing ones.

[Sigma88]

2 minutes ago, OhioBob said:

Of course, I should have know that.  I was copying the syntax for an OPM cfg, but those are new planets, not revisions to existing ones.

A good way to check what the issue is, is to apply your patch to the planets without SD installed and then go to the mm cache and see what is written there.

If you do that, you can easily spot 90% of mm issues

[evileye.x]

@Sigma88

Just started to play with rescales and want to thank you for your efforts, great mod.

However I have a suggestion regarding cloud height resize - would be cool to have rescale factor for clouds height  as option in main cfg, because it doesn't make sense to scale up clouds height by main multiplier 

Never mind, I found this post

 

Edited August 3, 2016 by evileye.x

[Sigma88]

1 hour ago, evileye.x said:

@Sigma88

Just started to play with rescales and want to thank you for your efforts, great mod.

However I have a suggestion regarding cloud height resize - would be cool to have rescale factor for clouds height  as option in main cfg, because it doesn't make sense to scale up clouds height by main multiplier

to give you a little insight on why I decided for using resize:

if you shrink the planet this is obvious, you need to take down the clouds to fit the new size

if you enlarge the planet it's a bit less obvious, but think of it like this: 

when you choose the clouds altitude in EVE you need to be careful not to go too low otherwise you get very ugly z-stacking issues, that's why you need to resize them up.

the real problem here is that cloud packs just pick an altitude that works, and since the planet is "small" (1x) you can't notice that the clouds are a bit too high, but when you resize everything 6.4x or 10x that extra height starts to be noticeable, and then ppl ask me to change the resize parameters for the clouds.

if you do the opposite (set the altitude to work well on 10x kerbin, take that number divided by 10 and apply to your stock game) you will see that the optimal altitude will work well in both scales (1x and 10x)

Edited August 3, 2016 by Sigma88

[FreeThinker]

@Sigma88 Hey, why isn't this mod on CKAN, I want to add a recommendation to Sigma Dimention to KSPI-E which will add active support. Note that this is required not only for KSPI-E but also several other mods which depend on Sigma Dimention like

 

Edited August 5, 2016 by FreeThinker

[Sigma88]

5 minutes ago, FreeThinker said:

@Sigma88 Hey, why isn't this mod on CKAN, I want to add a recommendation to Sigma Dimention to KSPI-E which will add active support ..

I have removed all my mods from ckan a while ago with the intention to readding them back on when I had the time to set up a system to maintain my own metadata. Shortly after removing them tho I was hit by a very busy period irl which lead to very little time (and motivation) to mod ksp.

I hope to be back for september-ish (you have probably noticed that updates are now very rare)

either way, I have yet to decide if I want to put a "WIP" mod on ckan, so I'm not sure yet if SD will end up there for the time being.

[FreeThinker]

6 minutes ago, Sigma88 said:

I have removed all my mods from ckan a while ago with the intention to readding them back on when I had the time to set up a system to maintain my own metadata. Shortly after removing them tho I was hit by a very busy period irl which lead to very little time (and motivation) to mod ksp.

I hope to be back for september-ish (you have probably noticed that updates are now very rare)

either way, I have yet to decide if I want to put a "WIP" mod on ckan, so I'm not sure yet if SD will end up there for the time being.

Not sure why  beeing so cautious makes much sence, what I do know is that other mods that depend on Sigma are now effectvely broken or force players to install your mod manualy with all catastropic problems related to this. Therefore I think the best thing to do is just allow players to decide for themselves if they wish to use your mod, For me this is the main motivation to give CKAN support, to prevent installation problems. After I implemented CKAN support, the number of wrong instaltions dropped by 90%,This allone is anough reason to keep CKAN updated and maintained at all times

Edited August 5, 2016 by FreeThinker

[Sigma88]

12 minutes ago, FreeThinker said:

Not sure why  beeing so cautious makes much sence

It made sense at the time because of the incredibly stupid attitude of the ckan team, and then I just didn't have the time to put them back on my own terms. All this could be avoided if the initial attitude was different.

17 minutes ago, FreeThinker said:

other mods that depend on Sigma are now effectvely broken

not broken, they just require a manual install of my mod.

(if the ckan metadata still lists my mod as a requirement effectively making that mod impossible to install, that's a ckan issue)

 

Plus, I have a limited time as is, so adding another layer of stuff to maintan to my mods isn't exactly something I am looking forward to.

 

[FreeThinker]

2 minutes ago, Sigma88 said:

It made sense at the time because of the incredibly stupid attitude of the ckan team, and then I just didn't have the time to put them back on my own terms. All this could be avoided if the initial attitude was different.

I must have mised something, what stupid attitude  are we talking about?

 

2 minutes ago, Sigma88 said:

Plus, I have a limited time as is, so adding another layer of stuff to maintan to my mods isn't exactly something I am looking forward to.

Well I think CKAN support will saves you time, because people are less likely to mess up their installation

Edited August 5, 2016 by FreeThinker

[Sigma88]

9 minutes ago, FreeThinker said:

I must have mised something, what stupid attitude  are we talking about?

Well I think CKAN support will saves you time, because people are less likely to mess up their installation

here's a thread where the issue was discussed throughly

to be clear, with "stupid" I mean the attitude to force their stuff down the throat of people (mod devs) who did not want their mods to be listed.

 

as for the installs, I spend time to make sure the installation of my mods is as easy as possible. I don't recall having ever received a bugreport from wrong (manual) installs.

and now since I will go back to ckan only when I will have time to maintain my own metadata, it will take me some time to get at that point.

[antgeth]

my sincere apologies if this has been answered before -- i only read the first and last couple pages of this thread and couldn't find anything (nor is it searchable):

will adjusting any of the parameters (resize, atmo, etc) move active flights?  i'm thinking about adding this to a current career save, but rather desperately do not want my crafts to suddenly find themselves inside an atmosphere (or a planet).

[Sigma88]

1 minute ago, antgeth said:

my sincere apologies if this has been answered before -- i only read the first and last couple pages of this thread and couldn't find anything (nor is it searchable):

will adjusting any of the parameters (resize, atmo, etc) move active flights?  i'm thinking about adding this to a current career save, but rather desperately do not want my crafts to suddenly find themselves inside an atmosphere (or a planet).

No, crafts already launched will not be affected. And the same is true for asteroids (only those already spawned)

 

This means that you could potentially lose them inside atmospheres or even planets