Sigma88

March 9, 2021

On 3/7/2021 at 7:11 PM, Gameslinx said:

This is not a Parallax bug, it's a bug with Sigma Dimensions:


Navigate to GameData/Sigma/Dimensions/Configs/ReDimension/resizePQSMods.cfg and delete the following line of text:
                  &minDetailDistance = 8
                  @minDetailDistance /= #$../SigmaDimensions/Resize$
-Save the .cfg and boot up KSP

the latest SD should have solved this

or at least I thought it did

February 16, 2021

On 2/14/2021 at 12:37 PM, New Horizons said:

Is this latest 10.8 compatible to KSP 1.10.1 and that correct Kopericus?

I didn't test but there were very little changes so it should probably work fine.

February 13, 2021

I had a break from ksp and played classic wow for a while.

I found the curseforge client to be very useful so I decided to upload my mods there.

the number of downloads is higher from there rather than github, which surprised me since I didn't expect it to be as popular

February 11, 2021

5 hours ago, Poodmund said:

GameData\Sigma\SigmaDimensions

Actually I changed the folder to be:

GameData\SigmaDimensions\

rather than the old:

GameData\Sigma\Dimensions\

this was done for 2 reasons:

1- making it easier to tell which of my mods is installed and making them more independent from each other

2- allowing the user to download and install the mod automatically with the CurseForge client

https://curseforge.overwolf.com/

so, @OrbitalManeuvers, the correct one is GameData/SigmaDimensions/

(basically just unzip the archive directly into GameData/ )

January 27, 2021

On 1/25/2021 at 11:49 AM, KerikBalm said:

Last time I checked (1.9, 1.10?) when I used sigma dimensions with the stock system at 3x, all the stock planets were fine, but my mod planet was not fine (terrain collision was all messed up)... yet the planet worked fine without sigma dimensions (used to work fine with both).

Reveal hidden contents

At 3x:

At 1x:

I just wanted to know if it was all sorted out before I try to pick up KSP again (haven't played in a while due to mod updating and real life stuff)

SD sorely needs an update for 1.11

sorry for taking so long but real life i getting in the way

I'll see if I can find some time. In the meantime, for the collisions bug there was a solution floating around somewhere, not really sure where though.

maybe in the github? I'll try to see if I can find it

EDIT: https://github.com/Sigma88/Sigma-Dimensions/issues/95#issuecomment-650375904

January 24, 2021

@linuxgurugamer @OhioBob @Kwebib

I think the issue about getting weird results from the calendar has been fixed now.

It was a combination of a Kronometer issue (fixed in the latest release v1.11.0-1) and Kopernicus (already fixed in the dev version, not sure when @R-T-B plans to release it)

January 20, 2021

@linuxgurugamer @OhioBob @Kwebib

Day 0 is not necessarily a bug, there are 2 different ways leap years are handled and one of the two uses a day zero while the other doesn't

depending on the kronometer settings it can be that you are using the first mode, or it could also be a bug, I would need more info about the system

to give you an idea of how it should work, these are the values of "year / day" you would expect from a system with a 10h year and a 3h day:

January 3, 2021

GN is very complicated mod which also should require a lot of work to be brought up to speed with latest kopernicus/ksp

I'm not sure it should be used right now, but I also can't really give you an ETA for a newer improved version tbh

December 16, 2020

On 12/15/2020 at 4:28 PM, Drew Kerman said:

@Arrowstar I can't use the included bodies.ini file because I have Kopernicus messing with Kerbin's atmosphere and spin rate. I tried to generate a new .ini but the texture feature was not included in the file. I placed the Kerbin texture lines in myself and that works but was not able to adjust the rotational offset. I tried using surfTextureZRotOffset but not sure if that's what that is for as it didn't seem to make any difference. I made sure to not only reload the .ini file after editing but also never saved my LVD file after load which means it would again convert it to the new .ini data. Here is the discrepancy:

LVD:

Where the trajectory is supposed to end, plugging the lat/lng into my online map

Ahhh, I was just about to post this and had another thought. Did some experimenting and yup, I see what's happening now. The surfTextureZRotOffset is working as intended, each time I edit it and load up LVD the default view of Kerbin changes as the texture is rotated. I didn't really pay attention before just loaded straight up into my case file. So okay the conversion is not using the currently-loaded .ini file it's converting based on the .ini data already in the case file. So then you're either a bit off on the offset calculation to account for a different body rotation speed or forgot to account for that altogether during the update.

@Arrowstar I noticed that you exported all your images with "oceanFloor = true", I would suggest you to try with "false" because I have the feeling it would give a better result for this specific use

October 31, 2020

I sent you a PR with the fix I had added in my version, not sure if it still works because I didn't test it in ksp

August 26, 2020

On 8/17/2020 at 1:59 AM, Akira_R said:

Any tips for getting this to play nicely with a 3.2x rescale? SigmaDimensions is supposed to have a system that will keep individual KK groups from getting all spread out but I think you have to manually set up the SD groups via configs, there is an OLD mod that Sigma wrote called KKtoSD that is supposed to automatically make SD groups from the KK groups but it doesn't seem to be working in my install.

KKtoSD is not needed anymore. KK now automatically keeps all buildings tied together when rescaling.

the only thing you need is to use the feature built into SD to tweak how the group are positioned in the final result

there's a description of how to use the feature into the README file of SD, just search for PQSCity_Groups

July 28, 2020

does mechjeb reads the day length from the rotation speed of the planet or from the ksp definition of 1 day (either 6hr or 24hr depending of user settings)?

July 26, 2020

22 hours ago, Aremos said:

Can some kind person help me get this right.

if you look at the RESCALE! mod from galileo it should have a pre-tested cfg for 10.625 (https://github.com/Galileo88/Rescale/tree/master/RESCALE_10625)

If I were you I would stick to that and it should provide you with what you are looking for.

if you want to set up your customized rescale you can find all the info in the README and if you still have any specific questions feel free to ping me here

some things you should be aware:

@OhioBob has done a lot of work on atmospheres, iirc his suggestion was to use something like

Atmosphere = 1.025

atmoTopLayer = 1.4

(this is from memory so might be completely wrong)

landscape should probably be lowered to something like ~0.5

the most realisting option should be around 0.10/0.15 but gameplay-wise 0.5 looks much nicer

July 21, 2020

9 hours ago, R-T-B said:

I finally just removed that whole override in the latest attempt and made a local "GetLocalStar()" function. I believe that override was unintended or not needed at any rate, as it overrides the standard GetBodyReferencing and isn't used like, anywhere else.

FWIW the rest of your code appears pretty darn solid for multistar, which is great.

my only doubt with that solution is that while the override returns a planet the "GetLocalStar" returns a star

however, if the use cases are working properly, then I would assume it's fine

July 20, 2020

On 7/18/2020 at 9:32 AM, Dux Aquila said:

Would any KKtoSD configuration work? Anybody got one?

KKtoSD is no longer required since KK handles groups natively now

July 20, 2020

10 hours ago, OHara said:

I added https://github.com/prestja/Kopernicus/issues/19
but have not set up to compile and test C#, so hope @Sigma88 might still be in position to confirm if this was his original intent, and motivated to make a pull request.

I can't remember for sure, but if my code worked fine and the new code doesn't it could be an indication to that effect.

However if my code was changed it could be because there was an issue with it, so whoever changed it should look how to make the new code work in your use case

Multiple star is always a headache and changing stuff while not testing with multiple stars will usually lead to this kind of issues

July 14, 2020

15 hours ago, OhioBob said:

The topographic range of the Earth, Moon and Mars are about 19.8 km, 20 km, and 29.4 km respectively. For comparison, stock Kerbin, Mun and Duna have topographic ranges of 8162 m, 7313 m, and 8145 m respectively. So if we wanted these stock bodies to have deformities comparable to their real-life analogs when scaled up to 10.618x, then we would have to give them landscape multipliers of about 0.23, 0.26 and 0.34. Or an average of about 0.275.

the problem with that is earth is much less flat below the sea level, if you only consider above sea level both earth and kerbin go from 0 to about 8 km

July 13, 2020

6 hours ago, etmoonshade said:

My question was more about understanding that the effects of that height scaling parameter in the configs worked the way I thought they did. It's not exactly easy to balance between "too flat" and "too tall" since most people probably have different opinions on what those mean.

Resize is a multiplier on the distance between surface and center of the planet

landscape is a multiplier on the distance between surface and sea level

so if you have landscape = 1 / Resize they would cancel each other out, and the altitude of the mountains measured from sea level would be the same in the original planet and the rescaled planet.

hope this makes sense

July 13, 2020

4 hours ago, Profiremu23 said:

My main goal is to make custom configs for EVERY planet pack in my mod, because the Gallieo88 version only the GPP pack had custom configs, and i will try to add custom configs like JNSQ

if you run into some trouble feel free to ping me

July 12, 2020

7 hours ago, Profiremu23 said:

Special Thanks for:

Profiremu23 for making and testing the mod.

July 3, 2020

50 minutes ago, Galileo said:

Oh, don’t give me that! You know where you stand with me!

just kidding

July 3, 2020

On 7/2/2020 at 7:16 PM, Galileo said:

I don’t have the relationship I had with Thomas and Sigma with the devs of Kopernicus Continued

"had"

ugh

July 2, 2020

in may 2016 the forum purged thomas for some reason, nothing relevant now :sticktongue:

June 24, 2020

5 hours ago, OhioBob said:

I know there were definitely issues with multiple stars and solar panels not working correctly in the dev version of Kopernicus. @Sigma88 was working on a fix that seemed to correct the problem, but it sounded like he wasn't completely satisfied with the solution. (I was doing testing for him at the time.) It's likely his changes are not included in this fork. I don't recall now exactly what the issues were, but I do remember that panels sometimes did not receive the amount of illumination they should have from a particular star, or tracked the wrong star.

You might want to try talking to Sigma88 about it before merging the fix.

I am happy with the state of the PanelsFix2 (or whatever it's called) branch as of now. I never merged it because some people pointed out stuff that could be changed/improved but I had no time nor patience to go back into the code to implement those.

As for the atmosphere issue you mentioned, I'm not sure if it had anything to do with the solar panels, honestly it shouldn't.

@prestja if you want to merge that branch I would suggest you to do it on a separate branch of your kopernicus and find someone that is willing to test the issue @OhioBob mentioned.

if that issue is not present (how I would expect) you should be able to implement everything into a new release. otherwise give me a shout and I'll try looking what might be going wrong there

June 19, 2020

12 hours ago, Motokid600 said:

So ive since decided against rescaling Rhode alone. Im going to go for the 2.5x. How is this done exactly? I see the settings in the.. settings file for Sigma. Is it just the rescale value I set to 2.5 and... that's it?

Also. I asked in my previous post about using SD for rescale vs just editing the raw config file. You advised against it. I want to change the gravity of Rhode to 1. That's it beyond the overall rescale that ill use SD to do. Do I have to create my own config file for that or can I just edit Rhodes?

SD contains a readme file that explains fairly well all the settings and what they do.

for a normal rescale 2.5x you would usually need to change:

Resize = 2.5 (this will change the size of the planets)
Rescale = 2.5 (this will change the size of the orbits)
Atmosphere = whatever (this will change the scale of the atmosphere, I don't know what's best for 2.5x, I guess it depends on your taste)
dayLengthMultiplier = you usually want this to be the square root of the Rescale (so in this case ~1.58)

SD can also change the gravity, when rescaling SD will keep constant the gravity at surface level of the planet.

if you want to change only rhode you might as well just go into its cfg and change the geeASL to 1 (assuming rhode has that value, otherwise just add it in there)

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by Sigma88

Special Thanks for: