Orbiter 2011?

I was looking for that, but forgot what it was called. Thanks Artlav. :cheers:
 
I wish I had found this a long time ago. Fantastic! :)

I still think the hover engine controls would do well in Orbiter's core. Though perhaps the Ctrl function could be reversed (hover control would stay the same, but Ctrl+0 would set them to full and Ctrl+. would shut them off.)
 
I'd like collision detection supported by the core.
The simplest way to do this seems to be using a current engine such as Havok.

Darren
 
Hal9001 makes a good point. This thread is rapidly becoming a clone of the other, and a "wishlist" of sorts.
 
If only there was one gigantic "wishlist" thread where everybody could look before suggesting something in the Feedback forum or somewhere else...
 
If only there was one gigantic "wishlist" thread where everybody could look before suggesting something in the Feedback forum or somewhere else...
I recall that there was one, but I can't seem to find it. Maybe it was renamed...? Or maybe that was the thread HAL posted. :huh:
 
I'd like relativity, which could probably be fairly easy to code (I don't know, I'm not a C++ coder).

1. Mass of vessel increases with speed.
2. Relative speed of time increases with vessel's speed (when you're focused on it).
3. All vessels' and their systems' perception of time are affected by their speed.
4. How YOU perceive time is determined by the velocity of the object you're focused on.
5. (This could be tricky) Planets' and moons' masses and rotation periods are affected by relativity.

Although considering the differences would be hardly noticeable in any real spacecraft, it's probably not worth it.
 
Before putting relativity in, finite speed of light should be considered (Earth as seen from Neptune is not where it is now geometrically, but where it was some time ago).

All this would require linking to SPICE. Gotta love this toolkit.
 
But once all (or almost all) the aspects of relativity were added to Orbiter it would definitely make things more interesting. Especially at high velocities.
 
If only there was one gigantic "wishlist" thread where everybody could look before suggesting something in the Feedback forum or somewhere else...

If people would only READ a wishlist thread before posting to it, it would already help a lot...

Before putting relativity in, finite speed of light should be considered (Earth as seen from Neptune is not where it is now geometrically, but where it was some time ago).

The Idea is quite interesting. I think it could already be done in a graphics client, the only thing you'd have to do is not using the standard position for the graphics engine, but recalculate the node position instead. Every frame. Might get a bit resource hungry for the benefit...
 
If people would only READ a wishlist thread before posting to it, it would already help a lot...



The Idea is quite interesting. I think it could already be done in a graphics client, the only thing you'd have to do is not using the standard position for the graphics engine, but recalculate the node position instead. Every frame. Might get a bit resource hungry for the benefit...
Perhaps defining where the visual positions are for each planet on the "celestial sphere" and updating that position after a specified time frame.
 
Further LUA improvements. Because for now, I don't know if I must spend time improving my C++, or rather spend that time learning LUA (which seems to be the future of Orbiter : being able to code without Microsoft VS(r) would make Orbiter even more "independant").

But for now, LUA doesn't replicate every Orbiter's library C++ functions, so I'm a little confused with that. Then I just play Orbiter. And it's fun ! :lol:
 
:probe:interestellar travel and collition detection :titanis:

Definitely those two, and integrate Orulex or Orulex-like rendering.

We also need to start to somehow improve the backward compatibility to help maintain add-on compatibility. This is a problem across the entire industry, not just orbiter specific.

There are too many (most-excellent) add-ons that will not be supported forever. And orbiter is 10 years old now too. Authors move on, get busy, pass away, etc.. etc..
 
scenario loading without orbiter exit
dynamic textures for parts of planets....esp Jupiter to show the changing clouds at the great red spot for example
thicker haze in gas giants and removing the land able hard surface
allowing planets to be created or removed without orbiter exit
addon installer & more importantly an uninstaller - should keep track of dependencies etc
start distributing a library of autopilots with the core that helps in common tasks like base landing, getting to orbit etc just to have some automation out of the box without having to install addons
 
Last edited:
I want only a callback function to program the mapping from control inputs to RCS thrusters and control surfaces myself.

hey... as a matter of fact, i think i could perhaps deliver something like this.... not as a built-in feature (that's only Martin) but as an OrbiterSound-like SDK thing...

my FlightControls module completely overrides the way axes and buttons are bound to RCS jets and control surfaces - i figure if i could have a couple of functions exported from there,we'd have a very suitable way to tap into the control axes directly... (and you'd get multi-joystick support)


if it interests you, then let us continue on this idea in the FlightControls Thread


just let me know what sort of mapping features you need and we can get this going :thumbup:
 
Personally I think it would be really cool to have DMM support, that would make failing at reentry more realistic and with more visual payoff. :cool:

Darren
 
Back
Top