Sigma88 Posted May 1, 2016 Author Share Posted May 1, 2016 15 minutes ago, davidy12 said: The main problem I'm seeing are the clouds are at 30,000m!!!!! clouds get rescaled with planet size, so they are always at the same relative distance from the center of the planet I don't know on which system you are playing, but: 30000/ResizedRadius = NormalCloudsAltitude/NormalRadius Quote Link to comment Share on other sites More sharing options...
davidy12 Posted May 1, 2016 Share Posted May 1, 2016 6.4K. They seemed lower in 1.0.5. Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 1, 2016 Author Share Posted May 1, 2016 10 minutes ago, davidy12 said: 6.4K. They seemed lower in 1.0.5. maybe EVE has changed the config structure? where did you download the clouds you are using? Quote Link to comment Share on other sites More sharing options...
davidy12 Posted May 1, 2016 Share Posted May 1, 2016 Just now, Sigma88 said: maybe EVE has changed the config structure? where did you download the clouds you are using? SVE. But it was the same with the default EVE. Quote Link to comment Share on other sites More sharing options...
Napoleon440 Posted May 1, 2016 Share Posted May 1, 2016 1 hour ago, Sigma88 said: yeah I never understood why exactly that was a problem, since in stock the atmosphere altitude is 70k and the inverseRotThreshold is 100k I will try to test the issue and see if I can find a solution Yep, just doing some trial and error checking the results in the Module Manager cache, I've been able to confirm that with both lines commented out, it defaults to 100k, and then with an Atmosphere value of 1.285, it moves to 128.5k. In fact, it looks like it's 100k for all bodies. I changed line 8 to: @inverseRotThresholdAltitude = #$../Atmosphere/atmosphereDepth$ This sets the warp threshold at the height of each planet's atmosphere. So far, it seems to be working, and looks like it is correct for the other planets with atmospheres in the Module Manager cache. I'll keep testing and let you know if anything weird comes up, but that may do the trick. Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 1, 2016 Author Share Posted May 1, 2016 1 hour ago, davidy12 said: SVE. But it was the same with the default EVE. SVE has the altitude set at 4000 so on 6.4x the altitude gets increased to 25.6 km A lower altitude would mean the clouds could clip through the terrain Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 1, 2016 Author Share Posted May 1, 2016 1 hour ago, Napoleon440 said: Yep, just doing some trial and error checking the results in the Module Manager cache, I've been able to confirm that with both lines commented out, it defaults to 100k, and then with an Atmosphere value of 1.285, it moves to 128.5k. In fact, it looks like it's 100k for all bodies. I changed line 8 to: @inverseRotThresholdAltitude = #$../Atmosphere/atmosphereDepth$ This sets the warp threshold at the height of each planet's atmosphere. So far, it seems to be working, and looks like it is correct for the other planets with atmospheres in the Module Manager cache. I'll keep testing and let you know if anything weird comes up, but that may do the trick. yes, that's what I wanted to try myself, I'm glad to hear it works btw, all stock bodies have inverseRotThresholdAltitude = 100k except jool which has inverseRotThresholdAltitude = 1000k (yes, even the sun has 100k) Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 2, 2016 Author Share Posted May 2, 2016 @Napoleon440 I think I know what your problem was what did you set the "dayLengthmultiplier" to? if you set it at "1" like @GreenWolf suggested that might be too low (you have a 6.4x size kerbin rotating in 6 hours) you should bring that up to about ~4ish that might be the reason why you were getting those "cannottimewarp" issues Quote Link to comment Share on other sites More sharing options...
Napoleon440 Posted May 2, 2016 Share Posted May 2, 2016 That seems to have done the trick as well. Any idea why rotational period would cause the problem? Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 2, 2016 Author Share Posted May 2, 2016 (edited) 51 minutes ago, Napoleon440 said: That seems to have done the trick as well. Any idea why rotational period would cause the problem? do you mean "any idea why rotation period would cause issues with a shift from a rotating reference frame to a fixed reference frame?" jokes aside, I don't know why it would, but it seems reasonable Edited May 2, 2016 by Sigma88 Quote Link to comment Share on other sites More sharing options...
Napoleon440 Posted May 2, 2016 Share Posted May 2, 2016 I used to think I was smart until I started playing KSP. I guess the only question I have left is, should the daylengthmultiplier value be tied to one of the other multipliers since leaving it as-is causes the problem, or is the workaround with atmo height a better fix. Seems like messing with day length could have some [un]intended consequences for synchronous orbits among other things. Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 3, 2016 Author Share Posted May 3, 2016 50 minutes ago, Napoleon440 said: I used to think I was smart until I started playing KSP. I guess the only question I have left is, should the daylengthmultiplier value be tied to one of the other multipliers since leaving it as-is causes the problem, or is the workaround with atmo height a better fix. Seems like messing with day length could have some [un]intended consequences for synchronous orbits among other things. I've decided to let it be a different parameter because people can get pretty nitpicky about that kind of stuff and there are many ways to approach rotation period modifications. but you definitely need to change it when you rescale a planet. if you use 6.4x resize a 4x dayLengthMulti should work just fine Quote Link to comment Share on other sites More sharing options...
HansB Posted May 3, 2016 Share Posted May 3, 2016 (edited) Also posted this in RSS I'm using Sigma and now it throws some errors : Applying node Sigma/Dimensions/Configs/ReDimension/setKSCSwitcher/@KSCSWITCHER:FOR[SigDim2] to KSCSwitcher/LaunchSites/KSCSWITCHER [ModuleManager] Error - Failed to do a maths replacement: @PQSMod_MapDecalTangent : original value="80E" operator=* mod value="0.9255" [ModuleManager] Error - Failed to do a maths replacement: @PQSMod_MapDecalTangent : original value="0" operator=+ mod value="80E" When i search for that 80E it's here: name = jp_tanegashima displayName = JP - Tanegashima description = The Tanegashima Space Center (種子島宇宙センター, Tanegashima Uchū Sentā) (TNSC) is a Japanese space development facility. It is located on Tanegashima, an island located 115 km south of Kyushu. It was established in 1969 when the National Space Development Agency of Japan (NASDA) was formed, and is now run by JAXA. The activities that take place at TNSC include assembly, testing, launching and tracking of satellites, as well as rocket engine firing tests. It is Japan's largest space development center. PQSCity { KEYname = KSC latitude = 30.39096 longitude = 130.96813 repositionRadiusOffset = 71 repositionToSphereSurface = false lodvisibleRangeMult = 6 reorientFinalAngle = -221 } PQSMod_MapDecalTangent { radius = 5500 heightMapDeformity = 80E absoluteOffset = 0 absolute = true latitude = 30.39096 longitude = 130.96813 } I guess it's a typo???? Is it also possible to change the versioning to 1.1.2, KSP-AVC always pops up, pfffffff Edited May 3, 2016 by HansB Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 3, 2016 Author Share Posted May 3, 2016 33 minutes ago, HansB said: Also posted this in RSS I'm using Sigma and now it throws some errors : Applying node Sigma/Dimensions/Configs/ReDimension/setKSCSwitcher/@KSCSWITCHER:FOR[SigDim2] to KSCSwitcher/LaunchSites/KSCSWITCHER [ModuleManager] Error - Failed to do a maths replacement: @PQSMod_MapDecalTangent : original value="80E" operator=* mod value="0.9255" [ModuleManager] Error - Failed to do a maths replacement: @PQSMod_MapDecalTangent : original value="0" operator=+ mod value="80E" When i search for that 80E it's here: name = jp_tanegashima displayName = JP - Tanegashima description = The Tanegashima Space Center (種子島宇宙センター, Tanegashima Uchū Sentā) (TNSC) is a Japanese space development facility. It is located on Tanegashima, an island located 115 km south of Kyushu. It was established in 1969 when the National Space Development Agency of Japan (NASDA) was formed, and is now run by JAXA. The activities that take place at TNSC include assembly, testing, launching and tracking of satellites, as well as rocket engine firing tests. It is Japan's largest space development center. PQSCity { KEYname = KSC latitude = 30.39096 longitude = 130.96813 repositionRadiusOffset = 71 repositionToSphereSurface = false lodvisibleRangeMult = 6 reorientFinalAngle = -221 } PQSMod_MapDecalTangent { radius = 5500 heightMapDeformity = 80E absoluteOffset = 0 absolute = true latitude = 30.39096 longitude = 130.96813 } I guess it's a typo???? Is it also possible to change the versioning to 1.1.2, KSP-AVC always pops up, pfffffff Yes that is a typo, I blame @KillAshley The version is not yet 1.1.2 because I still need to change some configs before updating the mod Quote Link to comment Share on other sites More sharing options...
KillAshley Posted May 3, 2016 Share Posted May 3, 2016 (edited) 2 minutes ago, Sigma88 said: Yes that is a typo, I blame @KillAshley The version is not yet 1.1.2 because I still need to change some configs before updating the mod wasnt me, thats a new typo by someone else Edited May 3, 2016 by KillAshley Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 3, 2016 Author Share Posted May 3, 2016 Just now, KillAshley said: wasnt me, thats an old typo I still blame you Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 3, 2016 Author Share Posted May 3, 2016 Ok guys, I've finished updating SD to 1.1.2 if no bugs are reported I should be able to release the new version today so, if you have seen bugs, now would be the best moment to report them Quote Link to comment Share on other sites More sharing options...
Napoleon440 Posted May 3, 2016 Share Posted May 3, 2016 The only other issue I've had is re-entry is absolutely killing me. Ablator is burning up (200 units on the procedural heat shields) on re-entry just from low orbit on my 6.4x scale while still pulling almost lethal G's with Deadly Re-Entry. I was digging through RO-Mini to see how it's handled there since I wasn't having the issue when I tinkered with RSS recently. I was going to try and add something like this to see if it helped: // Heat shields @PART[*]:HAS[@MODULE[ModuleAblator]] { @MODULE[ModuleAblator] { @lossConst *= 0.1 //I'm thinking should be 1/x where x is one of the SD config values } } Haven't had a chance to actually test it yet, but was going to check it out later tonight. Quote Link to comment Share on other sites More sharing options...
blowfish Posted May 3, 2016 Share Posted May 3, 2016 @Napoleon440 You could also try reducing re-entry heat in the settings. Stock heating is tuned to provide an interesting experience in the stock solar system. In 6.4x you're going a lot faster on re-entry so heat is going to be unmanageable. You could also try RealHeat (realistic heating will be slightly easier than real life in a 6.4x system). Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 3, 2016 Author Share Posted May 3, 2016 6 minutes ago, Napoleon440 said: The only other issue I've had is re-entry is absolutely killing me. Ablator is burning up (200 units on the procedural heat shields) on re-entry just from low orbit on my 6.4x scale while still pulling almost lethal G's with Deadly Re-Entry. I was digging through RO-Mini to see how it's handled there since I wasn't having the issue when I tinkered with RSS recently. I was going to try and add something like this to see if it helped: // Heat shields @PART[*]:HAS[@MODULE[ModuleAblator]] { @MODULE[ModuleAblator] { @lossConst *= 0.1 //I'm thinking should be 1/x where x is one of the SD config values } } Haven't had a chance to actually test it yet, but was going to check it out later tonight. I've added new cfg in the dev version to change reentry heating Try to use that one, you should find it works better than the release version Quote Link to comment Share on other sites More sharing options...
Napoleon440 Posted May 3, 2016 Share Posted May 3, 2016 (edited) Yeah, I've got Real Heat and have been running off the dev version of SD. I was hoping to find a way that felt a little less "cheaty". I've been looking for way to raise the max amount of ablator on heat shields so they just hold more, or reducing the rate it burns off. In both instances, mass would be added proportionally to offset the change making it "not cheaty". Anyway, that's just me. I'm one of the types that likes the added challenge of a 6.4x scale, but isn't quite ready to tackle RSS/RO. Plus, I really do like the stock system and parts. Edited May 3, 2016 by Napoleon440 Quote Link to comment Share on other sites More sharing options...
Akira_R Posted May 4, 2016 Share Posted May 4, 2016 (edited) I'm using the 64k rescale and SVE and the clouds are really high up there as some people have said, will changing the atmoVisualEffect parameter affect the height of the clouds? Or is the only way to fix it to go into the SVE cfgs and adjust all of the cloud heights? EDIT: NVM did more searching and found my answer, thank you! for those that are lazy, only way to change eve cloud heights is by editing the eve cloud cfg, this can be done with a MM patch Edited May 4, 2016 by Akira_R Quote Link to comment Share on other sites More sharing options...
Norcalplanner Posted May 4, 2016 Share Posted May 4, 2016 8 hours ago, Napoleon440 said: Yeah, I've got Real Heat and have been running off the dev version of SD. I was hoping to find a way that felt a little less "cheaty". I've been looking for way to raise the max amount of ablator on heat shields so they just hold more, or reducing the rate it burns off. In both instances, mass would be added proportionally to offset the change making it "not cheaty". Anyway, that's just me. I'm one of the types that likes the added challenge of a 6.4x scale, but isn't quite ready to tackle RSS/RO. Plus, I really do like the stock system and parts. I've been using SMURFF with my 6.4x Sigma Dimensions game with a 0.5 lever. It helps a lot with everything, but reentry in particular because it reduces the weight of both capsules and heatshields. With less weight to slow down, heating isn't as bad. I will note that I've adjusted heating with the stock slider down to 80 or 90%, and the combination of the slider and SMURFF means you don't have to worry about Real Heat or anything else which is more in depth. Quote Link to comment Share on other sites More sharing options...
Sigma88 Posted May 4, 2016 Author Share Posted May 4, 2016 (edited) 5 hours ago, Akira_R said: for those that are lazy, only way to change eve cloud heights is by editing the eve cloud cfg, this can be done with a MM patch Sigma Dimensions changes the altitude of clouds using "Resize" as a multiplier this way the clouds are always the same relative distance from the center (and surface) of the planet to anyone having reentry problems: I'm still learning how to properly tweak those parameters but, I have tested reentry on flat 10x resize / 10x Atmosphere comparing it with a similar reentry on 1x Size 1x Atmosphere and this is the result: both test are done using a 3 part vessel Mk1-2 Command Pod Mk16-XL Parachute 2.5 meter heat shield in stock: hyperedit the ship to a 100x25 orbit reentry consumes about 1/3 heat shield in 10x resize: hyperedit to a 1000x250 orbit reentry consumes about 2/3 heat shield max temperature experienced are comparable as far as I can tell any additional difficulty on reentry is caused by the setup (for example using an Atmosphere parameter lower than the Resize parameter) this is kinda the whole point of using a resize, so I think it's a good balance. I don't think I will introduce changes in the parts, since doing that would result in conflicts in other part mods like SMURFF Edited May 4, 2016 by Sigma88 Quote Link to comment Share on other sites More sharing options...
ThorBeorn Posted May 5, 2016 Share Posted May 5, 2016 (edited) I am trying to import Earths atmosphere from RSS to a 10 x Kerbin using Sigma. However, I still get the scaled atmosphere from Sigma (using factor 1.5 in "Sigma/Dimensions/settings.cfg"). What am I doing wrong here? @Kopernicus:Final { @Body[Kerbin] { @Properties { radius = 6371000 // 1/10:th of earth, later rescaled x10 by Sigma } @Atmosphere { AtmosphereFromGround { innerRadius = 6307290 // 0.99 radius = 6371000 m outerRadius = 6530280 // 1.025 radius = 6371000 m waveLength = 0.65, 0.58, 0.5, 1.0 } ambientColor = 0.05,0.05,0.05,1 lightColor = 0.65, 0.58, 0.5, 1.0 maxAltitude = 140000.0 pressureCurve { key = 0 101.325 0 -0.0119728 key = 1000 89.9533 -0.0107930 -0.0107930 key = 2000 79.7002 -0.00972796 -0.00972796 key = 3000 70.4681 -0.00875299 -0.00875299 key = 4000 62.1611 -0.00787622 -0.00787622 key = 5000 54.6878 -0.00708318 -0.00708318 key = 6000 47.9713 -0.00636065 -0.00636065 key = 7000 41.9464 -0.00569841 -0.00569841 key = 8000 36.5557 -0.00509245 -0.00509245 key = 9000 31.7442 -0.00453808 -0.00453808 key = 10000 27.4653 -0.00402673 -0.00402673 key = 12000 20.3414 -0.00312263 -0.00312263 key = 14000 14.8737 -0.00237047 -0.00237047 key = 16000 10.7635 -0.00176010 -0.00176010 key = 18000 7.75613 -0.00126803 -0.00126803 key = 20000 5.60721 -0.000901039 -0.000901039 key = 22000 4.07935 -0.000642531 -0.000642531 key = 24000 2.98525 -0.000462105 -0.000462105 key = 26000 2.19595 -0.000334419 -0.000334419 key = 28000 1.62339 -0.000243181 -0.000243181 key = 30000 1.20625 -0.000177515 -0.000177515 key = 35000 0.587912 -8.24999E-05 -8.24999E-05 key = 40000 0.296475 -3.95921E-05 -3.95921E-05 key = 45000 0.154505 -1.96895E-05 -1.96895E-05 key = 50000 0.0823932 -1.02964E-05 -1.02964E-05 key = 55000 0.0438116 -5.63015E-06 -5.63015E-06 key = 60000 0.0226627 -3.07308E-06 -3.07308E-06 key = 65000 0.0112639 -1.62393E-06 -1.62393E-06 key = 70000 0.00535122 -8.22379E-07 -8.22379E-07 key = 75000 0.00242788 -3.93412E-07 -3.93412E-07 key = 80000 0.00106419 -1.78176E-07 -1.78176E-07 key = 85000 0.000456540 -7.80320E-08 -7.80320E-08 key = 90000 0.000192994 -3.33998E-08 -3.33998E-08 key = 95000 8.14506E-05 -1.38984E-08 -1.38984E-08 key = 100000 3.54530E-05 -5.71581E-09 -5.71581E-09 key = 105000 1.63277E-05 -2.42049E-09 -2.42049E-09 key = 110000 8.14746E-06 -1.04679E-09 -1.04679E-09 key = 115000 4.54713E-06 -4.77713E-10 -4.77713E-10 key = 121920 2.39321E-06 -1.98618E-10 -1.98618E-10 key = 140000 0 0 0 } } } } Edit: To be precise, this patch doesn't change Kerbins atmosphere. It remains at 70km x 1.5 = 105 km height. But I want it to be equal to Earths atmosphere, same height, same pressure at any given altitude etc. Oh and radius doesn't apply either, it remains at 6000 km after Sigma scales it. Edited May 5, 2016 by ThorBeorn 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.