Search results

It seems that we haven't any thread for the news about HERA. Let's start one... With a picture of Deimos at Mars... maybe we should re-work its texture in Orbiter :) the video is positioned when the pics of Deimos are disclosed, and when Patrick Michel and Brian May are welcomed :)

That's indeed what is explained, then the dust is not "moving", it is just another layer of dust (further away) that is glowing in each picture, that makes this feeling of a motion: we don't observe the motion of dust, we observe the motion of light through an irregular ball of dust...

Sorry for initially posting this in a new thread instead of this existing one! I found these images of Cassiopeia A region by JWST. Then I decided to "stack" a part of the field of view in order to reveal the interstellar stream. Just imagine: the scene spans over 2 light-years and the...

I found these images of Cassiopeia and decided to "stack" a part of the field of view in order to reveal the interstellar stream. Just imagine: the scene spans over 2 light-years and the animation covers "only" 40 days... personally, I'm just fascinated by that! source = https://webbtelescope.org

is that only in atmospheric conditions? in vaccum, I really think that the equivalent of <arrow> and CTRL+<arrow> should be implemented with RCS thrusters. Depends on your sensitivity, just search for details on the web and pick up a copy of the wanted license, but here are some insights: you...

for sure nobody should try with YR4... due to the risk to THEN create a collision trajectory

aren't there any features for space-flight? e.g.: thruster up/down, kill rotation and other nav modes.... would be nice to keep piloting with the joystick when docking, for instance.

It's interesting actually: beyond the atmospheric flight, how can we use a "BetterJoystick" in space? Maybe you can describe where you were blocked and the backlog that you've got in mind. Having people involved in a new open-source dev is challenging, for sure... (BTW: where is your...

I would have loved to see a list of this release's developers & contributors ... just to get inspired and be more grateful! :salute: Thank you so much to all OpenOrbiter 2024's developers!! Our turn: let's now check the compatibility of our addons. Happy New Year 2025.

Ready to land on Saturn's rings :cool:

this is quiet well explained here by ESA:

There is also an IAS15 engine with variable time-step, which is key for integration in deep-space. I have an implementation in python that goes relatively quick, so I can imagine that a re-code in C++ would be efficient for a mission planning tool. By the way, you don't need to import all SPICE...

Good to know! Also thx for the detailed answer about Sun's location. Then, regarding @manolollr's questions: (6N,24000kg) -> acc.2.5E-4m/s². If only due to the Sun, your vessel is at 4.86AU from the Sun. Jupiter is 1000 times lighter than the Sun, i.e. its gravitation is less by the same factor...

because of Planet 9 :) more seriously, I have always wondered how the Sun proper motion is taken into consideration in Orbiter. As Orbiter uses mainly DExxx ephemerides that are one of the available models of ephemerides (actually a compilation of sources), the Sun should be seen as a moving...

I understood where is the bug, but not what kind of bug it is. Actually, the root cause is not the time acceleration. Orbiter freezes at a "LeaveCriticalSection" (of the thread statustimer), but not always which makes the bug hard to catch. Time acceleration makes it easier to have collisions...

The problem is that one of the orbit (at least) is not circular, hence there is not any analytical formula for the "true" anomaly \theta(t). In Space Situational Awareness (SSA), the closest approach is searched my minimizing the function d(t) = \text{distance}(M_c(t),P_e(t)), where M and P are...

I think definitely yes: for instance, PursuitMFD also warns about acceleration higher than 100x (crashes? I don't know). Orbiter aims at reproducing a system behavior in an environment via physical laws that must be computed quick enough (or would imply an "acceptable" accumulation of error)...

I understand and, indeed, I think having the conflicting code (whatever it is) in PreStep callback should secure access to shared variables with Orbiter's core, at a moderate cost in terms of multi-treading. I also see that you changed the PID loop parameters. I haven't dived into their...

At first thank you for your fast reaction! Its content does things that seem to overload other tasks, but I can't say what. (e.g. at start, or GINFO <id>"N..., GINFO <id>"D..., that make the server send a REQST... that are needed...) That's a point. I'm thinking at the many clbk... But then...

For the development of OMX (fork of Orbiter Multiplayer), I am creating a feature to restore a previous state: I unlocked the acceleration rate that was developed by @Face & fellows for OMP to start a scenario in the past and re-propagate until real time with time accelerations higher than x2...