Jump to content

OhioBob

Members
 View Profile  See their activity

  • Posts

    3,934

  • Joined

  • Last visited

 Content Type 

Everything posted by OhioBob

  1. OhioBob
    I don't know too much about it, but I know we're having problems getting all the building to resize correctly and remained grouped together. @Galileo is currently on hiatus, but @Poodmund is working on the problem. He could probably use your help.
  2. OhioBob
    I know what you mean. I only had 8 GB until I finally upgraded to 32 GB in February (I also upgraded my graphics card). Before upgrading I couldn't use the visual enhancement mods because my computer just couldn't handle it. Now, want a difference! I can finally experience GPP as it was meant to be.
  3. OhioBob
    Gael is the only planet where I remember naming geological features (other than those identified by biomes). We named the three continents and a couple of the tallest mountain peaks. We've started a GPP Wiki, but it's incomplete and some of what we've done is already out of date because we keep tweaking things. The Gael article includes the named features. http://outer-planets.wikia.com/wiki/Category:Galilean
  4. OhioBob
    We've actually given it a name, Mount Cilos.
  5. OhioBob
    We could tweak Gael's semimajor axis to make the years come out to an exact number of days, if that helps anything.
  6. OhioBob
    Glad I could help.
  7. OhioBob
    I've considered that possibility but still haven't made up my mind. I have a certain vision of what I want to do with this planet pack (which I'm not ready to disclose) that just gets messed up if it were released as a stand-alone solar system. If I were to work on a planet pack with the intention of releasing it as stand-alone solar system, I have other ideas that I'd like to explore. I'd rather save my Grannus ideas until which time the bug gets fixed.
  8. OhioBob
    Sadly I agree. I already started doing some preliminary work on a Grannus planet pack. My vision for the system was based entirely on the fact that Grannus is a low luminosity red dwarf. But if I can't create the planets I want and put them in the orbits that I want to because the solar irradiance is too high, then I don't see much point in continuing. I'm not going to compromise my vision and settle for something I don't want because of a bug. I'd rather just shelve the project until somebody figures out a way to fix the problem (though at this point I don't have a lot of confidence it will get fixed).
  9. OhioBob
    Maybe this article will help you... http://www.klabs.org/history/papers/lunney_gemini_rendezvous.pdf
  10. OhioBob
    I started writing something at one time, got distracted, moved on to other things, and never went back to it. It's still on my todo list, but new things keep getting added that slot in ahead of it.
  11. OhioBob
    Thanks for the feedback. Weird that you're getting the red light of Grannus. I don't know if the problem is with KSP, Kopernicus, or Kerbalism, but clearly something doesn't like the existence of multiple stars. I'm glad the Kerbalism solar panels are now working correctly. I'm pretty sure the stock solar panels will work as well, providing the correct power output while in the vicinity of Ciro. Near Grannus, however, things are messed up. In order to make things right at Ciro, we've had to give Grannus the same luminosity as Ciro. So while Grannus may have the size, mass, and color of a red dwarf, it's pumping out the energy of a G-type star. Unless somebody can find a way to fix the problem, we're just going to have to live with that. The next GPP release is changing Grannus luminosity to 1360. It will probably stay that way until such time that another solution is found.
  12. OhioBob
    Squad already assigned an albedo to each body, so I just used their numbers. However, the numbers they used look to be based on real-life counterparts.
  13. OhioBob
    I first computed the apparent brightness of each body. This was done by taking the luminosity of the sun, expanding its light out into space, and computing how much energy touched the disc of the planet. I then multiplied that amount by the planet's albedo to determine the amount reflected. I then let the reflected light expand out into space and determined how much energy per square meter was received back at Kerbin. I then compared this apparent brightness to the apparent brightness of real life celestial bodies for which I knew their real life magnitudes. Knowing the relative brightness of two bodies and the magnitude of one body, the magnitude of the other can be computed from the equation, m2 - m1 = 2.5 * log10 (b1 / b2) For example, suppose I determine that body #1 is half as bright as Jupiter when Jupiter's magnitude is -2.6. We have, -2.6 - m1 = 2.5 * log10 (0.5 / 1) m1 = -1.85
  14. OhioBob
    The solar panel bug occurs when there are multiple stars of different luminosities. Each solar panel has a chargeRate specified in its config. For instance, the chargeRate of a 3x2 panel is 1.64. From all the experiments I've run, I've determined that this is the charge rate that we get at the home world. The luminosity and sunAU specified in the star config are irrelevant. At the distance of the home world we get the charge rate specified in the solar panel config. (Remember that the units of electrical charge in KSP are unspecified, so they could be anything.) As we move closer to or farther away from the star, the charge rate changes according to the inverse-square-law. When a second star is added you would think that the charge rate at the home world would stay the same, and the charge rate at the second star would increase or decrease based on the ratio of the luminosities of the stars. But with Ciro and Grannus, that's not happening. Even though the home world orbits Ciro, we're obtaining the specified charge rate while in orbit around Grannus, not Ciro. And instead of getting a reduced charge rate around Grannus, the charge rate around Ciro is increased by the ratio of the luminosities. For example, the luminosities of Ciro and Grannus are 1360 an 42 respectively, and the distance of the home world (Gael) from Ciro is roughly 14 Gm. (Although we have sunAU = Gael's SMA, this makes no difference; what matters is the home world's SMA, not sunAU.) So if we put a 3x2 solar panel in orbit around Grannus at a distance of 14 Gm, we get a charge rate of 1.64 as specified in the config (though in practice this number fluctuates for reasons I don't fully understand). If we put the same solar panel in orbit around Ciro at 14 Gm we get a charge rate of, 1.64*1360/42 = 53. Changing the luminosities makes no difference, the result is always the same (the actual value of the luminosity is irrelevant, all that matters is the ratio). Everything I've just described happens in stock. I have not run any tests with Kerbalism installed, so I don't know what happens in that instance. @MaxL_1023 can probably help with that. I think you are probably getting the correct solar panel output around Ciro because the solar flux is only 42 rather than 1360 as it should be. You have two wrongs cancelling each other out to give a correct answer.
  15. OhioBob
    That's probably what we'll end up doing in the next update if a more satisfactory fix is not found. It's by no means ideal, but I think it will fix all the problems we're having in and around Ciro's neighborhood. Once you make the change, please let me know how it works out.
  16. OhioBob
    Without Kerbalism installed, at a distance of 1 AU I'm getting 1360 around Ciro and 42 around Grannus, and that's regardless of what scale I'm playing at. If the AU wasn't being rescaled, then going from 1x to 10.6257x should reduce the flux to, 1360 / 10.6257^2 = 12, not 42. The only way I can see you getting 42 is if it's somehow pulling that number from Grannus.cfg. My guess is that Kopernicus is making Grannus the 'active star' (as ShotgunNinja called it). This might explain why Kerbalism is using Grannus' luminoisity. It might also explain why solar panels are producing their specified chargeRate at 1 AU from Grannus rather than 1 AU from Ciro. @Thomas P., @Sigma88, @ShotgunNinja, any idea what we need to do to fix this?
  17. OhioBob
    Yes, if you have Scatterer installed, I think you need to change the size of the sunflare in the scatterer config. Unfortunately I don't know anything about that; that's Galileo's domain. Changing sunAU or brightestCurve in Grannus.cfg will change the stock sunflare, but the stock sunflare is disabled when scatterer is installed.
  18. OhioBob
    I don't know anything about Kerbalism, so I don't know what it's doing. What does the Thermal GUI (debug menu) read? Can you hyperedit your greenhouse to orbit around Grannus and check the numbers? Also try changing Grannus' luminosity to 1360 and see what happens.
  19. OhioBob
    I've tried to reproduce your problem and I'm not seeing it. According to the Thermal GUI in the debug menu, I'm getting a solar flux of 1360 W/m2 at 1 AU from Ciro, and 42 W/m2 at 1 AU from Grannus. That it what it should be. The solar panel power output it still bugged, but I'm reading the correct fluxes.
  20. OhioBob
    That's messed up. 42 W/m2 is what you should get at 1 AU from Grannus. There is definitely something bugged, though I don't there's anything inherently wrong with GPP. KSP just doesn't like it when there are multiple stars with different luminosities. The specific problem that you describe here is one I haven't seen before, but it sounds like it's related to the same root problem (I haven't done any testing on resized games). Perhaps @Thomas P. can take a look at Kopernicus to see if it could be the cause of the reported issue (or rule it out). We've reduced the landscape factor for Gael and a couple other bodies to reduce the heights of the mountains. They shouldn't be so extreme in the next version of GPP.
  21. OhioBob
    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.
  22. OhioBob
    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.
  23. OhioBob
    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.
  24. OhioBob
    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.
  25. OhioBob
    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.
×
×
  • Create New...