Sigma Dimensions

[Sigma88]

3 minutes ago, Bahamut said:

Yeah, I'm guessing something is wrong because I wasn't seeing that number. Any suggestions as to how I can figure out what is affecting that value?

try to reproduce the issue with just MM + kopernicus + SD

if you still see it send me the modulemanager cache and your settings.cfg from sigma dimensions

[JebThrillMaster]

28 minutes ago, Sigma88 said:

no need for now, could you try with dayLengthMultiplier = 4 ?

No more force reading in KER, but problem still persists. Could it be the InverseRot cfg?

[Sigma88]

Just now, JebThrillMaster said:

No more force reading in KER, but problem still persists. Could it be the InverseRot cfg?

what do you mean?

[JebThrillMaster]

Just now, Sigma88 said:

what do you mean?

@Kopernicus:FINAL
{
	@Body,*
	{
		%Properties
		{
			%inverseRotThresholdAltitude = 91000
		}
	}
}

Used to fix not being able to warp in space.

[Sigma88]

Just now, JebThrillMaster said:

@Kopernicus:FINAL
{
	@Body,*
	{
		%Properties
		{
			%inverseRotThresholdAltitude = 91000
		}
	}
}

Used to fix not being able to warp in space.

oh yeah remove that !

 

[JebThrillMaster]

11 minutes ago, Sigma88 said:

oh yeah remove that !

 

Seems to only be accelerated within 2000K of kerbin and seems lesser farther out. At around 11400K it seems to have 'stopped'. EDIT: not stopped, just lesser rate than before.

Edited May 10, 2016 by JebThrillMaster

[Sigma88]

1 hour ago, JebThrillMaster said:

Seems to only be accelerated within 2000K of kerbin and seems lesser farther out. At around 11400K it seems to have 'stopped'. EDIT: not stopped, just lesser rate than before.

can you reproduce this with only MM + Kopernicus + SD?

[Bahamut]

2 hours ago, Sigma88 said:

try to reproduce the issue with just MM + kopernicus + SD

if you still see it send me the modulemanager cache and your settings.cfg from sigma dimensions

So, I copied my ksp folder into a duplicate (and removed most mods). Keeping a bare minimum to test. Using hyperedit to see where the barrier was, the low/high split was exactly where you said it would be at 1.6 Mm. 

So it could be another mod cfg file interfering with that value, though I'm not sure how to trace that down without reading the cfg files of potential suspects.

[JebThrillMaster]

58 minutes ago, Sigma88 said:

can you reproduce this with only MM + Kopernicus + SD?

Still occurs. Going to try lowering atmosphere value down to 1.

4 minutes ago, JebThrillMaster said:

Still occurs. Going to try lowering atmosphere value down to 1.

Aaaaand still there.

[Sigma88]

7 hours ago, JebThrillMaster said:

Still occurs. Going to try lowering atmosphere value down to 1.

Aaaaand still there.

Ok

So delete the module manager cache file, run the game with the settings you want to use and then send me the ksp.log you can find in the ksp installation folder plus the modulemanager cache file

[Table]

Thanks for this mod man!

Edited May 11, 2016 by Table

[pap1723]

Sigma, this mod is great and it has allowed the guys over at SSRSS to create a great experience for those of us that do not want to play RSS with that much realism.

They are having an issue with the mod that I wonder if you could help with. They have used your mod to shrink the RSS down to Kerbal size. Everything is pretty much working great, but the time is a little screwy. The planets rotate properly, but the overall game time is still set on a 24-hour clock. So when trying to complete missions with time requirements, it takes 3 days to complete a one day mission.

Thanks for your help!

[Sigma88]

3 hours ago, pap1723 said:

Sigma, this mod is great and it has allowed the guys over at SSRSS to create a great experience for those of us that do not want to play RSS with that much realism.

They are having an issue with the mod that I wonder if you could help with. They have used your mod to shrink the RSS down to Kerbal size. Everything is pretty much working great, but the time is a little screwy. The planets rotate properly, but the overall game time is still set on a 24-hour clock. So when trying to complete missions with time requirements, it takes 3 days to complete a one day mission.

Thanks for your help!

hi @pap1723 SigmaDimensions doesn't currently change anything about contracts.

I'm not sure how I could approach this, I'll ask @nightingale when I get some time

the 24-hour clock can be changed in the game settings to 6hr clock. but I guess the contracts will take always the same amount of seconds to complete. if that's the case maybe there's a parameter I can change somewhere...

[pap1723]

3 hours ago, Sigma88 said:

hi @pap1723 SigmaDimensions doesn't currently change anything about contracts.

I'm not sure how I could approach this, I'll ask @nightingale when I get some time

the 24-hour clock can be changed in the game settings to 6hr clock. but I guess the contracts will take always the same amount of seconds to complete. if that's the case maybe there's a parameter I can change somewhere...

I think it might have something to do with the settings from Kopernicus as well. I am just curious as it seems to be a tricky fix!

[nightingale]

3 hours ago, pap1723 said:

I think it might have something to do with the settings from Kopernicus as well. I am just curious as it seems to be a tricky fix!

It's hard to do a generic fix for this.  Also, I think the resolution for this (if there is one) lies more in the contract pack that in Sigma Dimensions.  Which contract packs are you referring to with the time limits?  I'm guessing it's either GAP or RP-0.  I ask because I'm not sure what the impacts of the time limits are (is it that it's a timed mission and the difficulty doesn't scale properly?)  Generally speaking, all the durations in Contract Configurator are based on the 6 hour Kerbal day, but will display based on the game clock settings.  If you want to scale those, the likely way to do it would be based on a module manager patch.  One thing I could consider if the author of the contracts interested in is give a CelestialBody.DayLength() expression function which could be used to scale those types of requirements directly in the contract pack.

[pap1723]

51 minutes ago, nightingale said:

It's hard to do a generic fix for this.  Also, I think the resolution for this (if there is one) lies more in the contract pack that in Sigma Dimensions.  Which contract packs are you referring to with the time limits?  I'm guessing it's either GAP or RP-0.  I ask because I'm not sure what the impacts of the time limits are (is it that it's a timed mission and the difficulty doesn't scale properly?)  Generally speaking, all the durations in Contract Configurator are based on the 6 hour Kerbal day, but will display based on the game clock settings.  If you want to scale those, the likely way to do it would be based on a module manager patch.  One thing I could consider if the author of the contracts interested in is give a CelestialBody.DayLength() expression function which could be used to scale those types of requirements directly in the contract pack.

The one that I noticed it on is the RemoteTech setup of the initial 4 satellite relay network. In the file, it has the duration set at 2 days, but in the game, it actually took 48 hours, or 6 days. I am curious if it is an easy fix?

This is the current setup:

PARAMETER
    {
        name = Duration
        type = Duration

        duration = 2d

        preWaitText = Testing time after network up
        waitingText = Performing shake-out testing
        completionText = Shake-out testing completed
    }

If I change the duration value to this, will it work the right way, or is there something else going on with the Scaling?

PARAMETER
    {
        name = Duration
        type = Duration

        duration = CelestialBody.DayLength() * 2

        preWaitText = Testing time after network up
        waitingText = Performing shake-out testing
        completionText = Shake-out testing completed
    }

 

[nightingale]

1 hour ago, pap1723 said:

The one that I noticed it on is the RemoteTech setup of the initial 4 satellite relay network. In the file, it has the duration set at 2 days, but in the game, it actually took 48 hours, or 6 days. I am curious if it is an easy fix?

This is the current setup:

PARAMETER
    {
        name = Duration
        type = Duration

        duration = 2d

        preWaitText = Testing time after network up
        waitingText = Performing shake-out testing
        completionText = Shake-out testing completed
    }

If I change the duration value to this, will it work the right way, or is there something else going on with the Scaling?

PARAMETER
    {
        name = Duration
        type = Duration

        duration = CelestialBody.DayLength() * 2

        preWaitText = Testing time after network up
        waitingText = Performing shake-out testing
        completionText = Shake-out testing completed
    }

 

The DayLength() thing was just an idea I was thinking about -  it's not something that exists today.

The durations are calculated based on the time settings (not sure why I chose to do it that way, I don't really like it), so you probably had it set to earth time at one point (the value won't be changed back once the contract is generated).  Cancel the contract and the next one should be right.

That being said, for that particular contract it doesn't make a huge difference - 2 days was a pretty arbitrary value that I selected to make sure the network is actually up and operating correctly.

[Sigma88]

Thanks for taking the time @nightingale

I always apreciate your input

[Armisael]

First off: thanks muchly for this - it's great to have good support.

Would it be possible to have the timewarp heights scaled based off terrain scaling (or atmospheric scaling, for bodies with atmosphere) instead of the resize factor? I'm playing at 6.4x scale, and it's a little annoying to not be able to timewarp below 32km, given that I usually park at 10-12km.

[Sigma88]

3 minutes ago, Armisael said:

First off: thanks muchly for this - it's great to have good support.

Would it be possible to have the timewarp heights scaled based off terrain scaling (or atmospheric scaling, for bodies with atmosphere) instead of the resize factor? I'm playing at 6.4x scale, and it's a little annoying to not be able to timewarp below 32km, given that I usually park at 10-12km.

on atmospheric bodies time warp should be rescaled using the atmosphere parameter

are you saying this is not happening for you?

Edited May 15, 2016 by Sigma88

[Armisael]

My bad - it does happen on atmospheric bodies. Could we get that same effect using the terrain scale height on non-atmospheric bodies?

[JebThrillMaster]

@Sigma88 Seems the decay is a stock bug with the game currently. http://bugs.kerbalspaceprogram.com/issues/9619

[Sigma88]

9 hours ago, JebThrillMaster said:

@Sigma88 Seems the decay is a stock bug with the game currently. http://bugs.kerbalspaceprogram.com/issues/9619

Thank you!

I was going mad trying to figure out this issue

[OndrikB]

Any way to delete (or hide or move) the Old Airfield? At 1/100 scale it is clipping trough the launch pad

[Marsu69]

On 5/5/2016 at 0:21 PM, Sigma88 said:

A couple of things:

1 - you are not changing the radius, you are adding a second "radius" parameter which doesn't get used

changing the radius is a bad way to resize the planet anyways, (otherwise making SD would have been a pretty huge waste of time).

to get kerbin's radius to be 6371000 you should use

Resize = 10.6183333333

in the SD settings

in alternative, if could look at Planet Specific Changes (see README.txt in GameData/Sigma/Dimensions)

2- for the atmosphere I am supposing you copied the whole RSS "Atmosphere" bit from Earth cfg

that's fine, but try doing it this way:

@Kopernicus:FINAL
{
	@Body[Kerbin]
	{
		!Atmosphere,* {}
		Atmosphere
		{
			// FROM RSS
		}
	}
}

this should work

Hey @Sigma88

I too try to make the atmosphere like earth because it seems it decay much faster on earth than on Kerbin.

But i can't figure how to do this. Do I need to put something else in the config you provide ? 

Sorry for the noobish question :-(

 

EDIT : Nevermind the problem I have seems to be related with FAR and not with Sigma

Edited May 17, 2016 by Marsu69