• Content count

  • Joined

  • Last visited

Community Reputation

2,117 Excellent

About OhioBob

  • Rank
    Junior Rocket Scientist

Contact Methods

  • Website URL http://www.braeunig.us/space/

Recent Profile Visitors

11,178 profile views
  1. OhioBob

    [1.4.x, 1.3.x] Realistic Atmospheres

    That's interesting; I don't know how it got there. Since I'm not responsible for it being on CKAN, I can't vouch for whether or not it's up to date. I don't recommend installing it through CKAN.
  2. OhioBob

    Sigma Binary

    Try it and see. The lasted release of Sigma Binary on GitHub (v1.7.0) is dated May 3. The last KSP release was in late April. So I assume Sigma Binary has been updated.
  3. There's a celestial coordinate system used to measure the orbital elements. Zero longitude points in the direction of a point in space that is fixed relative to the stars. In real life, zero longitude is along the line formed by the intersection of Earth's equatorial plane and the ecliptic plane, pointing in the direction of the vernal equinox. In KSP it is not entirely clear what defines the direction of zero longitude. One thing I've noticed, and this is totally unofficial, is that when you look at the "milkyway" that crosses the sky, there appears to be a bright middle to it. Zero longitude seems to point in the direction opposite this brightest part of the milkyway. At least that's what I recall.
  4. OhioBob

    [1.4.3] Kopernicus (Release 2) - May 6

    @Tonas1997, here's a post I made last year describing a method that I like to use for making sunlight intensity curves. Maybe it will give you some ideas.
  5. OhioBob

    [1.4.3] Kopernicus (Release 2) - May 6

    If you enter slopes of 0 you'll get a curve with flat spots on it. It will looks something like this: You'd probably be better off using no slope. In that case, unity will compute a slope using a default formula. I believe it makes the slope at any given point equal to the slope between the two points straddling it. And for the end points it uses the slope between the end point and the point next to it. If you want the lighting to fade linearly, then you can simply do something like this, which is a straight line between the beginning and ending points: IntensityCurve { key = 0 1 0 -5E-13 key = 2E+12 0 -5E-13 0 } Or, in this case, you should get the same thing using no slope, IntensityCurve { key = 0 1 key = 2E+12 0 } By the way, I don't know what happens when we use a brightness greater than 1. I've never done that. Inside a certain distance from a star, I typically just set the value equal to 1. Regarding the second part of your question, IntensityCurve is the lighting that we see when we are in flight mode and close to the planet. For example, when we are in low orbit around it or landed on its surface. ScaledIntensityCurve is the lighting that we see when we are seeing the "scaled space version" of the planet. This occurs when we are far from the planet, in map mode, or in the tracking station.
  6. Integrating GEP into GPP as a single installation adds bodies that some people may not want. It could be too much for some people's computers to handle. We prefer to keep the mods separate. If somebody wants the additional planets around Grannus, then it is a very simple process to go download and install GEP separately. GPP and GEP are for the most part finished products; we're not making any more changes.
  7. OhioBob

    [1.4.3] Kopernicus (Release 2) - May 6

    Are you using Sigma Dimensions to scale RSS down to stock-scale? I see that the curves you're using are already scaled down to 1/10th scale. I don't think you want to do that. Since you are editing RSS's configs, and since RSS is a real scale system, you want to use curves that have real scale distances. Sigma Dimensions should then scale down the intensity curves along with everything else. I believe you are effectively doubling up on the 0.1 multiplier. Based on your curve, I think the light intensity at Earth is about 0.2 rather than 0.65 as apparently intended. Try multiplying all the distances in your curves by 10 and see if that fixes it. Also note that the distances in your IVAIntensityCurve are wrong. IntensityCurve and IVAIntensityCurve use the same units (meters). It is only ScaledIntensityCurve that should be different (meters/6000).
  8. The single setting is still an option in Kopernicus, but in that case a star's brightness doesn't diminish with distance. In other words, a star's light has infinite range. With multiple stars that's a problem because objects near Ciro would also be brightly illuminated by faraway Grannus, and vice versa. GPP uses brightness curves so that the sunlight decreases with increasing distance from each star. You've got two options depending on what you want. First, edit the curves in the file GPP/GPP_Configs/SunCurve.cfg. These are the curves that produce the light intensity decrease as we move away from a star. The second number in each "key" is the brightness. Just increase the numbers to make the sunlight appear brighter. If you prefer to have all the planets equally illuminated with no decrease vs. distance, then use the second option. Just delete the file SunCurve.cfg. This will cause the sunlight intensity to revert the curves in the individual star configs - Ciro.cfg and Grannus.cfg. These curves produce even illumination across all the planets, but it then decreases to zero before reaching the neighboring star. In this case the curves are simpler with fewer numbers to change.
  9. OhioBob

    [1.4.x, 1.3.x] Realistic Atmospheres

    Realistic Atmospheres is not on ckan. (If you're seeing it on ckan, then I have no idea how it got there. It's nothing that I'm responsible for.) Download and install it manually.
  10. OhioBob

    [1.4.3] Kopernicus (Release 2) - May 6

    Orbital period/speed is a function of the gravitational parameter of the primary body and the distance from it. Changing either of those parameters will change the orbital period, but otherwise it can't be changed. It is a hardcoded calculation that you can't override. The only other thing you can do is change the way that orbital period is calculated. Normally KSP uses a simplified calculation that takes into account only the mass of the primary body. But by using the setting finalizeOrbit = True, KSP will take into account the mass of both bodies in the calculation. It most cases it's only a very small difference, but if two bodies are close to the same mass, like binary stars, it can make a pretty significant difference in the orbital period. Better question, why would you want to? You could try giving a body a negative surface gravity, negative mass, or negative gravitational parameter (use only one), but I have no idea if that would work, or what the consequences would be. It might simply blow the game up. Just try it and see what happens.
  11. GEP is designed to play nicely with OPM. With GEP, OPM and CustomBarnKit all installed, you'll get the same Level 4 Tracking Station that OPM uses. That by itself won't be enough to reach Grannus, however. If you want communications to reach all the way to Grannus, you'll also need an larger antenna. GEP comes with its own antenna, which you get when installing the optional mod GEP_CommNet. The antenna is an upscaled version of the Communotron 88-88 with a new texture, but you don't get it until very late in the tech tree. GEP_CommNet comes in the GEP download, but you have to install it separately. You can also use the JX2 antenna if your prefer it. GEP_CommNet also installs the Level 4 Tracking Station if GEP is used without OPM.
  12. The appearance of Lili changed in one of the recent updates, but none of its physical or orbital properties. So everything you said is still true.
  13. Sounds like you're just talking about visual effects. I assume you're OK as far as aerodynamic effects are concerned? I'm a lot more familiar with how to make aerodynamic adjustments, but I'm guessing that you can probably change the visible height of the atmosphere using the atmosVisualEffect parameter. Open the file 6.4xKSP.cfg and you will see the following: @SigmaDimensions { // Base Settings @Resize = 6.4 @Rescale = 6.4 @Atmosphere = 1.2 @dayLengthMultiplier = 1.75 // Advanced Settings @landscape = 0.57 @geeASLmultiplier = 1 @resizeScatter = 1 @resizeBuildings = 0 @CustomSoISize = 0 @CustomRingSize = 0 @atmoASL = 1 @tempASL = 1 @atmoTopLayer = 1.333333333 @atmoVisualEffect = 1.2 @scanAltitude = 1 } Near the bottom you see @atmoVisualEffect = 1.2. Try changing the setting to see if you can find something more to your liking.
  14. OhioBob

    How to get into eve

    It's possible, but it's one of the biggest challenges there is in KSP. The selection of engines is really important because, at Eve's high atmospheric pressure, there are only a few that can produce adequate thrust. The Aerospike and Vector are best. It also takes a lot of delta-v, though I don't remember what the generally accepted value is. Streamlining is also really important because of the dense air. One of the biggest hurdles, as I recall, is designing something that can be aerodynamically stable during entry and landing, and then can also be aerodynamically stable during liftoff. I've landed on and taken off from Eve once, but that was way back in KSP 0.90. It has changed much since then. The problem back then was the extremely high drag and designing a vessel with enough delta-v. I think the delta-v requirement is now much less, but aerodynamic heating and stability are now much bigger issues.
  15. OhioBob

    [1.3.1][Plugin] Kronometer v1.3.1-1

    I've seen several mods that are not "kronometerized". Those mods are likely hardcoded to a 6 (or 24) hour day. From what I've been told, there are internal variables that define the length of day and year, and unless a mod references those variables, it's not going to work correctly with Kronometer. It's my understanding that it's the other mods that must change to make it work. Until that happens (if it ever does), you'll just have to deal with the inconvenience.