Sigma Dimensions

[Sigma88]

35 minutes ago, Streetwind said:

The more interesting stuff is in his second psot a little further down. I just linked this one because it's what he keeps referencing.

oh yeah, I saw that one after I replied to you... that might help

[Sigma88]

@Streetwind I've added the reEntryHeat parameter and a cfg to change heating on reentry

If you dl the dev version you can try it out

edit:

I have just tested it and I think it's definitely an improvement

Edited April 11, 2016 by Sigma88

[Streetwind]

Been spending my free time debugging Near Future, but will definitely check this out soon.

[thunder175]

23 hours ago, Sigma88 said:

@Streetwind I've added the reEntryHeat parameter and a cfg to change heating on reentry

If you dl the dev version you can try it out

edit:

I have just tested it and I think it's definitely an improvement

 

What's the significance of the change? Was there a problem with the last dev version that this is fixing? I haven't noticed much in the way of heating issues although I am using RealHeat. But maybe that is the problem?

 

On a side note, can you give us some recommended settings that you use or maybe even a physics.cfg patch like RO for the AeroFX on a scaled up Kerbin? Tired of my rocket glowing red and eating FPS (although no heating, just the FX) at 40km-60km on a 1.2857 multiplied atmosphere (90km atmospheric boundary). I'm hesitant to eject my fairings when I'm getting the FX even though FAR data is saying there is virtual no density and almost no drag, so I'm probably holding on to dead weight longer than I need to. Or do I just need to throttle back on my gravity turn?

 

On another side note, still loving 3.2x rescale and 6.4x resize. I even removed SMURFF since I didn't feel like fiddling with the multiplier value since 0.5 felt like overkill at 3.2x. At 3.2x, its taking just shy of 5700m/s to a 185km orbit. MJ is working perfectly with a 120km final turn altitude. I'm getting nice continuous orbital insertion burns without requiring engine restarts to get the Pe above the atmosphere. 6.4x resize is awesome with RT transmission delays.

 

Lastly, does anyone know how to calculate μ(km³s^-2) for rescaled planets? I'm trying to use the RemoteTech planner web app (https://ryohpops.github.io/kspRemoteTechPlanner/) and am inputting the newly sized planets as user add-ons, but without the standard gravity parameter it breaks most of the pages functionality. I am terrible at the math and am unsure of what to put in that space.

[Sigma88]

2 hours ago, thunder175 said:

What's the significance of the change? Was there a problem with the last dev version that this is fixing? I haven't noticed much in the way of heating issues although I am using RealHeat. But maybe that is the problem?

if you try playing on a stock install (no mods other than SD and its requirements) you will notice that on a 10x reentring the atmosphere from LKO burns away basically all your heatshield in a few seconds (which is not fun)

the change I've added is similar to what the physics.cfg patch of RSS but it's still a very rough version (I change only 1 parameter)

I'm currently stalking ppl that know about atmospheres like ferram and nathankell because I hope to get some help with that

I'm not sure about realheat, but maybe realheat was already fixing this for your

 

2 hours ago, thunder175 said:

On a side note, can you give us some recommended settings that you use or maybe even a physics.cfg patch like RO for the AeroFX on a scaled up Kerbin? Tired of my rocket glowing red and eating FPS (although no heating, just the FX) at 40km-60km on a 1.2857 multiplied atmosphere (90km atmospheric boundary). I'm hesitant to eject my fairings when I'm getting the FX even though FAR data is saying there is virtual no density and almost no drag, so I'm probably holding on to dead weight longer than I need to. Or do I just need to throttle back on my gravity turn?

I don't know enough about the physics.cfg parameters, that's why I'm still working on those.

My idea for the mod is to get everything fixed inside the mod (using the rescale/resize parameters to tweak those parameters)

for example the change I just added is calculating the orbital speed around the planet, and making sure that hitting the atmosphere in a rescaled planet you will generate the same heat you would generate in a stock install. (so basically, if in stock kerbin at 10% of your descent into the atmosphere your shield is being heated at 6000K, when you rescale everythink 10x you should expect to see more or less the same temperature)

this fix might also affect the "glowing red effect" you are seeing (but I can't be sure)

 

2 hours ago, thunder175 said:

Lastly, does anyone know how to calculate μ(km³s^-2) for rescaled planets? I'm trying to use the RemoteTech planner web app (https://ryohpops.github.io/kspRemoteTechPlanner/) and am inputting the newly sized planets as user add-ons, but without the standard gravity parameter it breaks most of the pages functionality. I am terrible at the math and am unsure of what to put in that space.

if by μ(km³s^-2) you mean GM (I would guess so)

then this is the formula to calculate it:

G = 6.674e-11
M = mass of the rescaled planet

to get the mass of the rescaled planet you need to do this:

mass of the rescaled planet = mass of the old planet * (Resize ^ 2)

 

unless you have changed the geeASL parameter in SD (in which case the formula would be different)

 

so if you already know the old GM you just need to multiply it by Resize squared.

 

I have to warn you tho, that SD changes the range of all antennas, not by changing the " Range Multiplier " (which would be the proper way to do it) but changing the PART cfg file (which is the wrong way to do it)

 

sadly RT doesn't allow MM to edit that parameter, so I have my hands tied for now

 

nevermind that, I found out how to fix it, now SD will set the rangemultiplier to equal the Rescale parameter

Edited April 12, 2016 by Sigma88

[thunder175]

@Sigma88 Acknowledge all. Just a few things.

First I looked at the RO physics.cfg file and he makes tweaks to the AeroFX section. Looks like he changes the variables for a 10x RSS system. Problem is when I applied the RO AeroFX changes on my 3.2x Kerbin, I was getting virtually no atmospheric visual effects at all even on reentry. So clearly something needs to be tweaked for larger than stock, but smaller than 10x systems in regards to the aeroFX settings. I defer to your discussions with the other developers. 

Second, on the math. Thanks! I think I did it right based on the equation you gave and I came out to 36163.584. When I used that in the web app it was giving me numbers very close to what I was seeing in game, so I guess I got that right. 

Third and most importantly on the RT multiplier. Great work but I don't think that is what we want if we are using the root model instead of standard described in the settings addendum (https://remotetechnologiesgroup.github.io/RemoteTech/guide/settings/). Reason is that a 0.5 mulitiplier is recommended by the developer if using the root model. He gives the math equation used, and I'd have to run the numbers but I think if you apply a patch changing the value of the global RT antenna multiplier it would give drastically increased ranges when using the root model. Those using standard modeling will probably be OK since it is defaulted to 1 and is basically an either can talk-can't talk scenario based on the max effective range of a given antenna. Can you double-check my thinking on this?

 

[Sigma88]

59 minutes ago, thunder175 said:

First I looked at the RO physics.cfg file and he makes tweaks to the AeroFX section. Looks like he changes the variables for a 10x RSS system. Problem is when I applied the RO AeroFX changes on my 3.2x Kerbin, I was getting virtually no atmospheric visual effects at all even on reentry. So clearly something needs to be tweaked for larger than stock, but smaller than 10x systems in regards to the aeroFX settings. I defer to your discussions with the other developers.

I'm currently documenting myself on the math behind those parameters, as soon as I get a proper grasp of what needs changing I will tweak everything that needs tweaking.

I'm not sure about your setup, but on a stock game, and talking only about graphic effects (the "fire" that envelops the capsule on reentry), I get more or less the same reentry effects in 1x (stock) and 10x (with sigma dimensions)

so maybe there is something else that changes that for you

just to make sure we are on the same page, when you say "atmospheric visual effects" you mean this right?

1 hour ago, thunder175 said:

Third and most importantly on the RT multiplier. Great work but I don't think that is what we want if we are using the root model instead of standard described in the settings addendum (https://remotetechnologiesgroup.github.io/RemoteTech/guide/settings/). Reason is that a 0.5 mulitiplier is recommended by the developer if using the root model. He gives the math equation used, and I'd have to run the numbers but I think if you apply a patch changing the value of the global RT antenna multiplier it would give drastically increased ranges when using the root model. Those using standard modeling will probably be OK since it is defaulted to 1 and is basically an either can talk-can't talk scenario based on the max effective range of a given antenna. Can you double-check my thinking on this?

well, if you multiply the range of the antennas by a value n then the equation for the root range becomes:

Min(r1*n, r2*n) + sqrt(r1*n*r2*n)

doing some algebra we get:

Spoiler

newrange = n* Min(r1,r2) + sqrt(r1*r2 * n^2)

newrange = n* Min(r1,r2) + sqrt(r1*r2) * n

newrange = n * (Min(r1,r2)+sqrt(r1*r2))

newrange = n * standardrange

 

it should be possible for me to check if you have the root model enabled, and tweak the RangeMultiplier accordingly

[thunder175]

29 minutes ago, Sigma88 said:

so maybe there is something else that changes that for you

just to make sure we are on the same page, when you say "atmospheric visual effects" you mean this right?

Yes your pic is what I'm talking about. Only things on my modded game that should be changing anything is RealHeat. So not sure if that is my problem or not, or if I even have a problem. I just noticed that RO/RSS changes some of the physics.cfg settings including aeroFX which is why I was asking. I can live with it since it doesn't seem that its actually causing any additional heating, and even FAR data is showing almost no atmosphere and drag.

 

29 minutes ago, Sigma88 said:

it should be possible for me to check if you have the root model enabled, and tweak the RangeMultiplier accordingly

Ok great. Again, just wanted to make sure resetting the global RT multiplier wouldn't throw out the recommended setting when running root/additive modes. Because currently RT takes the multiplier (0.5 in my case) and applies that to the existing antenna range. So a 90Mm ranged antenna is listed at 45Mm in stock. And then the previous SD multiplier was applied, which in my case is 6.4x, raising the max antenna range listed to 288Mm with other math associated with the root model applied by RT to actually close the link. 

[Sigma88]

1 hour ago, thunder175 said:

Ok great. Again, just wanted to make sure resetting the global RT multiplier wouldn't throw out the recommended setting when running root/additive modes. Because currently RT takes the multiplier (0.5 in my case) and applies that to the existing antenna range. So a 90Mm ranged antenna is listed at 45Mm in stock. And then the previous SD multiplier was applied, which in my case is 6.4x, raising the max antenna range listed to 288Mm with other math associated with the root model applied by RT to actually close the link. 

I'm still trying to get the feature working properly, so if I were you I wouldn't download the dev.version just yet

edit:

well, I gave up. the amount of bad decisions ("code"wise) I would have to make to get around RT cfg structure limitations is too high for my liking. (expecially considering that the alternative is pretty easy to do, see bottom of post)

 

SD Remote Tech compatibility:

from now on, if any of you want to play with RT and SD together, you just need to change the RangeMultiplier in the RemoteTech_Settings.cfg file (found in the RemoteTech installation folder)

that's the best way solution by far.

My suggestion would be to set the RangeMultiplier to be the same as the "Rescale" parameter you use for SD

or half the "Rescale" if like @thunder175 you use root mode

Edited April 13, 2016 by Sigma88

[thunder175]

@Sigma88 Thanks for the great work on this. So if you have abandoned changes for RT, is it safe to use the newer dev versions again for those using root mode? In all honesty I feel fine with the way it is. I think the antenna ranges are still scaling properly without changing the RT settings config IMHO. The only real problem I am seeing is that antennas that may be on the edge for KEO in stock scaling won't rescale correctly and may not reach a larger stable KEO. But that is easily correctable with another part specific patch or just use a bigger dish. For example, the AIES CL-1 is perfect for low power KEO work. It defaults to 9Mm range. With my previously mentioned root and multiplier settings, that range gets halved, then multiplied by SD's setting of 6.4 for a max range of 28.8Mm, well within KEO for a 3.2x Kerbin. The DTS-1 using the same math is getting me out to 288Mm, good enough to close a link to Minmus.

Actually just had another thought. I may be feeling its fine since I am running 3.2x/6.4x. What is KEO for a straight up 6.4x system? 3.2x KEO is 17037km. I'm not doing anything really long range yet beyond Kerbin SOI, so again your mileage may vary.

I also tweaked the RT settings config file by adding ground stations. The biggest change here of note to users in this thread is dramatically increasing the range of the KSC dish. When using root mode it will close a link even beyond the max range of a given antenna. This is both good and bad IMHO. I also added a bunch of tier 2 and tier 3 ground station sites to support launches and limited comm's. Some of these are crucial and allow a limited field of launch azimuths from KSC until the launch of larger communication relay birds. Sites were selected to coincide with the KerbinSide ground station locations that had their lat/lon listed in their config file (since I was lazy and unimaginative). I can post my config file if anyone is interested.

Anyways, sorry to turn this into an RT discussion instead of the pure awesomeness that is SD. I can't even imagine ever going back to stock after SD...

Edited April 18, 2016 by thunder175
Grammar

[Sigma88]

30 minutes ago, thunder175 said:

@Sigma88 Thanks for the great work on this. So if you have abandoned changes for RT, is it safe to use the newer dev versions again for those using root mode? In all honesty I feel fine with the way it is. I think the antenna ranges are still scaling properly without changing the RT settings config IMHO. The only real problem I am seeing is that antennas that may be on the edge for KEO in stock scaling won't rescale correctly and may not reach a larger stable KEO. But that is easily correctable with another part specific patch or just use a bigger dish. For example, the AIES CL-1 is perfect for low power KEO work. It defaults to 9Mm range. With my previously mentioned root and multiplier settings, that range gets halved, then multiplied by SD's setting of 6.4 for a max range of 28.8Mm, well within KEO for a 3.2x Kerbin. The DTS-1 using the same math is getting me out to 288Mm, good enough to close a link to Minmus.

Actually just had another thought. I may be feeling its fine since I am running 3.2x/6.4x. What is KEO for a straight up 6.4x system? 3.2x KEO is 17037km. I'm not doing anything really long range yet beyond Kerbin SOI, so again your mileage may vary.

I also tweaked the RT settings config file by adding ground stations. The biggest change here of note to users in this thread is dramatically increasing the range of the KSC dish. When using root mode it will close a link even beyond the max range of a given antenna. This is both good and bad IMHO. I also added a bunch of tier 2 and tier 3 ground station sites to support launches and limited comm's. Some of these are crucial and allow a limited field of launch azimuths from KSC until the launch of larger communication relay birds. Sites were selected to coincide with the KerbinSide ground station locations that had their lat/lon listed in their config file (since I was lazy and unimaginative). I can post my config file if anyone is interested.

Anyways, sorry to turn this into an RT discussion instead of the pure awesomeness that is SD. I can't even imagine ever going back to stock after SD...

yes, it should be safe for you to download it, make sure to back up your saves just in case (this is always good advice)

In relation to RT, I realized that there were to many issues in trying to rescale RT automatically, and even if I would have managed to do it, I'm sure there will always be someone that wants to rescale it in a slightly different way compared to what I do, and at that point I would need to add a setting for RT rescale. And it doesn't make sense to do all this mess just to achieve something that is offered from standard RT anyways (RangeMultiplier)

Keep in mind that if you have launched some antennas with the old SD (the versions that changed the antenna's range in the PART) those craft already in orbit which have an antenna may end up having way more range that they should.

other than that everything should be fine, if you are using the root mode remember to set  RangeMultiplier = 1.6 for a 3.2x system and RangeMultiplier = 3.2 for a 6.4x system

 

edit: to calculate the semimajoraxis for a Kerbin Syncronous Orbit you need to use this formula

KSO(Resized System) = KSO(Stock System) * (dayLengthMultiplier * Resize)^(2/3)

Edited April 18, 2016 by Sigma88

[thunder175]

1 hour ago, Sigma88 said:

Keep in mind that if you have launched some antennas with the old SD (the versions that changed the antenna's range in the PART) those craft already in orbit which have an antenna may end up having way more range that they should.

Ok I think I'm not fully understanding the changes from previous dev versions, sorry. The older dev version RT patch file is no longer included? Talking about the file that changes all antenna configs individually (assuming)? So in all newer dev versions the only way to change antenna range is via the RT settings multiplier? In other words, I install new dev version and leave RT alone, I'll have a much bigger scaled system with stock scaled antenna ranges?

I guess I'm just trying to figure out what is the appropriate range given a specific rescale without doing any antenna theory math. If for no other reason than for the record on the forums, here is a few scenarios with the AIES CL-1.

CL-1 Range, Stock scale system = 9Mm

(CL-1 Range (9Mm)) * RT multiplier (0.5))  = 4.5Mm

(CL-1 Range (9Mm)) * RT multiplier (0.5)) * SD Rescale (3.2x) = 14.4Mm

(CL-1 Range (9Mm)) * RT multiplier (0.5)) * SD Rescale (6.4x) = 28.8Mm <-- My current setup with older dev version of SD

(CL-1 Range (9Mm)) * RT multiplier (1.6))  = 14.4Mm

(CL-1 Range (9Mm)) * RT multiplier (3.2))  = 28.8Mm

(CL-1 Range (9Mm)) * RT multiplier (6.4))  = 57.6Mm

I hope I have that all correct since I'm doing this from memory while at work. Given the above, are you saying I am getting too much performance from my antenna right now when using the root model of RT? Again, my specific instance of KSP/SD is using a 3.2x/6.4x split.

 

EDIT: I just did some math in Excel using the above and RT's root formula. In my scenario, between two CL-1's the root model math is 858.24!! Is that right?? Clearly I'm doing this all wrong. This is all making me want to switch back to standard mode to be honest.

 

EDIT2: Fixed the problem with my math and am now getting reasonable link closure ranges in Excel.

Edited April 18, 2016 by thunder175

[Sigma88]

46 minutes ago, thunder175 said:

Ok I think I'm not fully understanding the changes from previous dev versions, sorry. The older dev version RT patch file is no longer included?

so, this is how it works now:

- Sigma Dimensions changes the celestial bodies but doesn't touch the antennas
- RemoteTech will rescale the range of your antennas using the number you set in the RangeMultiplier

on a stock system RemoteTech suggests these parameters:

Spoiler

RangeMultiplier = 1 (Normal Mode)
RangeMultiplier = 1 * 0.5 (Root Mode)

If you play on a 6.4x rescale you should set these parameters to:

RangeMultiplier = 1 * 6.4 (Normal Mode)
RangeMultiplier = 1 * 0.5 * 6.4 (Root Mode)

This may cause some problems with Kerbin Stationary Orbit ( because if you use Resize = 6.4 and dayLengthMultiplier = 4 the new KSO will not be 6.4 times the old one, but instead it will be 8.686 times the old KSO)

You can solve this problem by either using a bigger RangeMultiplier or a smaller dayLengthMultiplier

in particular, to have NEW KSO = 6.4x OLDKSO you can use   dayLengthMultiplier = SQRT(6.4)

 

So reassuming, the best choices for a 6.4x rescale are probably either:

A) RangeMultiplier = 6.4 (or 3.2 for root mode)   AND     dayLengthMultiplier = SQRT(6.4)

or

B) RangeMultiplier = (6.4 * 4)^(2/3)        AND        dayLengthMultiplier = 4

 

Problems with old saves:

Since the old versions of SD changed the range of the antennas directly (on the part) instead that using the RangeMultiplier (because it's not possible*)

You may have crafts in orbit with Antennas that have a modified range, those changes are sadly saved into the persistent and cannot be reverted using modulemanager (this is one of the reasons why I ultimately decided to remove them before releasing the feature)

the good news is, all the saved craft will have antennas with a bigger range, so you shouldn't lose connection anywhere

 

 

*actually it is kinda possible, but it wouldn't be very reliable with SD

[thunder175]

This is blowing my mind as far as which way to go and makes me wish I paid more attention in math class long ago. But let me try to run the numbers for a 3.2x resize, 6.4x rescale based on the math you provided.This may help someone else in the future.

For KSO: 3463.33*(4*3.2)^(2/3) = 18951.08 - (600km*3.2) = 17031.08km altitude for KSO at 3.2x resize. SOC is saying 17037.395, so its in the ballpark

For RT multiplier: (6.4*4)^(2/3) = 8.686 for standard model, / 2 = 4.343 for root model

Using RT multiplier at 4.343, a DP-10 will close links with a KR-7 at 31.3Mm since:

DP-10 range = 0.5Mm * 4.343 = 2.172Mm

KR-7 range = 90Mm * 4.343 = 390.87Mm.

Link closure = MIN(2.172,390.87)+SQRT(2.172*390.87) = 31.305Mm. Stock root model per RT table for DP-10 <--> KR-7 = 3600km

 

That look about right?

 

EDIT: Been thinking about this the past little while and I think I may "promote" my system to full 6.4x. Just seems the 3.2/6.4 split a la the 365 mod is causing more headaches on the math than its worth.

Edited April 18, 2016 by thunder175

[Sigma88]

2 hours ago, thunder175 said:

EDIT: Been thinking about this the past little while and I think I may "promote" my system to full 6.4x. Just seems the 3.2/6.4 split a la the 365 mod is causing more headaches on the math than its worth.

oh I didn't get that you were using Resize = 3.2 and Rescale = 6.4

If you didn't already abandon this, I would suggest you to just use a RangeMultiplier of 3.2 (with root mode) or 6.4 (without root node)

this will allow you to have fully functioning interplanetary antennas, and the shorter antennas will be probably be a bit overkill, but I don't think that the range limitations while inside Kerbin Sphere of Influence were never a big issue in RT. so it's not like you are losing the challenge of making it work with antennas that are not overkill

Edited April 18, 2016 by Sigma88

[davidy12]

@Sigma88: Just curious, does the dev version work with 1.1?

[Sigma88]

Just now, davidy12 said:

@Sigma88: Just curious, does the dev version work with 1.1?

I have no way to know

I need a working kopernicus release before I start checking my mod for bugs

[davidy12]

11 minutes ago, Sigma88 said:

I have no way to know

I need a working kopernicus release before I start checking my mod for bugs

Okay, I just checked it and NOPE. Doesn't work

[Sigma88]

Just now, davidy12 said:

Okay, I just checked it and NOPE. Doesn't work

well, you need a version of kopernicus that works in 1.1

[thunder175]

14 hours ago, Sigma88 said:

well, you need a version of kopernicus that works in 1.1

Did the formal release of 1.1 take anyone else by surprise? I stay away from the forums for a few hours and almost spit my drink out when check back and I saw the release notice. Immediately came here looking for a Kopernicus and SD update. I mean you had a few hours right?

So I played stock scaling with stock parts... and that lasted all of 30 minutes. I'm serious, the game is unplayable for me now without rescaling with SD. Yet another round of public kudos to @Sigma88 for his efforts.

[davidy12]

@Sigma88

She's up and running  

Edited April 20, 2016 by davidy12

[Sigma88]

11 minutes ago, davidy12 said:

@Sigma88

She's up and running  

I'll get some time in the weekend to check out SD, in the meantime you feel free to test the current development version with kopernicus 1.0

maybe it already works, who knows

[davidy12]

Bug already.

EDIT: Also, its black on the screen when I entered.

Edited April 20, 2016 by davidy12

[Sigma88]

16 minutes ago, davidy12 said:

Bug already.

EDIT: Also, its black on the screen when I entered.

I'll take a look

[thunder175]

I can confirm @davidy12 report. However, I did have success when I copied my entire Sigma Dimensions folder from my Linux 1.0.5 installation and ran it as is, no changes from 3.2x/6.4x. The catch is that I did copy the cache folder along with it. When I changed the settings to run 6.4x pure and the game generated new SD cache files, I got the black screen as described.

EDIT: Took a screen shot of 1.1 running SD at 3.2x/6.4, with EVE and SVE installed. 

Edited April 21, 2016 by thunder175