Jump to content

OhioBob

Members
 View Profile  See their activity

  • Posts

    3,934

  • Joined

  • Last visited

 Content Type 

Everything posted by OhioBob

  1. OhioBob
    With BetterSRBs there's a period of thrust decay at the end of the burn, with a visible weakening of the exhaust plume. But I don't know if the effect is as pronounced as you're looking for. BetterSRBs also makes other changes beyond just the thrust curves, which you may or may not want. You'll just have to decide for yourself whether you like the mod or not. If not, maybe I can write a MM patch that will make changes closer to your liking.
  2. OhioBob
    What versions are you using? There's a bug in Kopernicus 1.5.0-1 that causes a problem as you describe. It's fixed in 1.5.1-1. It that's the issue, then you're going to have to upgrade.
  3. OhioBob
    That's not a lot of information there. You're going to have to give be more to work with.
  4. OhioBob
    @Kroslev Kerman You might be able to use a thrust curve and make it so the SRBs produce a small lingering amount of thrust for a time after jettison. Once the thrust drops below a certain level, the SRB isn't really producing anything useful at that point. It just becomes dead weight, so cut it loose. You should be able to see it continue to burn what little fuel remains as it falls away. This will waste some fuel, but that might be an unavoidable tradeoff. A thrust curve gets added to an SRB's engine module. It should look something like the one below (taken from BetterSRBs). It gives a thrust multiplier as a function of fuel fraction remaining. For instance, in the example below you can see that when 4% of the fuel remains, the thrust is 76% of the maxThrust value. You'll have to experiment and figure out a curve that gives the effect you want. Maybe do something like have it produce 5% thrust for the last 1% of fuel remaining. @MODULE[ModuleEngines] { useThrustCurve = true thrustCurve { key = 0 0.1 0 33 key = 0.04 0.76 0.79 0.79 key = 0.54 1.155 0.79 0.79 key = 0.65 1.1785 -0.51 -0.51 key = 1 1 -0.51 -0.51 } }
  5. OhioBob
    @Kevin Kyle, I usually just focus view on the target planet and try to get as close to the correct plane as possible. For Mun and Minmus, if it's going to be really far out of plane, it's easy to just delay the transfer and loiter in Kerbin orbit until the alignment improves. For a transfer to Duna, that' really not possible. You have to go when it's time to go or you'll miss the window. So I don't worry about it to much. I just try to get an intercept and then perform a correction(s) to match the plane of the target orbit as close as possible. There's only so much that can be done in that regard, so instead I try to line it up so I can do the plane change at the same time as the orbit insertion. The key is to make sure the periapsis of your incoming trajectory touches somewhere on the orbit line that you're trying to match. You then just place a maneuver node on the Pe and perform a burn the includes both the retrograde and normal components. You can also include a radial component if necessary. By performing a combination burn you can save much delta-v. It's a Pythagorean thing. If you have a 1000 m/s retrograde burn, 500 m/s normal burn, and 200 m/s radial burn, you can perform all three at once for SQRT(1000^2+500^2+200^2) = 1136 m/s. I can often match the target orbit close enough with one big burn to fulfill the contract requirements.
  6. OhioBob
    How's it breaking it? I don't see why anything suggested on page 13 would completely break OPM.
  7. OhioBob
    Have you tried Sigma Dimensions? It might still work. Here's the most recent version... https://github.com/Sigma88/Sigma-Dimensions/releases/tag/v.0.10.1
  8. OhioBob
    @Dagger is still trying to work some things out. I think Tilt'Em is likely to go through some more changes before it's completely useable. I have only the vaguest idea of how things work internally, so I can't help out all as far as coding it goes. But if there is anything I can do to help out with the general mechanics of it, I'd be happy to do what I can. When I ran my tests, I looked at just a couple of KER's displays. I mainly focused on latitude/longitude on the surface display, and inclination/LAN on the orbit display. The latitude and longitude appeared to be reading correctly. For instance, if I put the satellite in orbit around the body's new (inclined) equator, I was reading 0 degrees latitude all the way around. The inclination and LAN, however, were reading in relation to the ecliptic, not the equator. The orbit data is not wrong, but it's not the preferred way of doing it for planetary orbits. I didn't check any of KER's other features, so I can't say what else might be working or not working.
  9. OhioBob
    I've tested it several times over the last couple years. At one time the solar constant of 1360 W/m2 at the home world was hardcoded into it. But the last time I tested, which was a few months ago, that was fixed. If you give a star a luminosity of X, and then place a satellite in orbit around that star at a distance of 1 AU (where 1 AU equals semimajor axis of home world), then you should read a solar flux of X. When moving closer or farther away, you should see the solar flux change according to the inverse square law.
  10. OhioBob
    From what I've determined, sunAU has nothing to do with a star's luminosity. The only purpose for sunAU appears to be to compute the lookup for brightnessCurve. BrightnessCurve, despite its name, has nothing to do with luminosity. It determines the size of the sunflare when viewed at different distances, where distance is in units of, sunAU/(distance from star in meters). I'm confident that's not the case. The "luminosity" parameter is the solar constant at the home world.
  11. OhioBob
    From my experimentation, the "luminosity" of the home star is the solar constant at the home world. For instance, the stock sun has a luminosity of 1360, so that means the solar constant at Kerbin will be 1360 W/m2. It doesn't matter how far away from the star the home world is positioned. The solar flux at other distances from that star are computed according to the inverse square law. For other stars, their luminosity setting is simply in direct proportion to the home star. For example, if you have a second star and give it a luminosity of 136, it will have 10% of the home star's luminosity. If you place a vessel at a distance from the second star equal to the home world's distance from it's star, you should read a solar flux of 136 W/m2.
  12. OhioBob
    Or uninstall Kerbal Konstructs.
  13. OhioBob
    Absolutely, I agree. Kerbol is one big contradiction. The reason the two methods yield such different results is because Squad made Kerbol so large. If it's radius was at the same scale as the rest of the solar system, the two methods would yield matching results. I prefer to go with the 3.161E+24 number because temperatures in KSP are computed using the solar constant (at least I think they are).
  14. OhioBob
    Version 1.0 references the body by index number, but that has changed in v1.1. But it's still a work progress, and there are likely more changes are on the way. So I recommend you just sit tight for a little while and wait until Dagger has worked out all the bugs.
  15. OhioBob
    If we were to build a big hollow sphere around the sun having a radius equal to that of Kerbin's orbit, then all of the sun's energy would fall on the inside surface of that sphere. If we were to measure the amount of energy falling on that surface per unit area, we would measure 1360 W/m2. This measurement in called the solar constant, and the value of 1360 is defined in the game. So to compute the total energy that the sun radiates, we just have to compute the total surface area of the sphere and multiply the result it by 1360 W/m2. The radius of Kerbin's orbit is 13,599,840,256 meter. So the surface area of a sphere having that radius is, area = 4 * pi * radius^2 = 4 * pi * 13599840256^2 = 2.324221308E+21 m2 So the sun's luminosity is, Luminosity = solar constant * area = 1360 * 2.324221308E+21 = 3.161E+24 W.
  16. OhioBob
    I just tested it in 1.1 and, unfortunately, the bug I reported is still there. I left an additional comment about it on GitHub.
  17. OhioBob
    How do we get 1.1? Your GitHub page includes only a 1.0 release. I've also added further information regarding the issue I reported on GitHub.
  18. OhioBob
    Yes, I did some testing as well and I too think the NavBall is correct. I placed a satellite into a equatorial orbit and pointed it at +Normal. The Level and +Normal indicators on the NavBall remained positioned exactly on the intersection of the horizon and the N line throughout an entire orbit. This tells me that the satellite's longitudinal axis is continuously pointing at true north. This is what we should see if the NavBall were correctly identifying the new north pole. When I put the satellite in non-inclined orbit (relative to the ecliptic), the Level and +Normal indicators would oscillate around north, pointing true north only two times per orbit. This is again what I would expect if the NavBall were working correctly.
  19. OhioBob
    @jrbudda, have you seen this new mod? I've been playing around with it and it has a lot of potential. I think it's something planet makers have wanted for a long time, so I can see it catching on. The only issue I have is that when we're orbiting a body with axial tilt, it would be preferable to have orbital elements provided in reference to the planet's equator. KER currently does not do this. Inclination, LAN, etc. is given in reference to the ecliptic. Do you think providing orbital information in a geocentric-equatorial coordinate system would be a feature that could be added to KER? From what I could see in my tests, it appears that the latitude/longitude in KER's surface display is working properly with Tilt'Em installed.
  20. OhioBob
    Yes, everything seems working correctly as far as I can tell.
  21. OhioBob
    Oh, maybe. If so, then never mind.
  22. OhioBob
    OPM has its own visual enhancement mod:
  23. OhioBob
    Currently orbital elements are in reference to the ecliptic (universal coordinate system). A due east launch from KSC will put you in orbit around Kerbin's equator, but the KER readout will say the inclination is ~23.4 degrees (Kerbin's axial tilt per this mod's cfg). Having a readout that gives orbital data in reference to the equator is something that I think is needed. I suspect it will likely require an upgrade to KER (and MechJeb, and whatever else uses or provides such information).
  24. OhioBob
    @VonFrank, yes, the axial tilt of a planet is usually expressed relative to the plane of the orbit. But I agree with @Phineas Freak that it's probably easier to use the ecliptic as the reference point. If it's really so important that tilt relative to the orbit must be known, the developer may just have to mathematically convert from one reference plane to the other. If it becomes necessary, I can probably figure out the conversion.
  25. OhioBob
    @Dagger, I've found a problem. The line of nodes of the equator randomly changes from one game launch to the next. For instance, put a satellite in an equatorial orbit (you'll have to figure out the LAN by trial and error). Shut the game down and restart. The planet's axis will now be pointed in a different direction and the satellite will no longer be orbiting around the equator. I did it three times. First time the LAN was 84.54 degrees, second time it was 198.33, and the third time it was 266.13. It looks just like a problem we use to have with planetary rings. Any time we tried to incline rings, the LAN kept randomly changing. Kopernicus eventually added a longitudeOfAscendingNode parameter for rings that locked down their orientation. It looks like you may have to do something similar with axial tilt.
×
×
  • Create New...