Sigma Dimensions

[Galileo]

1 hour ago, Sigma88 said:

so, SD should multiply all the altitude limits by the parameters scanAltitude and Resize

if what you are seeing does not fit this behaviour please get in contact with me so we can take a deeper look

@Galileo just to be sure, SSRSS doesn't mess with scanSat stuff right?

RSS does and it's a dependency. I assume the mm cfg in there is what is causing an issue. I could probably write another mm cfg and reset the scan height for stock sizes. I think that is possible

[Sigma88]

1 hour ago, Galileo said:

RSS does and it's a dependency. I assume the mm cfg in there is what is causing an issue. I could probably write another mm cfg and reset the scan height for stock sizes. I think that is possible

depending on how you are using SD you will need to approach this differently

1- values in PARTS are multiplied by Rescale  and  scanAltitude

2- values in SCAN_Color_Config are multiplied by Rescale, landscape and  scanAltitude

all of those parameters are taken from the main SigmaDimensions node, which means that:

1- if you use planet specific changes they won't affect the scansat rescale

2- if the main SD node has resize = 0.1 then the values must be those applied by RSS (which I suppose will be 10x) so that SD can bring them back to stock size (10*0.1 = 1)... if RSS scan altitudes are not 10x, then you might consider changing the scanAltitude parameter so that you can get the result you like best (no need to go and mess with the scansat parameters direclty)

3- if you still rather re-define all scan altitudes manually, make sure you do that after SD so that you can override any changes applied by SD

[DocRockwell]

Hey @Sigma88, perhaps this is a question that's up  your alley. It has to do with game physics and reentry heating. I'm playing with Half Scale Real Solar System + Sigma Dimensions to scale it down a touch more (why not just use SSRSS? I want a ~6000 dV to LEO scale Earth so SSTU Low Part Count rockets balance nicely, but I also want RSS Constellations planets to be reasonably sized), and my heatshields were burning up way to fast and early on simple LEO reentries. I think it's largely due to the "machTemperatureScalar" parameter in the physics.cfg and was wondering if you knew more about these settings.

 

SD is a brilliant mod by the way.

 

Cheers.

[Jso]

45 minutes ago, DocRockwell said:

Hey @Sigma88, perhaps this is a question that's up  your alley. It has to do with game physics and reentry heating. I'm playing with Half Scale Real Solar System + Sigma Dimensions to scale it down a touch more (why not just use SSRSS? I want a ~6000 dV to LEO scale Earth so SSTU Low Part Count rockets balance nicely, but I also want RSS Constellations planets to be reasonably sized), and my heatshields were burning up way to fast and early on simple LEO reentries. I think it's largely due to the "machTemperatureScalar" parameter in the physics.cfg and was wondering if you knew more about these settings.

 

SD is a brilliant mod by the way.

 

Cheers.

You want to increase ModuleAblator's pyrolysisLossFactor by maybe 25-50%. This is how SMURFF handles heatshields.

[DocRockwell]

5 minutes ago, Jso said:

You want to increase ModuleAblator's pyrolysisLossFactor by maybe 25-50%. This is how SMURFF handles heatshields.

Sweet, thanks! 

Increase it to reduce the rate that the heatshield burns? 

I'm not really familiar with MM, does this look correct to you, for increasing the value by 50%?

@PART[*]:HAS[@RESOURCE[Ablator]
{
    
    @MODULE[ModuleAblator]
    {
        @pyrolysisLossFactor *= 1.5
    }
}

[Sigma88]

2 minutes ago, DocRockwell said:

Sweet, thanks! 

Increase it to reduce the rate that the heatshield burns? 

I'm not really familiar with MM, does this look correct to you, for increasing the value by 50%?

@PART[*]:HAS[@RESOURCE[Ablator]
{
    
    @MODULE[ModuleAblator]
    {
        @pyrolysisLossFactor *= 1.5
    }
}

@PART
{
	@MODULE[ModuleAblator]
	{
		@pyrolysisLossFactor *= 1.5
	}
}

 

this should be enough

[DocRockwell]

Thank you!

[Sigma88]

1 minute ago, DocRockwell said:

Thank you!

and to answer your original question, reentry heating is something I never fully grasped.

SD tries to do some kind of handling but ultimately I found that the best way is to adjust the reentry heating manually untill you are satisfied with the result

[StephanVonKermann]

I am not sure if it's the cause but there is a file in SSRSS for sigma with a scanAltitude = 1 parameter.  What is the best way to contact you?

[Sigma88]

24 minutes ago, StephanVonKermann said:

I am not sure if it's the cause but there is a file in SSRSS for sigma with a scanAltitude = 1 parameter.  What is the best way to contact you?

Just write here

If it's a issue with SSRSS and SD you should probably try to contact @Galileo first

 

For this specific issue I think SD is working as intended but SSRSS being  bit unusual probably has some fixes to add to its cfgs

The team knows about this issue so I think they will be able to fix it in the next release

[Sigma88]

Sigma Dimensions v0.7.6

This release adds some minor fixes for atmospheres and LandControl

 

Many thanks to @OhioBob for continuing to harass assist me

Thanks also to @GregroxMun for finding a bug in LandControl resizing

 

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)
- Thomas P. (Kopernicus)

 

Changelog:

v0.7.6

- Tweaked Atmosphere resize when using atmoTopLayer
- Fixed LandControl resize
- Fixed PQS levels for oceans on very small planets

[Galileo]

Thanks for the update sigma! in the future, how would you feel about making the terrain texture scale a custom thing. I know I was the one that had you implement the current way things are done, and it works great for SSRSS when being shrunken down to stock size, but scaled up causes the textures to seem VERY small and clearly tiled. I think I remember you saying you could make that a custom setting, but I didn't want to burden you with more work. 

[Sigma88]

1 minute ago, Galileo said:

Thanks for the update sigma! in the future, how would you feel about making the terrain texture scale a custom thing. I know I was the one that had you implement the current way things are done, and it works great for SSRSS when being shrunken down to stock size, but scaled up causes the textures to seem VERY small and clearly tiled. I think I remember you saying you could make that a custom setting, but I didn't want to burden you with more work. 

ah yes, a reminder 5 minutes ago would have saved me from making 2 releases

I'll see if I can fit it into the next one

please could you PM me some details about this? so I can start thinking how to approach it?

[Sigma88]

Sigma Dimensions v0.7.7

This release adds a new parameter that handles ground textures tiling, which will be off by default.

This change comes to solve an issue pointed out by @Galileo where SD used to automatically change the tiling of a planet and the result was not good.

 

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)
- Thomas P. (Kopernicus)

 

Changelog:

v0.7.7 - Added the parameter groundTiling - Ground textures tiling is now off by default and can be changed using groundTiling

Edited May 1, 2017 by Sigma88

[Eklykti]

 

9 hours ago, Sigma88 said:

Sigma Dimensions v0.7.7

Github shows only source code archives for that

[Sigma88]

2 minutes ago, Eklykti said:

 

Github shows only source code archives for that

apparently there was an error in the upload of the zip, thanks for reporting it

it's fixed now

[DocRockwell]

Does SD tend to affect anomalies like monoliths? I've visited a few anomaly sights on the Moon and haven't been able to find anything, just wondering if it's because I shrunk things a bit with using only the RESIZE paramter.

Edited May 3, 2017 by DocRockwell

[Sigma88]

2 hours ago, DocRockwell said:

Does SD tend to affect anomalies like monoliths? I've visited a few anomaly sights on the Moon and haven't been able to find anything, just wondering if it's because I shrunk things a bit with using only the RESIZE paramter.

SD resizes the altitude of anomalies so that they should show up where expected

Unless you changed the resizeBuildings parameter, SD will by default resize anonalies when shrinking a planet, which means anomalies will be smaller than what you expect, but it also means that you have the best chance of finding them where you expext them to be

But generally speaking ksp is not very good with automatical anomalies repositioning, which means it's still possible they are still not positioned correctly (floating above ground or buried in it)

[antgeth]

is there a good rule of thumb on how to (roughly) calculate delta-v budgets? a simple formula where you plugin the resize/rescale factor in combined with the traditional number?  i love playing at 2x, but i have no idea what i need to plan for in mission designs.  it needn't be exact, just something that will give me the right ballpark.

Edited May 8, 2017 by antgeth

[Sigma88]

36 minutes ago, antgeth said:

is there a good rule of thumb on how to (roughly) calculate delta-v budgets? a simple formula where you plugin the resize/rescale factor in combined with the traditional number?  i love playing at 2x, but i have no idea what i need to plan for in mission designs.  it needn't be exact, just something that will give me the right ballpark.

I have no idea

but I bet some people know for sure, there is a formula you can use, I just don't remember it right now

[somnambulist]

2 hours ago, antgeth said:

is there a good rule of thumb on how to (roughly) calculate delta-v budgets? a simple formula where you plugin the resize/rescale factor in combined with the traditional number? 

I'm playing in a 3.2 rescale, using a formula posted by @GregoxMun for dV calculation. I haven't double checked the numbers but so far it seems like an accurate guideline.

Quote

(d(Sqrt of x))=D. Where d is original scale delta-v, X is the scale factor, and D is the rescaled delta-v.

A Mun transfer from LKO in stock is about 860 m/s. In a 2x system, the transfer would be 860 m/s * √2 = 1216m/s. In my 3.2x game the same transfer is 860 m/s * √2 = 1538 m/s

Edit: Or just to make it easy on yourself, multiply all dV requirements by 1.42. Sqrt of 2 is 1.41 and change, round-up to 1.42 for margin of error and because it's 1 more than The Answer. Or round-up to 1.5x to make it easier to do the math in your head and give an even larger margin of error. 

 

 

Edited May 9, 2017 by somnambulist

[antgeth]

On Monday, May 08, 2017 at 6:37 PM, somnambulist said:

I'm playing in a 3.2 rescale, using a formula posted by @GregoxMun for dV calculation. I haven't double checked the numbers but so far it seems like an accurate guideline.

A Mun transfer from LKO in stock is about 860 m/s. In a 2x system, the transfer would be 860 m/s * √2 = 1216m/s. In my 3.2x game the same transfer is 860 m/s * √2 = 1538 m/s

Edit: Or just to make it easy on yourself, multiply all dV requirements by 1.42. Sqrt of 2 is 1.41 and change, round-up to 1.42 for margin of error and because it's 1 more than The Answer. Or round-up to 1.5x to make it easier to do the math in your head and give an even larger margin of error. 

 

 

most excellent, thanks!

[Eklykti]

In case if it's useful for someone, there's an MM patch to move KSC closer to the water in 10x scale:

@Kopernicus:FINAL
{
	@Body[Kerbin]
	{
		%SpaceCenter
		{
			%latitude = -0.3
			%longitude = -74.44
			%repositionToSphereSurface = True
			%repositionToSphereSurfaceAddHeight = True
			%repositionRadiusOffset = -22
		}
	}
}

Edited May 12, 2017 by Eklykti
Added screenshot

[Kerbal the Kerbal]

It does not work for me. I use a Mac OS X El Capitan to play KSP. Is this able to be supported for mac users? I am able to edit the .cfg files using text edit, but it has no effect.

[Galileo]

23 minutes ago, Kerbal the Kerbal said:

It does not work for me. I use a Mac OS X El Capitan to play KSP. Is this able to be supported for mac users? I am able to edit the .cfg files using text edit, but it has no effect.

Do you have kopernicus installed?