Sigma Dimensions

[Fobok]

59 minutes ago, Galileo said:

I would make a copy of your save and try it out. If it wrecks everything just put your old save back in and remove sigma until you make the necessary changes to allow for a rescale

Thank you. :-) That makes perfect sense, and I'm a little embarrassed that I didn't think of that myself.

*ETA: And, as far as I can tell, no problems whatsoever. In fact, a few things remained that I hadn't expected. It will be a few days before I can properly test, but looks like it worked out fine. :-)

Edited February 12, 2017 by Fobok

[Norcalplanner]

2 hours ago, Fobok said:

Thank you. :-) That makes perfect sense, and I'm a little embarrassed that I didn't think of that myself.

*ETA: And, as far as I can tell, no problems whatsoever. In fact, a few things remained that I hadn't expected. It will be a few days before I can properly test, but looks like it worked out fine. :-)

When I've done rescales on existing saves like you describe, I'll bring all my Kerbals home.  That way I save all my personnel, science, and funds for certain.  My current 3.2x save may inflate later to 6.4x or larger, but only after I've done some more large things (like down and back on Tellumo, which requires 11 km/s in 3.2x).  It will probably also depend on when I can set up infrastructure for a reliable Karborundum supply.  

[DerpyFirework]

@Sigma88, I've been working on a plugin that places structures using PQSCity2 and I've run into an issue regarding compatibility with SigmaDimensions.

I'm experimenting with several objects, including some droneships, and the droneships have "snapToSurface = false". This, and using SigmaDimensions to resize to 2x, results in them being 600km (1x original radius) higher than they should be (ie. In space). Any object placed with "snapToSurface = true" is unaffected.

Looking at the source of SigmaDimensions, at line 108 in SigmaDimensions.cs it compensate for the resizing of the planet for every PQSCity2, but it would seem as though every PQSCity2 that I place (in the mainmenu scene) accounts for this without any additional code, which may indicate that this is already handled by PQSCity2 itself.

Just thought I'd let you know, since I have no idea what else to do.

[Sigma88]

51 minutes ago, DerpyFirework said:

@Sigma88, I've been working on a plugin that places structures using PQSCity2 and I've run into an issue regarding compatibility with SigmaDimensions.

I'm experimenting with several objects, including some droneships, and the droneships have "snapToSurface = false". This, and using SigmaDimensions to resize to 2x, results in them being 600km (1x original radius) higher than they should be (ie. In space). Any object placed with "snapToSurface = true" is unaffected.

Looking at the source of SigmaDimensions, at line 108 in SigmaDimensions.cs it compensate for the resizing of the planet for every PQSCity2, but it would seem as though every PQSCity2 that I place (in the mainmenu scene) accounts for this without any additional code, which may indicate that this is already handled by PQSCity2 itself.

Just thought I'd let you know, since I have no idea what else to do.

Sure, I'll  take a look and report back

[Cheesecake]

I don't know if this is a Sigma-Issue or SVT. So I post it here too.

I have installed SVE+SVT+Kopernicus 1.2.2-4+Sigma Dimensions and the I have no Groundtextures around the KSC. Without Sigma the Textures are OK. Mods are the neweset versions.

http://imgur.com/a/5IUjA

[thunder175]

@Sigma88 I started a new game running a 6.4/6.4 after playing 3.2/6.4 for a long time. I have found it annoying that the time warp limits are getting scaled as well. For example, at 6.4x the lower end limit for time warp goes to 192km! This was occurring at 3.2x but I didn't find it as annoying since it was raising the time warp limit to only 96km, and I have raised the top layer of the atmosphere to approximately 90km. I manually went thru all the files from github to make sure I have the most current versions and it appears I do. Is this behavior normal as the mod is currently written? I tried to force time warp limits manually in my extra MM patch by adding a time warp limit entry, but it didn't respect that entry and I'm still limited to 1x time below 192km. Is there a way to limit or change the time warp settings another way so they its not a raw multiplication of the configs found in \Configs\Bodies\Templates? Or am I doing missing something simple?

 

 

Edited February 17, 2017 by thunder175

[Sigma88]

@thunder175 timewarp limits of atmospheric planets will be scaled using the "Atmosphere" parameter, while on non atmospheric ones it will scale with "Resize"

 

if you don't want that to happen, you can use this cfg to override SD

 

@Kopernicus:FINAL
{
	@Body:HAS[@Atmosphere]
	{
		@Properties
		{
			@timewarpAltitudeLimits,0[*, ] *= XXX
		}
	}
	@Body:HAS[!Atmosphere]
	{
		@Properties
		{
			@timewarpAltitudeLimits,0[*, ] *= YYY
		}
	}
}

 

where XXX is the multiplier for atmospheric planets and YYY is the multiplier for non atmospheric ones

 

keep in mind that this multiplier will be applied ON TOP of whatever multiplier SD uses

[thunder175]

@Sigma88 I don't know if that is happening correctly at the moment. This is occurring on Kerbin. My atmosphere rescale is set to 1.14, with rescale and resize at 6.4. So looking at the config templates and taking your reply into account it should be multiply time warp limit 30000x1.14=34.2km. Instead it appears to be multiplying 30000x6.4=192km. Looking at the config file again, the only thing I can think of is that its treating Kerbin as an !Atmosphere planet. 

 

As always appreciate the prompt response and help!

Edited February 17, 2017 by thunder175

[Fobok]

Does scaling up increase the heat as well somehow? I finally made my decision on the scale I wanted to play and moved to 3.2x, and it seems to be working great, but I've noticed even when I have a low TWR I'm getting extreme heat warnings on my fairings. And, in my second launch, even one of my engines. Not enough to blow anything up, yet, (I haven't tried reentry yet), but just wondering if I need to make any other tweaks, or if it might be a bug with another mod that I need to track down.

Or, if it's completely normal, then I can try to deal with it. :-)

Edited February 17, 2017 by Fobok

[lordcirth]

2 hours ago, Fobok said:

Does scaling up increase the heat as well somehow? I finally made my decision on the scale I wanted to play and moved to 3.2x, and it seems to be working great, but I've noticed even when I have a low TWR I'm getting extreme heat warnings on my fairings. And, in my second launch, even one of my engines. Not enough to blow anything up, yet, (I haven't tried reentry yet), but just wondering if I need to make any other tweaks, or if it might be a bug with another mod that I need to track down.

Or, if it's completely normal, then I can try to deal with it. :-)

If you scale up the planet, you scale up the orbital velocity, which means your dynamic pressure and heating will increase while flying through the atmosphere attempting to reach that orbital velocity.  You can turn heating down in the stock settings, if you want.

[Fobok]

1 hour ago, lordcirth said:

If you scale up the planet, you scale up the orbital velocity, which means your dynamic pressure and heating will increase while flying through the atmosphere attempting to reach that orbital velocity.  You can turn heating down in the stock settings, if you want.

 

And that makes perfect sense. Thanks!

[RocketRyleigh]

I'm not sure if this is a bug, or if it's something I'm missing in the settings, but I'm experiencing a minor issue.

When the system is scaled up to 6.4, the game seems to think I'm at 423m above sea level while I'm sitting on the launchpad in a Mk1 Command Pod.

I checked things out with Sigma removed and RSS installed, and the game seems to recalculate the new sea level just fine in RSS. This isn't a huge issue, but it seems like something that can be resolved given that the issue doesn't happen with RSS (also planning on using kOS and not sure if this will affect it's calcs).

This may have nothing to do with the problem, but in an earlier post on this thread where someone posted their 6.4 rescale settings for reassurance, I noticed they had the "landscape" setting at 0.5, which I couldn't figure out the purpose of. Even if that's not part of the aforementioned sea level issue, could someone shed some light on the purpose of reducing the landscape setting to 0.5 when scaling up the system to 6.4?

In any case, love your mod Sigma88.

[thunder175]

@Sigma88 I did as you suggested, but instead put the entry right into my own Kerbin patch file for a few other setting changes that I use. Restarted KSP and I'm still stuck at 1x below 192km. I've double and triple checked files and I can't seem to find a conflict anywhere else. I also been going thru all my other mods to see if there is a conflicting entry somewhere, but I can find it.

 

Spoiler

@Kopernicus:FINAL
{
    @Body[Kerbin]
    {
        @Properties
        {
            %rotationPeriod = 86164
            %initialRotation = 254.595 //sets midnight local time to KSC
            // %timewarpAltitudeLimits = 0 90000 90000 90000 150000 300000 600000 900000
            @timewarpAltitudeLimits,0[*, ] *= 0.46875
        }
        @Orbit
        {
            %inclination = 1.31
            %eccentricity = 0.0167
            %longitudeOfAscendingNode = 0
            %argumentOfPeriapsis = 0
        }
    }
}

 

[Sigma88]

5 minutes ago, thunder175 said:

@Sigma88 I did as you suggested, but instead put the entry right into my own Kerbin patch file for a few other setting changes that I use. Restarted KSP and I'm still stuck at 1x below 192km. I've double and triple checked files and I can't seem to find a conflict anywhere else. I also been going thru all my other mods to see if there is a conflicting entry somewhere, but I can find it.

 

  Hide contents

@Kopernicus:FINAL
{
    @Body[Kerbin]
    {
        @Properties
        {
            %rotationPeriod = 86164
            %initialRotation = 254.595 //sets midnight local time to KSC
            // %timewarpAltitudeLimits = 0 90000 90000 90000 150000 300000 600000 900000
            @timewarpAltitudeLimits,0[*, ] *= 0.46875
        }
        @Orbit
        {
            %inclination = 1.31
            %eccentricity = 0.0167
            %longitudeOfAscendingNode = 0
            %argumentOfPeriapsis = 0
        }
    }
}

 

could you send me the mm cache file generated with that setup?

10 minutes ago, RocketRyleigh said:

I'm not sure if this is a bug, or if it's something I'm missing in the settings, but I'm experiencing a minor issue.

When the system is scaled up to 6.4, the game seems to think I'm at 423m above sea level while I'm sitting on the launchpad in a Mk1 Command Pod.

I checked things out with Sigma removed and RSS installed, and the game seems to recalculate the new sea level just fine in RSS. This isn't a huge issue, but it seems like something that can be resolved given that the issue doesn't happen with RSS (also planning on using kOS and not sure if this will affect it's calcs).

This may have nothing to do with the problem, but in an earlier post on this thread where someone posted their 6.4 rescale settings for reassurance, I noticed they had the "landscape" setting at 0.5, which I couldn't figure out the purpose of. Even if that's not part of the aforementioned sea level issue, could someone shed some light on the purpose of reducing the landscape setting to 0.5 when scaling up the system to 6.4?

In any case, love your mod Sigma88.

423 sounds about right

stock launchpad is at 65-66 meters above sea level

and 423/6.4 = 66.09375

 

the purpose of "landscape" is to change the ratio between the height of geographic features (like mountains) and the radius of the planet.

simply put, an 8km mountain in stock would become an 80km mountain in 10x SD

if you want to keep the highest mountain at 8 km you can set landscape = 0.1 which means the mountain height will now be:

 

8km (stock) *  10 (Resize) * 0.1 (landscape) = 8km (final height)

Edited February 19, 2017 by Sigma88

[RocketRyleigh]

10 minutes ago, Sigma88 said:

could you send me the mm cache file generated with that setup?

423 sounds about right

stock launchpad is at 65-66 meters above sea level

and 423/6.4 = 66.09375

 

the purpose of "landscape" is to change the ratio between the height of geographic features (like mountains) and the radius of the planet.

simply put, an 8km mountain in stock would become an 80km mountain in 10x SD

if you want to keep the highest mountain at 8 km you can set landscape = 0.1 which means the mountain height will now be:

 

8km (stock) *  10 (Resize) * 0.1 (landscape) = 8km (final height)

That seems so simple that I almost feel silly; I think I had just gotten it into my head that the game wasn't changing the ASL from the stock scale, and that the game was measuring my ASL altitude from somewhere inside the rescaled planet.

I actually had a feeling the landscape setting worked like that; I'm fine with the landscape scaling proportionately with the resize, so I'll just leave it be.

Thanks for the incredibly quick response, Sigma.

[RocketRyleigh]

On 1/24/2017 at 5:10 AM, Sigma88 said:

you might want to add a :FINAL so that the changes are applied after SD

 

an alternative to :FINAL could be :AFTER[SigDim2]

 

but I haven't tested any of those

Don't like to be a pest, but since I've already got you here: 

Are these settings necessary to keep the proportions in line for antenna ranges in a larger scale system? And if so, which Config file would I and that code into (I was guessing advancedSettings.cfg)?

Edit: Guess I don't know how to quote properly; I meant to include IronCretin 's cfg:

@PART[*]:HAS[@MODULE[ModuleDataTransmitter]] {
	@MODULE[ModuleDataTransmitter] {
		@antennapower *= #$@SigmaDimensions/Rescale$
	}
}

@CUSTOMBARNKIT {
	@TRACKING {
		@DSNRange,* *= #$@SigmaDimensions/Rescale$
	}
}

Edited February 19, 2017 by RocketRyleigh

[Sigma88]

1 minute ago, RocketRyleigh said:

Don't like to be a pest, but since I've already got you here: 

Are these settings necessary to keep the proportions in line for antenna ranges in a larger scale system? And if so, which Config file would I and that code into (I was guessing advancedSettings.cfg)?

I'm not sure what you mean, but if we are talking about antennas I don't think SD is changing antennas at all. I don't remember looking into that yet.

[RocketRyleigh]

I just want to keep the game mechanics as balanced as possible, and I got the impression from IronCretin's question that stock antennas wouldn't be sufficient for the rescaled distances, hence the need for his suggested cfg to rescale antenna ranges.

Do you think any changes would be REQUIRED for the stock antennas to still be useful in a 6.4 scale system, and if so, where would I insert IronCretin/Jso's suggested cfgs?

For reference, IronCretin/Jso suggested:

@PART[*]:HAS[@MODULE[ModuleDataTransmitter]] {
    @MODULE[ModuleDataTransmitter] {
        @antennapower *= #$@SigmaDimensions/Rescale$
    }
}

@CUSTOMBARNKIT {
    @TRACKING {
        @DSNRange,* *= #$@SigmaDimensions/Rescale$
    }
}

Edited February 19, 2017 by RocketRyleigh

[Sigma88]

11 minutes ago, RocketRyleigh said:

I just want to keep the game mechanics as balanced as possible, and I got the impression from IronCretin's question that stock antennas wouldn't be sufficient for the rescaled distances, hence the need for his suggested cfg to rescale antenna ranges.

Do you think any changes would be REQUIRED for the stock antennas to still be useful in a 6.4 scale system, and if so, where would I insert IronCretin/Jso's suggested cfgs?

I don't recall ever working on stock antennas, so probably SD is still not compatible with those

[RocketRyleigh]

1 minute ago, Sigma88 said:

I don't recall ever working on stock antennas, so probably SD is still not compatible with those

If it makes a difference, I DO use RemoteTech. TBH I might be asking a pointless question based on half-understood information.

In any case, I'll just leave it be for now, make sure RT is set to Root, and do some testing before I get into a new Career.

I release you from my inquisition!

[Sigma88]

2 minutes ago, RocketRyleigh said:

If it makes a difference, I DO use RemoteTech. TBH I might be asking a pointless question based on half-understood information.

In any case, I'll just leave it be for now, make sure RT is set to Root, and do some testing before I get into a new Career.

I release you from my inquisition!

if you use RT then you need to use their multiplier for ranges. I tried baking compatibility into SD but RT cfg structure is too messy to do that properly.

plus, it's really easy for you as an user to set RT to whatever you want

[thunder175]

Just following up on my problem above. Apparently it was HyperEdit causing my time warp refactor issue. I moved HyperEdit out of my GameData folder after creating new MM patches for my planet orbit edits and the time warp limits were being refactored appropriately.

[RocketRyleigh]

2 hours ago, Sigma88 said:

if you use RT then you need to use their multiplier for ranges. I tried baking compatibility into SD but RT cfg structure is too messy to do that properly.

plus, it's really easy for you as an user to set RT to whatever you want

Ah okay, so I would just set the RT range multiplier to the same factor as my rescale factor (or in the case of the Root RangeModelType, half of my rescale factor, since it's recommended to set that to 0.5 for the stock system when using Root).

P.S. I'm making a point to explain it clearly in the hopes that someone else comes here with the same questions, so I won't have wasted thread space.

Thanks for all your help, Sigma88 (I would tag people in my posts but I've forgotten how).

[thunder175]

@RocketRyleigh A while back in this thread we ran the calculations for 3.2x and 6.4x rescaling and RemoteTech with root modeling. After running the numbers I think it was 2.17 and 4.34 respectively to get comparable level of antenna performance to stock. See this post here:

 

Edit: Be sure to scroll up and down from the linked post. Should just be plug and chug depending on your rescale.

 

 

Edited February 19, 2017 by thunder175

[RocketRyleigh]

8 hours ago, thunder175 said:

@RocketRyleigh A while back in this thread we ran the calculations for 3.2x and 6.4x rescaling and RemoteTech with root modeling. After running the numbers I think it was 2.17 and 4.34 respectively to get comparable level of antenna performance to stock. See this post here:

 

Edit: Be sure to scroll up and down from the linked post. Should just be plug and chug depending on your rescale.

 

 

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? 

Edited February 20, 2017 by RocketRyleigh