Galileo Posted April 28, 2017 Share Posted April 28, 2017 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 Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted April 28, 2017 Author Share Posted April 28, 2017 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 Quote Link to comment Share on other sites More sharing options...
DocRockwell Posted April 28, 2017 Share Posted April 28, 2017 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. Quote Link to comment Share on other sites More sharing options...
Jso Posted April 28, 2017 Share Posted April 28, 2017 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. Quote Link to comment Share on other sites More sharing options...
DocRockwell Posted April 28, 2017 Share Posted April 28, 2017 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 } } Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted April 28, 2017 Author Share Posted April 28, 2017 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 Quote Link to comment Share on other sites More sharing options...
DocRockwell Posted April 28, 2017 Share Posted April 28, 2017 Thank you! Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted April 28, 2017 Author Share Posted April 28, 2017 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 Quote Link to comment Share on other sites More sharing options...
StephanVonKermann Posted April 29, 2017 Share Posted April 29, 2017 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? Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted April 29, 2017 Author Share Posted April 29, 2017 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 Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted April 30, 2017 Author Share Posted April 30, 2017 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 Quote Link to comment Share on other sites More sharing options...
Galileo Posted April 30, 2017 Share Posted April 30, 2017 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. Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted April 30, 2017 Author Share Posted April 30, 2017 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? Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 1, 2017 Author Share Posted May 1, 2017 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Eklykti Posted May 1, 2017 Share Posted May 1, 2017 9 hours ago, Sigma88 said: Sigma Dimensions v0.7.7 Github shows only source code archives for that Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 1, 2017 Author Share Posted May 1, 2017 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 Quote Link to comment Share on other sites More sharing options...
DocRockwell Posted May 3, 2017 Share Posted May 3, 2017 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 3, 2017 Author Share Posted May 3, 2017 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) Quote Link to comment Share on other sites More sharing options...
antgeth Posted May 8, 2017 Share Posted May 8, 2017 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 8, 2017 Author Share Posted May 8, 2017 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 Quote Link to comment Share on other sites More sharing options...
somnambulist Posted May 9, 2017 Share Posted May 9, 2017 (edited) 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 Quote Link to comment Share on other sites More sharing options...
antgeth Posted May 10, 2017 Share Posted May 10, 2017 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! Quote Link to comment Share on other sites More sharing options...
Eklykti Posted May 12, 2017 Share Posted May 12, 2017 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Kerbal the Kerbal Posted May 15, 2017 Share Posted May 15, 2017 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. Quote Link to comment Share on other sites More sharing options...
Galileo Posted May 15, 2017 Share Posted May 15, 2017 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? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.