OhioBob

Members
  • Content count

    1365
  • Joined

  • Last visited

Community Reputation

1303 Excellent

3 Followers

About OhioBob

  • Rank
    Junior Rocket Scientist

Contact Methods

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

Recent Profile Visitors

5295 profile views
  1. Hi Bob. I was told that you wrote http://www.braeunig.us/space/orbmech.htm. Thanks a lot - it's really useful, but I am a bit stuck on the math in the article. I've posted my questions on reddit. I would appreciate if you helped me to understand your article better and perhaps you could also improve it to make it more easy to understand for dummies like me :-).

     

  2. The atmosphere factor uses a similar formula, where Atmosphere = Resize^(Log10(1.25)), or Resize^0.0969. The product Atmosphere * atmoTopLayer also uses a similar formula, though the end result is rounded off. Atmosphere*atmoTopLayer ≈ Resize^(Log10(1.8)), or Resize^0.255. From the above we get, atmoTopLayer = Atmosphere*atmoTopLayer / Atmosphere. I've found that this type of function gives a better result than scaling linearly by the resize factor.
  3. Low as in the speeds are too low and you want to time warp faster, or low as in the altitudes at which the limits change are set too low? If the former, what version of Sigma Dimensions are you using? Sigma Dimensions 0.7.5 changed the way it does time warp limits. It now changes time warp limits by the resize factor when resize < 1, but it doesn't change them at all when resize >= 1. (It previously changed time warp limits by the atmosphere factors for bodies with atmospheres, and by the resize factor for bodies without atmospheres.) In other words, at 6.4x the time warp limits are the same as they are at 1x. That should be plenty fast enough for you. If you mean the later, I can probably help you write a ModuleManager config that raises the altitudes, but I need to know more specifically the problem you're trying to address before I can recommend anything.
  4. Something else that might be happening with the Transfer Window Planner it that it could be computing a type 2 trajectory. A type 1 trajectory is one in which the angle the spacecraft sweeps out between the departure point and the intercept point is less than 180 degrees. A type 2 trajectory is one where the angle is greater than 180 degrees. In a type 2 the spacecraft travels out to an apoapsis beyond the target, and then intercepts the target on the way back in. Type 2 trajectories are common for trips to Mars because they often result in better intercept conditions and reduce the amount of delta-v required for orbit insertion. Whether a type 1 or a type 2 is better really depends on where the target is in its orbit at the time of launch. Although a type 2 may require less delta-v, the travel time for a type 2 will be significantly longer. If you are simply selecting the transfer that has the lowest delta-v, then you may be unwittingly selecting a type 2 transfer. At a distance out beyond Grannus, a spacecraft is traveling very slowly. I can see how using a type 2 trajectory could add a hundred years to the travel time. The Transfer Window Planner might be computing other transfers that have shorter travel times but higher delta-v. You might just have to poke around on the porkchop plot until you find something that provides both acceptable delta-v and acceptable travel time. You'll probably have to compromise by sacrificing a little bit of the one for the other.
  5. I think there might be something messed up in the Transfer Window Planner's flight times. Without getting real complicated, I just figured an orbit with a periapsis at Gael and an apoapsis at Grannus and computed the flight time. I get about 150 years to go from periapsis to apoapsis. I think that should be about the worst case.
  6. We're never going to be able to make the SOIs work in a realistic way. The formula KSP uses to compute SOI is just a mathematical approximation. There are several things wrong with it. We can get a better approximation of a body's real SOI by computing the location of the equigravisphere. The equigravisphere is the spherical surface on which the gravitational attraction of both bodies is equal. Below is an illustration showing both Grannus' equigravisphere and its SOI as computed using the formula in KSP: One of the first things you notice is that the equigravisphere is not centered on Grannus. The computed SOI, on the other hand, is centered on Grannus. Even though the computed SOI is smaller, by centering it on Grannus you can see that it extends much closer to Ciro, causing Grannus to dominate most of the space between the stars. When the bodies are this close to each other in mass, the computed SOI just doesn't work. Another problem is that the SOI is computed using the semimajor axis of the secondary. The radius of the SOI should be a dynamic thing that changes with the actual distance between the bodies. If we compute Grannus' SOI based on its semimajor axis, then the computed radius is way too big for when Grannus is at periapsis, causing the SOI to engulf Ciro. Fortunately KSP allows the developer to override the calculation and enter an actual value for the SOI. But this still centers the SOI on the body. There is no way to simulate an equigravisphere the way it is in real life. This seems to me to be the most logical way of doing it. FYI, on a straight line between the stars, the distance of the equipotential surface from Ciro is 0.58579 times distance between the stars.
  7. But you added some further good points. I agree with you that there is really no difference in terms of game play between having them binary or not.
  8. Personally, I see no added value in making Ciro and Grannus into a binary system. Grannus' orbital period is over 1700 years. What exactly does anyone expect to see? For all practical purposes the movements are imperceptible. If somebody wants to create their own system, or move planets around, then feel free to do so. But GPP is a finished product.
  9. Grannus and its orbit currently have the following characteristics: Mass = 0.5 x Ciro Eccentricity = 0.4 Semimajor axis = 2,000 Gm Periapsis = 1,200 Gm Apoapsis = 2,800 Gm Sphere of influence = 500 Gm Ciro's farthest planet is Leto, with Pe = 488 Gm and Ap = 597 Gm. Leto's closest approach to Grannus is about 706 Gm.
  10. We didn't make one for SSRSS, but if one exists for RSS, it can be used. Just multiple the numbers in the RSS map by about 0.31. That should get you close.
  11. I'm happy to help if I can, but I don't know what's being asked. Can you be more specific about what you're looking for?
  12. I wouldn't recommend changing the AU value without fully testing it out to see if it affects anything else. It could change the solar flux, which could affect heating rates. I haven't run enough tests to know one way or the other, but I'd be leery of changing anything without knowing the full consequences. I think the better way of changing the sun flare size is by changing the brightness curve.
  13. All that can be done to make it look brighter is to make the sun flare bigger. But Galileo thought the stock sun flare was too big and looked somewhat cartoonish, so we reduced it. It's at its current size because that's the size Galileo wanted it to be. It would be nice if we could make it brighter without making it bigger, but I don't know of any way to do that.
  14. @Danilka, the apparent size of a star at a distance is control by brightnessCurve in its configuration file. We rewrote brightnessCurve for both Ciro and Grannus to make them appear smaller when viewed from great distance (that's what Galileo wanted). If you want to undo that, you'll have to edit the configs. You can always try using the stock brightnessCurve shown below. If you don't like how that looks, then the only other option it to try writing your own brightnessCurve to get it looking the way you want it. brightnessCurve { key = -0.01573471 0.217353 1.706627 1.706627 key = 5.084181 3.997075 -0.001802375 -0.001802375 key = 38.56295 1.82142 0.0001713 0.0001713 }
  15. We just didn't set up the configs to generate trojan asteroids. I did not take part in writing the asteroid configs, but now that I look at how the orbits of the asteroids are defined, I think it might be possible to produce a random group of trojan asteroids. I'll check with the rest of the team to see if that's something we might consider adding. That's a good point. I didn't think of that.