Jump to content

chuckstables

Members
  • Posts

    7
  • Joined

  • Last visited

Posts posted by chuckstables

  1. Hi people, 

    I bought KSP like YEARS ago, it must've been 2014 or 2015? I've tried logging on and resetting passwords on the store with all of my email addresses, I haven't gotten rid of any I've ever used and have got NOTHING! Do I have to buy it again then or something? Was there a time limit where you had to migrate over? If so that's kind of frustrating. 

    Nevermind, was able to figure it out. Turns out I do in fact have one email I don't use, fortunately I have forwarding set up for it so all good. Would delete this but cant figure out how sorry :/

  2. 7 hours ago, Bellabong said:

    If I wanted a kerbin with the capability for sun-synchronous satellites could I just copy the the geopotential data from earth over to kerbin? (3.2x scale kerbin)

    Simple answer; No. You can't do that.

    Here's why. An Nth order truncated geopotential has terms which go like 1/R^(N+1) in it, where R is the radius from the center of the planet. Therefore, for your kerbin, which has a radius about 3.125 times less than earth's, terms of order N in the geopotential will be 3.125^(N+1) times larger on your kerbin's surface than they'd be on earth's surface. For a 30th order geopotential this is about 7*10^14 times larger for the highest order terms. 

    What you can do is make your own reasonable geopotential for your kerbin. For sun-synchronous orbits the most important term in the geopotential is the second zonal term, though for earth other terms contribute significantly. So you could just make a custom geopotential which only includes the J2 term (second zonal term).  

  3. 3 hours ago, eggrobin said:

    While the cost of prolonging the ephemeris is quadratic in the number of massive bodies (whereas computing the trajectory of a vessel is linear in that number) the timescales are very different (at least in the worst case, and since it is not possible to have variable step size and symplecticity, the chosen step size must accommodate the worst case); this is a case where the constant factor matters more than the asymptotic behaviour (the number of massive bodies remains fairly small, even with RSS).

    As @scimas said, these are vessels.

    We had this kind of thing in mind when choosing the number of terms in the selenopotential—we go up to degree and order 30—: it was chosen to keep the qualitative behaviour of the low orbits described in a 2006 paper by Ryan P. Russel and Martín Lara, Repeat Ground Track Lunar Orbits in the Full-Potential Plus Third-Body Problem; see figures below.

    Do you have any screenshots of your frozen orbit, and of what the orbit analysis window says about it? My attempts at getting a frozen lunar orbit in-game have not been very successful.

    Figures from our investigation of Russel and Lara’s Orbit C with various selenopotential truncations.

      Reveal hidden contents

    dJjOb4X.png

    Same as above over 10 years.

    ZfiqfW9.png

     

    I did the frozen orbit quite a while ago so no; I don't have any pictures. That being said it wasn't perfect; it ended up being unstable over a 12 month period with no correction burns. In GMAT the orbit was stable for around 3 years from what I remember with no correction burns, but the fact that it worked with a periapsis of around 30-40 km from what I remember is remarkable. I did it before the orbit analysis window actually was introduced as well; I just went forward in time. Here's the paper I based it off of; https://lunar.gsfc.nasa.gov/library/LRO_AAS_Paper_07-057.pdf 

    In particular look at pages 10-11. I think it was technically a quasi frozen orbit. Still impressive in any case. The LRO these days is in a different quasi frozen orbit with an orbit of 20km x 165km. I think they wanted the Periselene to be lower so they could get more detailed images over the poles. 

    Super interesting graphic by the way! I love stuff like that. Thanks for sharing. If I can replicate it again I will take some pictures and show you. What sort of frozen orbits have you tried to replicate? Thanks for taking the time to respond; I appreciate it. 

  4. 9 hours ago, pleroy said:

    Let's ignore for a moment the inconvenience of having to special-case a solar system, of having new code paths to test, bugs that would show up only for some solar systems, etc.

    The real question is: why would anyone want to trade CPU for I/O?

    Computing a year of ephemeris for the real solar system takes about 10 seconds on an average computer, which means that, in the absence of vessels, we support timewarp at 3'000'000x.  A representation based on an existing ephemeris (DE431, INPOP, EPM, etc.) would take tens of megabytes per year.  That would require several seconds to load (for mysterious reasons KSP reads saves no faster than 5 MB/s even from SSD).  And then we would have to be super-cautious to be consistent with said ephemeris when it comes to masses, geopotential, and the like.  For instance, we truncate the geopotential at large distance, we might not be able to do that.

    On top of this, the real cost of integration is in the vessels: we use a step size of 10 seconds whereas we use 10 minutes for the ephemeris, and many games have dozens of vessels.

    Difficult enough that we have extensive documentation of the mathematical details, because the code is incomprehensible in isolation.

    A very insightful comment.  We have been working on this thing for 6 years but the first cut of a symplectic integrator took a few days.

    Yeah definitely fair. I was more just curious whether it would be possible; I've always assumed that the cost of the N-body calculation for the solar system would be more than for a vessel, but that does make sense.  I'm curious; what's your time step for asteroids and "unknown" objects? Is it the 10 second one or the 10 minute one?

    As an aside; I'm honestly super impressed that this mod actually exists; it's absolutely incredible. What's even more awesome is that it's free. I've gotten hours of fun times playing around trying to get quasi-frozen low lunar orbits. I was impressed to see that your selenopotential model was accurate enough to replicate the original frozen orbit of the Lunar Reconnaissance Orbiter. It's a testament to the hard work you guys put into this mod; so thank you. 

  5. On 6/19/2020 at 7:46 PM, SynX said:

    KSP is based on Unity Engine. N-body gravity simulation shouldn't be too hard, as you could just add gravity as a function of mass and distance between all objects or Rigid Bodies. I believe that the sphere of influence single body gravity actually needs more coding work... you need to first judge which sphere of influence are the craft is in, and then calculate the amount of gravity acted upon you. However, that's not the case. Last time I downloaded Principia, and found out that the 600MB mod was mostly composed of codes... I don't understand that why is this such a large project, I've seen Principia videos several years ago and it's still WIP.

    It's not really that simple. You need high fidelity symplectic integrators to get stable orbits if you are going to go the numerical route. Otherwise energy is not conserved and orbits will diverge and become horribly unstable. It's far simpler using patched conics because the orbits are known EXACTLY with mathematical functions. Once you're in a sphere of influence you use math to determine the exact shape (a conic section) of your orbit and boom; you're done. Your spacecraft is now on rails; there is no need to determine the gravitational force acting on you. There is no real numerical integration here; everything is predetermined and on rails.

    If you add n-body physics your orbit is no longer known exactly. There is no closed form solution for a general n-body problem. Therefore you have to use numerical integration to approximate the 'true' orbit using a finite step size (as you can't simulate an infinite number of time-steps). Finite step sizes lead to energy not being conserved over longer time scales with most integration methods. You can get around this by using what's called a symplectic integrator, which conserves an energy-like quantity.

    You also need one in this situation where you can vary the step size to account for situations where you're travelling very fast near a planet, where the step size needs to be smaller. You also need a method which is computationally efficient enough to be run in high time warp. This is difficult to do, which is why the code is probably so large. The mod dev's also needed to add accurate geopotential models for RSS, which model the real gravitational field of planets/moons using a power series with spherical harmonics. They also need to add code to efficiently evaluate the analytical derivatives of each term in the geopotential (at least I'm assuming they analytically evaluate them). This is also difficult. 

    I could write a symplectic integrator in python in about 100 lines; but to get it to run in KSP let alone to run efficiently would require a lot more than that.  

  6. Would you guys consider adding in an Ephemeris model for Real Solar System? That way we wouldn't have to simulate the full N-body dynamics of all the planets and they could just follow high fidelity trajectories that exist in a data file. There's lots of high precision Ephemeris models available for the solar system IRL for trajectory designs for missions. This could speed things up quite a bit. Just curious. Thanks!

  7. Hey. I found a few errors in the configs for SSTU. These are pretty simple to fix; I'm using the latest download of Realism overhaul from github. In RealismOverhaul/RO_SuggestedMods/SSTU/SSTU_SCC_Orion.cfg there's a source for a  bug that makes it so that the capsule is stuck with the default resources it's given by SSTU. If you try to change these in game it will revert back to the default resources when you launch or reload the craft file.  To fix this you have to add     !MODULE[SSTUVolumeContainer]{} before you add the ModuleFuelTanks module and define the resources you want the part to have. So this

    MODULE
        {
            name = ModuleFuelTanks
            type = ServiceModules

    needs to become this

    !MODULE[SSTUVolumeContainer]{}

    MODULE
        {
            name = ModuleFuelTanks
            type = ServiceModule

     

    This needs to be done for the Orion Command Module, the Orion European Service Module, and the Orion orbital Command Module. All can be found in the SSTU-SCC-Orion.cfg file. There's another bug in that file which results from the wrong module being named for the RCS. As a result the RCS thrusters on these parts retain their SSTU definitions. Where it says 

    @MODULE[ModuleRCS],

    It needs to be changed to 

    @MODULE[ModuleRCSFX],

    This again needs to be done for all the orion parts. Not sure whether or not this is supposed to be posted here, so sorry mods if I'm not supposed to be posting this here! I spent a good hour trying to figure this out, and thought I'd post it to save you all the trouble of fixing it yourself. I personally fixed these issues on my own installation of Realism Overhaul. If the Dev's want me to send them the CFG files I can send the edited ones on GitHub? Just let me know. Thanks for creating this awesome mod guys! I enjoy it quite a bit. 

×
×
  • Create New...