Jump to content

OhioBob

Members
  • Posts

    3,934
  • Joined

  • Last visited

Everything posted by OhioBob

  1. Gravitational parameter and sphere-of-influence are computed from the data in the configs. If you use the following formula you'll be balls on accurate, because it's the same thing the game is doing. gravParameter = 9.80665 * geeASL * radius ^ 2 sphereOfInfluence = semiMajorAxis * ( gravParameter_secondary / gravParameter_primary ) ^ 0.4
  2. That's the orbital period, not the rotation period. The units are seconds. And, yes, the sidereal rotation period of Eve is 80500 s.
  3. That's odd. In real life the Moon's inclination relative to Earth's equator varies between 18.4 and 28.6 degrees, depending on where it is in its 18.6-year nodal precession cycle. If it's 33.3 degrees in RSS, then somebody messed something up when they set up the Moon's orbital elements.
  4. I've only taken off from Eve a couple times, and it was using the stock engines. I've never actually used Eve Optimized Engines other than in testing. I just think it's kind of weird that Squad gave us Eve but never gave us any proper engines for getting off of it.
  5. Other than the Dart, none of the stock engines are properly designed for Eve. That's one of the things that makes Eve so difficult... you're forced to use the wrong tools for the job. Some of the stock engines allow you to improvise, but it kind of like driving in a nail with a wrench rather than a hammer. If you want to use a hammer, you might consider this: Some people probably consider it cheating, but I just consider it engineering the correct tool for the job. It's simply making a trade off to get a better performance where you need, by sacrificing performance where you don't.
  6. That's one of the things I like about MissingHistory, it adds @Porkjet's LV-T15 engine (105 kN max thrust).
  7. Drag use to be a much bigger issue in early versions of the game, pre-1.0. At that time the game used a placeholder drag model that produced insanely high amounts of drag. That's where the 4700 m/s to orbit came from. But with the introduction of the current aerodynamics in v1.0, things are much more lifelike now. (The aero settings have gone through some tweaks since v1.0, but the basic model hasn't changed.) Generally speaking, gravity losses are about ten times greater than drag losses. Other than using common sense and making my rockets reasonably streamline, I don't even worry about drag. It's just not that big of an issue, at least not on Kerbin. Eve might be another story. Don't worry about it. Lord knows we've all made our share of mistakes while going through the learning curve.
  8. The Reliant and Swivel are similar engines with similar Isp, so the sequence in which you fire the engines shouldn't make much difference in the calculated delta-v. What will change by firing only the Reliants first is the thrust-to-weight ratio. You'll have less thrust off the launch pad, so you'll be accelerating more slowly. This will decrease drag losses but increase gravity losses. These effects are not seen in the delta-v calculation. In fact, computed delta-v doesn't care at all about TWR. The computed delta-v is just theoretical. You can have a rocket with 3000 m/s delta-v, but if the TWR is <1, it's not going to go anywhere. So there's more to designing a good launch vehicle than just delta-v. What engine fire sequence works best should probably be determined by what keeps your rocket within a controllable range of TWR. If you are firing 2 Reliant + 1 Swivel, I compute a TWR of 2.07 at launch and 3.45 at burnout. By firing just the Reliants, I compute a TWR of 1.47 at launch and 2.38 at burnout. Either of those will probably work, but the lower range is closer to what I typically do. I find the higher TWR more difficult to control, so I find it harder to get the turn right. But that's just me. What works best for you should be determined through practice. (EDIT) Which method you use, low or high TWR, can also have an effect on launch cost. But that's an entirely different conversation. We can discuss it if you'd like, but I don't want to sidetrack the thread.
  9. First off, I usually do all the calculations using vacuum Isp. It over estimates the delta-v a little, but you generally climb out of the thick atmosphere so quickly that you're burning at much closer to the vacuum value for most of the ascent than you are to the sea level value. I believe that "vacuum delta-v" is what most people use when talking about delta-v to orbit. I know that the "3400 m/s to orbit" figure that is commonly quoted is based on vacuum values. Computing the combined Isp of 1 Swivel + 2 Reliant using the vacuum values, I get 313 s. So computing the first stage delta-v using your mass numbers and vacuum Isp, I get the following: Delta-V_1 = 313 * 9.81 * LN(28556 / 20556) = 1009 Delta-V_3 = 320 * 9.81 * LN(16646 / 8646) = 2056 Delta-V_total = 3065 m/s Delta-v is velocity measured in m/s. m/s2 is the unit of measure for acceleration. I have no idea where you got that number. The Swivel has sea level and vacuum Isp of 250 and 320, so it couldn't possibly be 167.9s. 276.6 m/s sounds way too low. Are you computing that using sea level Isp? You don't give starting and ending mass figures for the second stage, but I can make some educated guesses. I'm estimating that your second stage should have >1300 m/s delta-v. I don't know from where you got that number, but it sounds too high to me. To reach a minimum orbit around Kerbin, I generally assume about 3400 m/s. That's for a minimum orbit; getting to 200 km should add another 200 m/s. That get's us up to about 3600 m/s. It could be more than that if your rocket is really draggy, or if you fly it inefficiently. If your first stage has 3065 m/s, and if you used 40% of the second stage's fuel, that's probably getting you pretty close to 3600 m/s total.
  10. Don't get too excited. There's not much to it, just some internal stuff. And to be honest, I'm not sure if or when it will ever release. The changes were made months ago and it's just been sitting there. Since GPP is working as is, nobody seems motivated to push an update.
  11. Kopernicus by itself really doesn't do much without a planet pack to use it.* It's mainly just a tool that allows planet packs to work. There's really no point in installing Kopernicus other than when it is a dependency for something else. * There are probably a few things that Kopernicus does when installed by itself, but probably nothing you need to use to enjoy the game. For instance, Kopernicus has its own solar panel module that replaces the stock module. This is needed so that planet packs having multiple stars will work. But if you aren't using planet packs that add stars, then there's no need to replace the stock solar panel module.
  12. Excess heating on Icarus and Thalia is providing using the HazardousOcean feature in Kopernicus*. What HazardousOcean does is it simply adds X degrees to the temperature of a vessel every Y seconds. So in that case I'm not sure if it's really possible to dissipate the heat. It's likely a vessel's temperature will continually rise until it reaches a critical temperature and parts begin to explode. Eventual destruction may be inevitable, but I don't know enough about how it works to say with absolute certainty. * Kopernicus has replace HazardousOcean with HazardousBody. We've updated GPP to use HazardousBody, but it hasn't been released yet. HazardousBody provides more flexibility than HazardousOcean, so we may be able to produce some safe areas on Icarus and Thalia that are not subject to excess heat (like perhaps the poles). We'll take it under consideration.
  13. Great care was taken in many areas, but a few things were done just because we thought it would be cool without regard to realism. @JadeOfMaar may have assumed everything was Principia compatible because of the care taken in most cases. But since I'm the one who set all the orbital parameters, I can assure you that compatibility with Principia was not a prime consideration.
  14. GPP was never designed to be stable under Principia. I'm actually a bit surprised that Lili is the only issue. Just add the following config somewhere inside your GameData folder. @Kopernicus:AFTER[GPP] { @Body[Lili] { @Orbit { @mode = 3 } } }
  15. @septemberWaves, has Kerbalism fixed it's multiple star problem? The reason GPP dropped support for Kerbalism is because Kerbalism couldn't support multiple star systems. If the problem hasn't been fixed, then beware that if you use Kerbalism with GPP, solar panels will not work around Grannus. Kerbalism might work OK if you plan to play GPP as a single star system and never leave the vicinity of Ciro.
  16. @septemberWaves, the old Kerbalism configs can be found in the following post in the old Kerbalism thread. The previous dev promised to add GPP support to Kerbalism, but it never happened. I have no idea if the old configs will still work.
  17. It should work fine. OPM adds planets but doesn't do anything to change the stock ones (except for Eeloo), so vessels currently to or from, on or around, the stock bodies shouldn't be effected. Eeloo isn't replaced, it is moved, becoming a moon of Sarnus rather than a planet. Vessels in Eeloo's SOI could be effected, but I'm not sure. Celestial bodies are assigned an index number when created by Kopernicus, so if a body's index number is changed, it's possible a vessel could be deleted or moved to a different body. At least that's what use to happen, but I think Kopernicus may have changed the way that works. Vessels may now be linked to a body by name rather than index number. So if that's the case, you may be OK. It might depend on what version you are using. Probably the best thing you can do is make a backup of your save and then just try it out and see what happens. I doubt anyone can give you assurances one way or the other whether or not your save will break.
  18. There's nothing special about the rings per se that I know off. The only unique feature of which I'm aware is that the planet's axis, the rings, and the orbits of the moons are all inclined about 10 degrees. (You need to be using EVE to get the inclination, otherwise there's no tilt).
  19. The GPP atmospheres have already been made to the same standards as Realistic Atmospheres, so no support is needed.
  20. I don't know what everything means, but... * For each cube, the first three numbers are the surface area, the drag coefficient, and the depth of the X+ face. * Every group of three numbers that follow are the same for the X-, Y+, Y-, Z+ and Z- faces. * I don't know what the last six numbers are.
  21. @wile1411, I've repeatedly had the problem you describe. I've tried the techniques described by @Poodmund and others and it just won't work for me. Don't know why it works for them and not me; very frustrating. The only thing I've found that I can get to work is to use the Web palette. Using the Web palette, for each of R, G and B, you can only use the values 0, 51, 102, 153, 204 and 255. So that gives a total of 6^3 = 216 possible colors. But even using the Web palette, I still can't get it to work if I save the file in Photoshop. For some mysterious reason, it will only work for me if I save the file using GIMP. What I do is create the biome map in Photoshop and save it as a RGB file. I then load it into GIMP and select, Image > Mode > Indexed > Use custom palette > Web > Convert. Then just save it as a .PNG file. It makes no sense to me, but that's the ONLY thing I can get to work that eliminates the problem.
  22. … and be sure to also install Kopernicus 1.6.1-1. Links are provided in the OP.
  23. I see no reason why it shouldn't. Give it a try.
  24. OK, I think I see what you're talking about (I was looking at something else). I'm not sure what the problem is, nor how to fix it.
×
×
  • Create New...