Sigma88

Theoretically not impossible But kopernicus is not build to support that now

kopernicus can make that, and scatter science as well (you can run experiments near a scatter thing to get different results)

that's already a thing

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

@PART { @MODULE[ModuleAblator] { @pyrolysisLossFactor *= 1.5 } } this should be enough

I'm working on it

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

on top of what @Olympic1 already pointed out: if you right click the image and select "copy image address" the address is pretty self explanatory, you just need to change some of the parts to what you want and it will display whatever you want it to display

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?

thank you for pointing that out, I probably never bothered to check that all parameters used the same terminology so I ended up using 2 different terms I will fix that in the OP and from the next release it will be fixed in the README file as well

hi there, I remember some time ago we discussed a bit how scansat ranges work, and how to properly rescale them on resized systems However I completely forgot what the end result of that discussion was, and since I had a bug report about SD not rescaling a ScanSat properly I was wondering if anyone here could refresh my memory on the topic thanks guys

no, Atmosphere and AtmoTopLayer are definitely different things and I gave a brief explanation in the same thread you quoted if you need a more detailed description here are some useful posts 1 2 3 KerikBalm was talking about "Atmospheric height" vs "Atmospheric depth" which are not terms used in SD as far as I remember, and honestly they sound like they are describing the same thing to me I forgot how ScanSat limits work to be honest, I'll ask the developer to refresh my mind so that I can check if SD is doing what it's supposed to

You missed two earlier in the year, and keep looking out because one is coming in a few days (not planet related this time) And yes, there was one on april 1st but nobody seemed to notice And regarding valentine's day... what's more romantic than a full mun? PS: the next one won't be available for sandbox saves

What @Galileo means by is that SD is designed to work with any planet pack, as long as that planet pack's cfgs are written properly In OPM's case they are written properly which means it should be compatible with SD

So there's no water where the rivers are?

I definitely remember the scaledspace texture of kerbin had rivers in it They should be river-shaped elongations of the ocean into the mainlands

wait, doesn't kerbin have some sort of "rivers"?

mountains altitude is calculated multiplying the original altitude by Resize first and by lanscape second. which means with your cfg the mountains are 3*1.5 times bigger than stock (4.5x) if you wanted them to be 1.5x you would have to set landscape to 0.5 so that 3*0.5 = 1.5

while this is not doable with Kopernicus, it is actually doable if you write a plugin for it. I might even look into it just for fun

Have you tried adding ciro to the forbidden list?

It calculates the distance from the center and multiplies it by the rescale parameter If you use the same number for resize and rescale you can just divide your threshold by that number If you use different numbers it gets a bit more complicated

@New Horizons if I understand the situation correctly this is what's going on: you change some values on a stock sized system to be the values you want in a 6.4x system, and then you feed this hybrid system to SD to get it rescaled to 6.4x size your options are: 1- apply your modifications after SD (so that they override SD modifications) 2- apply your modifications before SD but using numbers that are smaller so that when SD changes them they become the numbers you want in your final 6.4x system

Stars are a different type of object and changing their type could cause issues, so I avoid changing them

Incredibly, noone noticed the april's fools easter egg, but many noticed this one... go figure