Jump to content

einsteiner

Members
  • Posts

    51
  • Joined

  • Last visited

Posts posted by einsteiner

  1. If you can truly warp anywhere you want, you can warp deep into the sun's gravity well such that your velocity points away from the sun, and use its gravity to slow down. When you have the velocity you want you warp out to LEO with just the right velocity to be in a nice, circular orbit.

    To find the optimal maneuver you take the final velocity you want minus the velocity you have to find the velocity you need. You warp to the proximity of the sun with sun's gravity pulling toward that dV vector. To do this fast you want to be as close to the sun as possible. If you can survive being right on the surface you will get an acceleration of 274.0 m/s^2, decreasing as you fly "up" away from the sun. Use the time spent flying up to spool up your jump drive. If you need more dV use it to jump back down to the surface of the sun and repeat until you have the velocity you need, then jump to LEO. You can adjust the amount of dV you get per jump by jumping further from the sun. Your crew won't experience any g-forces since you'll be in free-fall the whole time. You're only limited by how close you can get to the sun.

    This whole thing obviously violates conservation of energy and momentum, but so does the jump drive.

  2. There is some truth in what the OP says, if your apoapsis and periapsis do happen to line up with the AN and DN, then it's perfect for plane changes.

    Using a setup that looks like the OP's pictures, it takes 52.5 m/s to make the orbit equatorial. If it were in the optimal position (ie. Ap is on AN, meaning Ape=0), it would take only 48.67 m/s. So not being right on the Ap for the equatorialization burn loses you less than 4 m/s. Include a burn to reduce your periapsis to aerobrake (about 100 m/s) and you'll never miss it.

    Here are the orbital parameters for the numbers I arrived at, if that will make you happier:

    ORBIT

    {

    SMA = 11396924520.3127

    ECC = 0.2170260877019

    INC = 1.50113290597947

    LPE = 338.895144038711

    LAN = 137.362053173262

    MNA = 3.79013058444902

    EPH = 3617460.69961997

    REF = 0

    }

    This isn't the right asteroid, this one is in orbit around the sun (REF=0).

  3. The problem with Chernobyl is that all the stuff around the core that is used to pump and circulate water was blown away and that the melted core doesn't produce enough heat any more. It would be pretty useless.

    I think you've hit it on the head. It's like trying to use the embers from last night's camp fire to cook. They're still hot enough to be dangerous, but not hot enough for any practical purpose.

  4. I received a contract to "Position satellite in a tundra orbit" around Kerbol.

    Not Kerbin, right? 3 million km is inside Moho's orbit, you're going to have to use so much delta-V just to get down there, I wouldn't worry about trying to get out of doing the plane change. You can probably play some games with Eve intercepts to lose energy and increase your inclination, then Moho intercepts if you can time it right to lower it some more, but you'll need a lot of fuel no matter what you do, methinks.

  5. It is a compile error to assign an attribute to something it's not designed for. The error says "Attribute 'KSPField' is not valid on this declaration type. It is only valid on 'property, indexer, field' declarations." So it should work on properties. It is possible Squad declared it as applying to properties but didn't put in the code to actually fetch the value. Perhaps this belongs in the bug reports?

  6. That said, I'd love to see a FAR or AJE type mod to come out which introduces realism to the reaction wheel system. I was actually planning to write such a mod myself but only if the game reaches its final version and nobody else has done a better job at it.

    I second this. It would be more realistic in that you would have to include RCS for every spacecraft. Since KSP doesn't include things like gravity gradient torques and solar light pressure it wouldn't pick up stray angular momentum, so it wouldn't be too bad. This could be a nice difficulty option, since Squad is working on more customization in that area.

  7. Small changes in Isp cause large changes in the total mass of your craft, this demonstrates this perfectly. For a recent mission the total starting mass of the craft with a LV-N was 58.5 tons. With a Poodle it would be 580 tons. That's a lot to launch into orbit before your mission can even start. So they are useful.

    Is it cheating? I say no if you use it with some restrictions. I don't use it as a takeoff/landing engine, to avoid irradiating planetary surfaces. I also don't use it for any burn less than 100 m/s, as I imagine starting and stopping a nuclear reactor is non-trivial.

  8. 0.5 * 6^2 * 5.3 * (275000*0.2 + 300*500*y)/(275000+300y) * 0.008 * (275000 + 300y) = 4600000

    Please point out errors :(

    0.5 * 6^2 * 5.3 * (275000*0.2 + 300*500*y)/(275000+300y) * 0.008 * (275000 + 300y) = 4600000

    0.5 * 6^2 * 5.3 * (275000*0.2 + 300*500*y) * 0.008 = 4600000

    275000*0.2 + 300*500*y = 6027254

    300*500*y=5972253.7

    y = 39.82

    The right side of the original equation really should include the weight of the parachutes themselves, but it only changes the answer a little (41.57 vs 39.82)

  9. I vote for synthetic fuels. The technology to create them is already well developed, it's just that natural fuels aren't expensive enough yet. They also don't require any modifications to engines to be used, so they can be used in the existing vehicles. Even if they live up to K^2's promises, nuclear isomer batteries aren't going to be cheap enough for Belarus airlines for a long time (not picking on them, I just saw World War Z).

  10. I am writing a plugin that allows me to list a number of altitude-pitch control points and have Mechjeb's SmartASS fly to the correct pitch interpolated between the control points. The window is handled using a Mechjeb DisplayModule. I got this working well and can change the number of control points dynamically just fine. The window resizes itself larger to accommodate more points, but does not shrink itself when the number of points is decreased (see image). This is persistent across closing and restarting KSP. Looking at the code for custom info windows in Mechjeb there doesn't seem to be anything special to make them shrink, so I'm confused why mine only grow. Any ideas?

    lkX51O1.jpg

  11. On Earth, it's not much of an issue; the ignition source can be supplied by the launching infrastructure (The Space Shuttle used external igniters).

    This is not true. The Space Shuttle engines had augmented spark ignitors inside the engine. The sparks you see in videos such as

    are there to burn off any excess hydrogen that may be floating around. Similar ignitors were used in the Saturn 5 engines, where the second and third stages had to start in flight (twice for the third stage).
    • The problem is RAM usage due to large textures.
    • Textures are large because the game will accept formats that are in non-native formats like .png, which accommodates ease-of-access to modders.
    • Solution: require a compressed and compiled texture format like DXT for quicker load times and easier rendering by the video card.

    If Active Texture Management can compress the textures from inside the program, so can KSP. Then have it save the textures alongside the original files. When it loads it can check to see if the compressed file is out of date or missing, and if so re-generate it. Otherwise it only has to work with the more efficient compressed texture. It's still easy for modders because they don't have to create odd formats (though I don't see why there shouldn't be a tool to let them) and efficient.

×
×
  • Create New...